Re: [hylafax-users] batching almost there

[Mason Sanders <mason@xxxxxxxxxxxxxxxx>]

Hello,

This is a little off topic but this discussion sheds some light on a problem that I have been having.  I am running hylafax 4.2.1 on FC2 clients and a Cent OS 3 server.  For whatever reason, we end up having to fax a lot of documents to ourselves.  This works fine as we have 16 modems in the server, but occasionally the jobs will be batched together.  Hylafax realizes that the jobs are separated entities and splits them into separate tiff files correctly, however all of the jobs have the same comm id which is throwing off our internal fax tracking database.  It relies on a unique comm id for each job to be identified.  I can't seem to determine what causes the jobs to be batched together.  All of the jobs must come in to the same phone number so that they are placed in the correct directory.  Is there a way to turn the batching feature on/off?  What criteria does the server use to determine if it should batch a set of jobs to the same destination?  I have read all of the man pages and can't find any mention of batch jobs.  Any help would certainly be appreciated.

Thanks,

Mason Sanders

 

On Sat, 2005-07-30 at 06:33 +0800, offman wrote:
> On Jul 29, 2005, at 8:53 PM, Aidan Van Dyk wrote:
>
>
> > * offman <offman@xxxxxxxxxxxxxxxx> [050729 08:36]:
> >
> >
> >
> >> Ahh!!
> >> i've not got that deep into the source yet, which package is that in?
> >> We have no special flags set , as it is a java front end , just a
> >> "TTS"  but we do SET a re-try of 15 minutes.
> >>  Out of over 40 jobs in the last couple of hours , i have not seen
> >> any "jitter" added.
> >>
> >>
> >
> >
> > When sending a job "fails" (see faxd/FaxSend.c++:317), the job  
> > retrytime
> > is used unless the attempted dial resulted in:
> >   NODIALTONE
> >   ERROR
> >   FAILURE
> > in which case the configured JobRetryTime for the device is used.
> >
> > If a previous job in a batch fails (so tts for the job will be in the
> > "past" when faxq get's it back), faxq will use the job's retrytime,
> > unless it's not set, in which case it get's the jitter: tts set to  
> > now +
> > X (where 1/2 requeueInterval < X < requeueInterval).  See
> > faxd/faxQueueApp.c++:1529.
> >
> > So, if you set retrytime, you can rest assured that it will be used,
> > except if it was the first job in the batch, and dialing resulted  
> > in in
> > one of the 3 earlier errors (not a usual operating case).
> >
> > A case might be made that in FaxSend.c+, we should honour retrytime  
> > for
> > those cases too.
> >
>
> So maybe a better solution is to remove the jitter routine , but set  
> a default retrytime ?
> It should give a similar degree of randomness,but be based on the  
> jobs submittal time.
> Thereby giving a greater chance of batching on failure.
> but if the user wants to override the retry time then so be it.
>
> I'm actually pleased how this is all working out, because without the  
> batching , & based on last years figures,
>   it could cost us an extra $10,000-15,000 dollars in non batched jobs.
>
>
>
>
> > a.
> >
> > -- 
> > Aidan Van Dyk                                              
> > aidan@xxxxxxxx
> > Senior Software Developer                          +1 215 438-4638  
> > x8103
> > iFAX Solutions, Inc.                                http:// 
> > www.ifax.com/
> >
> >
>
>
>
>
> ____________________ 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@xxxxxxxx.*