Re: mass-check --server bug?

["Daryl C. W. O'Shea" <sp...@dostech.ca>]

Justin Mason wrote:
> Daryl C. W. O'Shea writes:
>> Justin Mason wrote:
>>> Daryl C. W. O'Shea writes:
>>>> Justin Mason wrote:
>>>>
>>>>> This looks a lot like an infinite loop.  The output files haven't been
>>>>> written to in several hours.  Has anyone ever seen this?
>>>> Are one of the clients running in --cs_paths_only mode?
>>> nope.
>> It looks like the message numbers the clients are returning don't match 
>> what the server thinks it issued or, probably more likely, the client is 
>> actually returning the message results.  It doesn't appear to be an 
>> issue with missing messages as they would be re-issued to the client as 
>> soon as it posted the results.  In this case its actually waiting for 
>> them to timeout before re-issuing them.
>>
>> Are there any zero-length messages in the corpus?  Zero-length messages 
>> WILL cause problems.  I can't remember if this was one of the failure 
>> modes (I think I've only seen the clients hang on zero-length messages).
> 
> We should be able to avoid that, surely?!

Of course, just like anything else. :)


> Here's a log from a mass-check session.  It again gets stuck nearly at
> 100% with a set of 676 and 728 messages.

Any logs from the client at 140.211.11.138 to go with this?  The client 
logs will likely provide a better clue to why this is happening than the 
server logs.

Daryl

Re: mass-check --server bug?

["Kevin A. McGrail" <ke...@thoughtworthy.com>]

> For anybody following along who cares... it turned out it was zero-length 
> messages causing the problem.  mass-check now handles this.

Phew.  I was worried I had something setup wrong on the new mass-check 
machine! 

Re: mass-check --server bug?

["Daryl C. W. O'Shea" <sp...@dostech.ca>]

Daryl C. W. O'Shea wrote:
> Justin Mason wrote:
>> Daryl C. W. O'Shea writes:
>>> Justin Mason wrote:
>>>> Daryl C. W. O'Shea writes:
>>>>> Justin Mason wrote:
>>>>>
>>>>>> This looks a lot like an infinite loop.  The output files haven't 
>>>>>> been
>>>>>> written to in several hours.  Has anyone ever seen this?
>>>>> Are one of the clients running in --cs_paths_only mode?
>>>> nope.
>>> It looks like the message numbers the clients are returning don't 
>>> match what the server thinks it issued or, probably more likely, the 
>>> client is actually returning the message results.  It doesn't appear 
>>> to be an issue with missing messages as they would be re-issued to 
>>> the client as soon as it posted the results.  In this case its 
>>> actually waiting for them to timeout before re-issuing them.
>>>
>>> Are there any zero-length messages in the corpus?  Zero-length 
>>> messages WILL cause problems.  I can't remember if this was one of 
>>> the failure modes (I think I've only seen the clients hang on 
>>> zero-length messages).
>>
>> We should be able to avoid that, surely?!
> 
> Of course, just like anything else. :)

For anybody following along who cares... it turned out it was 
zero-length messages causing the problem.  mass-check now handles this.

Daryl