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] a quickie



* Lee Howard <faxguy@xxxxxxxxxxxxxxxx> [070208 21:23]:

> It's probably this:

> http://hylafax.cvs.sourceforge.net/hylafax/hylafax/faxd/faxQueueApp.c%2B%2B?view=log#rev1.39
> 
> Patch here:

> http://hylafax.cvs.sourceforge.net/hylafax/hylafax/faxd/faxQueueApp.c%2B%2B?r1=1.38&r2=1.39&view=patch

> The problem was that the unblockDestJobs function was unaware that 
> di.getBlocked() actually removed the job from the blocked list.  
> Consequently, if the case arose that it couldn't place that job on the 
> run queue (much more likely if batching were disabled, I'd think) then 
> unblockDestJobs would erroniously not replace the job back onto the 
> blocked list.  So from then on that job would have "disappeared" from 
> faxq altogether until faxq were stopped and restarted when it creates 
> the lists anew from the sendq files on disk.

This was fixed in July 2006 in HylaFAX CVS, before 4.3.1 was released:
	http://hylafax.bkbits.net:8080/HylaFAX/?PAGE=cset&REV=PatchSet-1278
which contains the following hunk in faxd/faxQueueApp.c++:

	@@ -2260,20 +2277,24 @@ faxQueueApp::unblockDestJobs(Job& job, D
	     Job* jb;
	     u_int n = 1;
	     while ( (jb = di.nextBlocked()) ) {
	-	if ( isOKToCall(di, job.getJCI(), n) )
	+	if ( isOKToCall(di, jb->getJCI(), n) )
		{
		    if (!di.supportsBatching()) n++;
		    FaxRequest* req = readRequest(*jb);
	-	    if (req) {
	-		req->notice = "";
	-		updateRequest(*req, *jb);
	-		delete req;
	+	    if (! req) {
	+		setDead(*jb);
	+		continue;
		    }
	+	    req->notice = "";
	+	    updateRequest(*req, *jb);
	+	    delete req;
		    setReadyToRun(*jb, jobCtrlWait);
		} else
		{
	- 	    traceJob(job, "Continue BLOCK, current calls: %d, max concurrent calls: %d", 
	- 		di.getCalls(), job.getJCI().getMaxConcurrentCalls());
	+ 	    traceJob(*jb, "Continue BLOCK, current calls: %d, max concurrent calls: %d", 
	+ 		di.getCalls(), jb->getJCI().getMaxConcurrentCalls());
	+	    di.block(*jb);
	+	    break;
		}
	     }
	 }

So if jobs are still remaining blocked, it's not that case.  This case
(fixed prior to 4.3.1) would lose a single job every time the unblocking
happened.  Peter seems to describe that *all* blocked jobs are being
lost.

Peter, if the jobs live past their kill time (-k value in sendfax), do
they time out properly and get removed, or are they completely lost
forever?   If you could set ServerLogging to 0xFFFFFF in
$SPOOL/etc/config and reproduce it with 4.3.1, I would love to see the
syslog message for FaxQueuer.

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




Project hosted by iFAX Solutions