[Glass] [3.3.1]: Waiting for a connection is blocked ... no timeout at all is considered

[Dale Henrichs via Glass]

Marten,

Are you reading code and drawing these conclusions or are you in a 
debugger or ???

Unless I'm mistaken the method that calls ZnServer>>serveConnectionOn: 
is in an infinite repeat loop and it looks like by default the accept 
will block for 5 minutes, then the timeout should fire and a new accept 
request will be launched ... which will give the SigAbort code a chance 
to run ...

So if you are not seeing the accept call kick out after 5 minutes (300 
seconds = 5 minutes right:) then perhaps there is a bug ... is that what 
is happening for you?

And it looks like GsSocket>>waitForAcceptFor: calls 
GsSocket>>waitForConnectionFor:ifTimedOut:..

Digging a bit more I see that SocketStreamSocket>>waitForAcceptFor: 
calls SocketStreamSocket>>waitForConnectionFor:ifTimedOut: is wired to 
calling `self accept` which does ignore the timeout .... Since GsSocket 
implements waitForConnectionFor:ifTimedOut:, I think that 
SocketStreamSocket>>waitForConnectionFor:ifTimedOut: should do:

   ^self self underlyingSocket waitForConnectionFor: timeout ifTimedOut: 
timeoutBlock

Could you try that out and confirm ... presumably the SocketStreamSocket 
code dates back to GemStone 2.4.x when perhaps 
GsSocket>>waitForConnectionFor:ifTimedOut: wasn't implemented?

Good catch ... let me know it it works ...

Dale

On 10/24/2016 01:23 PM, Marten Feldtmann via Glass wrote:

> This seems to become a different topic - I tried to change this and I 
> notice that I was not able to make it work.
>
>
> Some of my topaz/ZnServer tasks are handling only http-calls with 
> special URLs. It can happen, that these calls will be called over a 
> period if time (days or so) - in my client simulation tool these calls 
> were not called at all.
>
> As I understand the ZnServer, GsSocketStream and GsSocket code: the 
> ZnServer tasks are then simply blocked low level in the virtual 
> machine until a request comes in ... I would be surprised to see if 
> they really wake up if they get a SigAbort ...
>
> The whole logic in ZnServer>>serveConnectionOn: listeningSocket:
>
> ...
>
> socket := listeningSocket waitForAcceptFor: self acceptWaitTimeout.
>
> ...
>
> does not work: timeout is not considered and at the lowest level, that 
> API calls says: I'm blocking.
>
> Therefore the periodicTasks are not so executed periodically - ONLY 
> when a request is incoming from that listing socket.
>
> Seems to be strange ...
>
>
>
>> Marten Feldtmann via Glass <glass at lists.gemtalksystems.com> hat am 
>> 24. Oktober 2016 um 16:43 geschrieben:
>>
>> That's very interesting.
>>
>> This means, that I should introduce my own subclass of ZnServer and 
>> its #serveConnectionOn: (or the #noteAcceptWaitTimedOut) should be 
>> rewritten to make an empty transaction (with #beginTransaction and 
>> #abortTransaction) on a periodical base (15 seconds ?).
>>
>>
>
>> _______________________________________________ Glass mailing list 
>> Glass at lists.gemtalksystems.com 
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20161024/d2042268/attachment-0001.html>