Paul, On 15 May 2012, at 20:50, Paul DeBruicker wrote:
I ran into an out-of-external semaphores error when testing the Tropo API. It uses ZnEasy to post data to their api servers.
Any idea at what rate you are posting, just a ballpark figure ?
I know I can raise the semaphore limit by running:
Smalltalk vm maxExternalSemaphoresSilently: 3000.
then saving. But I wondered if changing ZnClient>>#close to this:
close "Close any HTTP network connection that I might have kept open."
connection ifNotNil: [ connection close: self isOneShot. connection := nil. state := #closed ]. lastUsed := nil
And then adding these two methods:
ZdcAbstractSocketStream>>#close: close: andDestroy "Close the stream, flush if necessary"
self flush. socket isNil ifTrue: [ ^ self ]. self socketClose: andDestroy. socket := nil
ZdcAbstractSocketStream>>#socketClose: andDestroy andDestroy ifTrue: [ socket closeAndDestroy ] ifFalse: [ socket close ]
might enable ZnClient to clean up after it issues 'one shot' requests in a safe manner.
I can submit a change if so ( an a test! ).
Thanks Paul
I am assuming you are on Pharo 1.3 or 1.4. But since you are talking about ZdcAbstractSocketStream you have Zodiac loaded as well. Are you using HTTPS then ? Because #close: does not exist on regular SocketStreams. If you are talking about regular HTTP, then you must have loaded the somewhat older/experimental ZdcNetworkingUtils, and are not using regular SocketStreams but ZdcOptimizedSocketStreams. Which is brave since this is something I am not doing myself ;-) Anyway, the close and/or destroy discussion puzzles me as well. When running all unit Zn tests I sometimes do see some cleanup happening in delayed fashion under finalization. I have not yet had problems with that. Note that ZnClient under #beOneShot behavior asks the other side to close as well. Socket>> closeAndDestroy does a wait of up to 20 seconds... Anyway, it is a good issue, but we should understand it better first I think. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill