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

[Dale Henrichs via Glass]

Whoops my previous guess was a bit wrong ... and it looks like I 
extended the GsSocket protocol when I ported Zodiac to GemStone and I'm 
sitting in an image with Zodiac installed ... sorry about that:

instance for GsSocket--*zodiac-gemstone-core
--------------------
closeAndDestroy
connectTo:port:waitForConnectionFor:
dataAvailable
isValid
listenOn:backlogSize:
localPort
readInto:startingAt:for:
readyForRead
receiveDataSignallingTimeout:into:startingAt:
sendData:count:
sendSomeData:startIndex:count:
waitForAcceptFor:
waitForConnectionFor:ifTimedOut:
waitForDataFor:
waitForDataFor:ifClosed:ifTimedOut:
waitForNonBlockingReadActivityUpToMs:
writeFrom:startingAt:for:

and for Zodiac, GsSocket>>waitForConnectionFor:ifTimedOut: is 
implemented ... so the real fix is to move these methods into 
SocketStream and/or make SocketStream obsolete, ... since I know I 
didn't create an SecureSocketStream class the need for SocketStream is 
probably fading away ...

Created an issue[1] for moving all of these methods into zinc and this 
issue[2] for your original problem

[1] https://github.com/GsDevKit/zinc/issues/81

[2] https://github.com/GsDevKit/zinc/issues/82

On 10/24/2016 02:22 PM, Marten Feldtmann via Glass wrote:
>
> And I think, that this can be fixed by:
>
> SocketStreamSocket>>waitForConnectionFor: timeout ifTimedOut: timeoutBlock
>
> |waitForConnectionFor: timeout ifTimedOut: timeoutBlock|
> |    "Wait up until the given deadline for a connection to be 
> established. Return true if it is established by the deadline, false 
> if not."|
>
> |    | aGsSocketOrNil ||
>
> |    aGsSocketOrNil := self underlyingSocket acceptTimeoutMs: timeout 
> * 1000.|
> |    aGsSocketOrNil isNil ifTrue:[^timeoutBlock value].|
> |    ^ SocketStreamSocket onNativeclientSocket: aGsSocketOrNil for: self|
>
>> Marten Feldtmann via Glass <glass at lists.gemtalksystems.com> hat am 
>> 24. Oktober 2016 um 22:23 geschrieben:
>>
>> 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
>
>
> _______________________________________________
> 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/751efee5/attachment.html>