S, Sven Van Caekenberghe piše:
> Janko Mivšek wrote:
>> If I recall others have also problems with sockets in Pharo, so here is
>> the my current image, which:
>>
>> - has 105 Sockets open, mostly waiting
>> - has also >105 processes open
>> - consumes 100% cpu
>> - on aSocket close responds with primitive failure
>> - image is workable, I can browse etc.
>>
>> - Pharo1.2.2a on Linux
>>
>> Sockets are waiting on Socket>>waitForConnectionFor:ifTimeOut:
> Is that number of open sockets and processes by design or not ? If they keep
> coming back, you must be creating them. Your application has to keep these
> (expensive) resources under control to start with.
This is Swazoo accepting the connections, probably from web spiders. But
also promptly closing them, because there are no instances of
HTTPConnection hanging around.
> Long running Seaside images seem to be fine and they are using sockets and
> processes a lot.
>
> Socket have #close and #destroy, there might be a difference.
Swazoo uses Sport portability layer and its SpSocket actually call
#closeAndDestroy on underlying Socket. Obviously this method don't
manage to actually close nor destroy the socket.
> I think that part of the cleanup of sockets is delayed (using finalization)
> and needs some GC work to complete. GC policies might be involved as well as
> weak datastructures.
This could be a way to proceed. How to diagnose that?
> I am also interested in knowning the practical upper bound for open sockets
> and number of processes.
>From Henrik pointer it seems that in 1.2 one-click there can be up to
512 semaphores by default. Every socket need three, so up to 170 sockets
can be open at once. Semaphore limit can be increased , to say 1024*3
for 1024 sockets by:
Smalltalk vmParameterAt: 49 put: 1024*3
Another limit on Linux is namely a default 1024 limit of sockets per a
whole machine. This one can also be increased
Best regards
Janko
--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
