Hylafax Mailing List Archives

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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




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*



Home
Report any problems to webmaster@hylafax.org

HylaFAX is a trademark of Silicon Graphics Corporation.
Internet connectivity for hylafax.org is provided by:
VirtuALL Private Host Services