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

Reply via email to