Il giorno 03/mag/2012, alle ore 03:22, Ryan Showalter ha scritto:

> I've attached a log of the issue happening.  You can see it's trying
> to execute the same spool job over and over even though there are ~300
> jobs in the queue.
> 
> Ryan-

can you send an ls -l output of the spooldir ?

Looks like for some reason the scandir is ignoring your others 299 files :(

> 
> 
> On Wed, May 2, 2012 at 6:10 PM, Ryan Showalter <[email protected]> wrote:
>>>> I've noticed that with recent version of uWSGI, the spooler does not
>>>> treat jobs as it used to. Before, if 10 jobs were in the queue and job
>>>> 1 failed, the spooler would proceed to try job 2 and then job 3, etc.
>>>> But recently, I've noticed that if job1 fails, it will continue to try
>>>> and execute job1 completely ignoring jobs 2-10 until job1 is
>>>> successfully processed.  Here is my config:
>>> 
>>> 
>>> This is pretty strange, as the spooler is not supposed to work in that way.
>>> 
>>> How the job is failing ? I mean, it is returning a SPOOL_RETRY or an 
>>> Exception ?
>> 
>> I'm noticing this issue when the spooler is failing with an Exception.
>>  I have not yet tried a test case with SPOOL_RETRY.
>> 
>>> The spooler can only destroy objects created by him, if the code you are 
>>> running cannot be freed it will leak.
>>> I suggest you to use
>>> 
>>> sys.gettotalrefcount()
>>> 
>>> before exiting the function to see if your callable is leaking
>> 
>> Sounds good, i'll implement this and get back to you with the results.
> <uwsgi_spooler_issue.txt>_______________________________________________
> uWSGI mailing list
> [email protected]
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

--
Roberto De Ioris
http://unbit.it
JID: [email protected]

_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to