Re: [hylafax-users] job group rules

[Christopher Curtis <ccurtis@aet-usa.com>]

On Mon, 27 Aug 2001, Lee Howard wrote:

> At 05:40 PM 8/27/01 -0400, Christopher Curtis wrote:
> >
> >I have a situation in which jobs submitted as a single group (ie, with
> >multiple -d parameters) must be sent sequentially, but not limited to a
> >single modem.
[...]
> >Is there a way to say 'send this group exclusive of itself', while still
> >mainting a full modem pool sending other groups, or sitting idle as
> >necessary?
> 
> Maybe it's me, but this is very confusing.  Mostly because "group" in
> HylaFAX refers to a set of modems, and not a set of jobs.

Firstly, let me apologize for being needlessly vague.  Also, let me
request a Cc on all replies since I'm not subscribed.  Next, let me thank
you for your help, and finally, let me clarify.

I am running the 4.0 series HylaFAX on a Linux machine with (currently)
two modems attached to it.  We have a web interface for submitting jobs,
and a number of billing accounts which are specified as part of the dial
string.  The problem is that each billing account can only have one active
job at a time, else it fails.

Now, according to the manpage for sendfax, I can specify a host and modem
for a particular 'job group' - HylaFAX "understands" 'job identifiers' and
'job groups'.   This would (in theory) allow me to bind one job group to
one modem, but it makes me put all the load balancing smarts in my
scripts.  I can random round-robin the 'job groups' to a modem, but there
may be very small and very large jobs.

The problem I am having now is that the jobs are failing because both
modems are trying to send faxes to the same billing account and are
getting an error in return.  I'm trying to find a way to make each group
remain sequential within the members of the group, but to continue the
existing modem pool balancing (so tying a job group to a modem is not a
requirement, but may be a solution, assuming the job group can jump to
another modem if it becomes free).

> From what I understand you basically want multiple fax broadcasts to occur
> simultaneously over multiple modems, distributing individual fax jobs
> equally over the modem pool such that no modem is left idle and no two
> modems transmit the same broadcast at the same time.

Yes, essentially.  One modem may sit idle due to the sequential nature of
things (eg, one large job), but the other modem could in theory start
dialing as soon as the first one is finished and is being reinitialized.
Again, this is not a requirement, just a way to save a few seconds.

> Frankly, this last timing constraint really isn't possible, without
> providing for known modem idle times so that slow jobs have time to catch
> up.  If idle time is minimized, then eventually the synchronization of jobs
> is lost, and you can conceivably have the two modems send the same
> broadcast at the same time (to different destinations, of course).

Timing is not critical - it is just a general goal to keep both modems
busy as much as possible.

> And, from what else I understand, the process seems a bit too complex to be
> realistic.

It shouldn't be that difficult ... the basic logic is simply "Do not send
a member of a job group if another member of that group is currently in
the 'R' state" ... maybe it will introduce a new state - 'b', similar to
(B)locked by concurrent job, but instead (b)locked by concurent group job.

If the logic doesn't exist now (in 4.0), there isn't too much I can do
about it since the system generally works (it works 100% until we add a
second modem) and it's in a "not to be touched" state until the whole
system is upgraded.  Goal 1: make it work.  Step 2: start optimization.
Any suggestions to upgrade fall on deaf ears  :(

Thanks again,
Christopher



____________________ HylaFAX(tm) Users Mailing List _______________________
 To unsub: mail -s unsubscribe hylafax-users-request@hylafax.org < /dev/null