Re: [hylafax-users] Audit hook not getting all Job events

[Dominique dHotman <dominique@xxxxxxxxxxxxxx>]

Sorry what I meant by retry state is that we notify our processing application via the audit hook script of the job "state"  and from our processing applications point of view there are only 3 job states; that is what's interesting to the user.  The 3 states or 3 things we notify the processing application about are the job was sent successfully, the job failed or the job is going to be retried.

At the moment we are just looking through the job file and are thinking of making use of the numeric value of "state".  Would there be any benefit of getting this information from the scheduler instead (i.e. connecting using the protocol).

thanks

On Wed, Jul 14, 2010 at 4:52 PM, Aidan Van Dyk <aidan@xxxxxxxx> wrote:

* Dominique dHotman <dominique@xxxxxxxxxxxxxx> [100714 10:29]:

> Hi Aidan,
>
> Just a question on some processing logic.  In the current version of our
> audit hook we set a failed, success or retry state based on the audit event
> fired.  And this state along with other information retrieved from the job
> file is inserted into our database.  This state decision is something that
> we decided on after looking at the event set for a whole lot of different
> fax jobs and it's worked pretty well for the most part.
>
> Having said that I have now found out about this "state" variable in the job
> file which is obviously a far superior manner of determining what state the
> job is in.  So would it be better if moved this failed, success decision to
> the job_done event and use this state variable in the job file?

*I* would absolutely use the job state.  If you're connecting to a
HylaFAX server and using the protocol, you get nice "state names"... If
you're groveling through internal data structures yourself (i.e. the
qfiles) you only get internal integers.  You can see what the current
"integer values" mean by looking at the code:
       http://git.hylafax.org/HylaFAX?a=blob;f=faxd/FaxRequest.h;hb=6.0

Look for the state_* enum values (around like 85), which are currently:
 85     enum {                      // job scheduling state
 86         state_undefined = 0,    // undefined state (should never be used)
 87         state_suspended = 1,    // not being scheduled
 88         state_pending   = 2,    // waiting for time to send
 89         state_sleeping  = 3,    // waiting for scheduled timeout
 90         state_blocked   = 4,    // blocked by concurrent activity
 91         state_ready     = 5,    // ready to be go, waiting for resources
 92         state_active    = 6,    // actively being processed
 93         state_done      = 7,    // processing completed with success
 94         state_failed    = 8     // processing completed with a failure
 95     };

>  Additionally how would you recommend we best handle notification of this
> retry state?

What do you mean by the "retry state"?  There is no state for retried...
a "retried" job is either in state_sleeping or state_ready, just a newly
submitted job.

But depending on what you want to do when you find out a job is going to be
retried, you don't need to do anything  If you're doing basic job tracking, all
you really care about are:
 undefined/suspended:  Job isn't actually being scheduled for sending, it's either
       not completed, or not submitted properly
 done/failed: Final states, job completed, nothing new will happen
 everything else: Job's in the queue and will eventually reach the done/failed state

a.


--
Aidan Van Dyk                                             aidan@xxxxxxxx
Senior Software Developer                          +1 215 825-8700 x8103
iFAX Solutions, Inc.                                http://www.ifax.com/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFMPc87uVxNPsxNPScRAlotAJ4zkZDkpYldDBOrcsBhXV+S/3NO+ACgs1NQ
V0lmzievV0A2la9torYetLk=
=C+r0
-----END PGP SIGNATURE-----