Re: [hylafax-users] Blocked by concurrent call problem since upgrade to 4.2.2

[Jordan Kojouharov <hylafax@xxxxxxxxxxx>]

Lee, thank you for the quick and detailed response.

As a follow up to this, some more testing suggests that this only 
happens for me when the following conditions are true:

1. there are two or more jobs to the same destination already in the 
outgoing queue, with one of them sending, and the others 'blocked by 
concurrent'.

2. then, a few more jobs for that destination get submitted, and HylaFAX 
attemps to batch them, however, resulting in two or more of them going 
into 'blocked by concurrent', and never unblocking, even after the 
current sends to that destination get completed.

setting 'MaxBatchJobs: 1' in /var/spool/hylafax/etc/config seems to have 
fixed the problem for me (i think this has effectively disabled 
batching). See below for thoughts on the default value for MaxBatchJobs.

regards and thanks,
Jordan

Lee Howard wrote:
> Jordan Kojouharov wrote:
>
> > as far as I am aware the default value of MaxBatchJobs is '1'?
>
>
> The default value of MaxBatchJobs is not 1.

'man hylafax-config' does seem to indicate that the default value for 
MaxBatchJobs is 1. Not sure if the man page is wrong, or I'm reading it 
wrong:

MaxBatchJobs   integer   1   max jobs in a batch

The maximum number of jobs to batch together.  Fax  Batching  is an 
advanced  feature that has some rough edges.  It is not currently 
considered fully supported,  but  in  limited  situations works  well. 
 Enabling  this  on  a server where you don't have total faith in your 
users could have serious undesired  affects.

> > Can someone please shed some light on the batch send feature - how 
> > does it work and what are the benefits of using it?
>
>
> The original idea behind batching was to enable busy servers with a 
> restricted set of outbound modems, with a large volume of non-bulk faxes 
> to repeated destinations, and where those destinations were frequently 
> busy to be able to deliver everything in the queue to that destination 
> in one call... all of this in an effort to enable more timely delivery 
> of sent faxes and to avoid running into killtime trouble in those 
> situations.  This was a fairly limited intent, and I think that, for the 
> most part, batching as found in 4.2.0 accomplished this.
>
> Since that time demands have been placed on the batching feature to 
> coordinate batches, to improve on faxq CPU usage, and several other 
> things including some more recent features (like keeping batches 
> together after encountering busy signals) that have been added since 4.2.2.
>
> It sounds like for the most part batching is being knowingly used to 
> save on long-distance toll charges.
>
> You can search the archives for other posts on batching that I have 
> made, but it's *supposed* to work in this fashion: if, when faxq 
> allocates a modem to a job, faxq finds other jobs to the same 
> destination also in the queues, then it will add those jobs to the 
> current job in a "batch".
>
> Lee.

____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*