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

[Aidan Van Dyk <aidan@xxxxxxxx>]

* 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/

Attachment: signature.asc
Description: Digital signature