HylaFAX The world's most advanced open source fax server
[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [hylafax-users] batching almost there


On Jul 29, 2005, at 12:24 AM, Lee Howard wrote:

offman@xxxxxxxxxxxxxxxx wrote:



On Jul 27, 2005, at 10:33 PM, Lee Howard wrote:


Please double-check this by looking at the files in /var/spool/ hylafax/sendq and checking that the "tts" entry is exactly the same for all of them.


hmm seems not

fax1 tts:1122538209
fax2 tts:1122538324
fax3 tts:1122538324

that would account for it, page 1 takes a little bit longer to process.



It would seem, then, that the time-to-send is not being set independently, but rather is being set with a relative value again.

that is now fixed, the programmer nested the call.

Also, one thing that I should make you aware of before you encounter this on your own and we have another issue over this matter... HylaFAX doesn't currently maintain batches. So just because it's batched on the first call, if it is retried (i.e. the first call results in a busy signal), HylaFAX does not attempt to keep the jobs in the same order or even at the same rescheduled time-to-send ("jitter" is added to the time-to-send on reschedules). So if a batch does not make it through on the first attempt then it will be highly unlikely [with the way that the code currently is] that on the second attempt those jobs will be batched again.
( I had a semi fix for it, in java)
but i'm npt worried about that ,I can see that from the hylafax code, and I understand the construction of the system enough to see potential issues.
I used to code embedded systems in C++ & assembly professionally for over 15 years. I would love to work on Hylafax but i just don't have the time.


I still feel like your usage of batching is a bit misappropriated. You seem to be counting on the server-side batching mechanism to collate your pages, and that's not really what the mechanism was designed for. As I see it, this collation should really be happening on the client-side, before the job is submitted to the server for transmission.

Not exactly counting on it. I'm not expecting the pages to be collated it's not a printer, that would be nieve, it's more a document pack
(total maybe 10-50 pages, but it might be 3pages +2pages +4pages +1page (as separate jobs), but tied together with a ref number), they are for different people/departments , in the same business relating to the same supply job.
, it CAN be split up, but it's better if it goes in 1 call. it's more like buying a 4litre bottle of coke, instead of 8 tins, and i'm not asking for the jobs needing/must be all together, and in the exact order.


to clarify exactly what is needed:
Is a way to try to reduce IDD calls, nothing more. as you know It is not cheap ESP. with redial.

Unfortunatly faxes cannot be batched as you suggest because they may come from a number of different users,we would have to have some sort of daemon to grab them server side , bump them into 1 job & pass to hylafax, very messy , tried it , and it does not interface well, esp. with hylafax clients

the way it is done currently , stands a risk of 1 Idd call for each fax, I'm not worried about re-dials now & again, but more about 1 Idd call for each fax, that can really mess up my budgeting.

The other question is about redials, if we submit 4 faxes to the same destination & the same TTS , and if the first one hits a busy signal, do the other 3 also try to call the busy number , or is the software smarter than that, and puts them all for a re-try?

In the case of FaxSTF, I did read the documentation on this product and it appears to me that the collation (the so-called "batching") is being done manually by the administrator/user. So it looks to me like you submit a few faxes to that product and then you manually tell FaxSTF to collate them into one call before those are transmitted. In HylaFAX terms, then, this is all being done on the client-side... even on FaxSTF. To give you a HylaFAX version of the same procedure, it would be like submitting all of the jobs and then later, before the jobs are sent, for you to use something like faxalter to give them all a common time-to-send.


That's not exactly correct., you can do it "manually" but ,batching is performed by the faxsoftware,( we've been using it for over 8 years and it does batch, maybe not 100% reliably but close enough, but the support for different fax machines is poor)

It seems to batch just before the current job is going,it scans the queue for matching numbers. ( not really suitable for hylafax)
, it does not use timers to trigger jobs to pass into the send queue ( it seems to loop around the send queue looking at the time to send, sub-optimal, and not scaleable), but appears to sort internally via fax number, or perhaps , it has a quick look above & below the current job for other numbers that are the same.
like i said it's not 100% accurate , but it is close enough.


I had one of the programmers write a java daemon( unfortunatly thats 50mb with the jvm), that sits on the faxserver, it takes a look at the hylafax job queues & if the numbers are the same, alters the TTS, so that they are all the same for the same numbers. it's a hack , but it seems fairly effective, as long as the jobs are submitted with a delay.( this also could fix the redial issue) , that daemon went into service last night , and it does look good.

lee, I'm not looking for something that is 100%, just budget reduction, and I'm not happy with what happened at the start of this thread.
and just for the record, I am down 1 staff member as of last monday.


Thanks,

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*

Project hosted by iFAX Solutions