"select: Bad file number"

John M McIntosh johnmci at smalltalkconsulting.com
Tue Dec 16 04:41:39 UTC 2003


MMm
ulimit -n
should show you the maximum number of file handles you are allowed.  
That might be a low number? Change it and see what
happens. If the socket is being closed/destroyed as part of weak array  
processing you could get quite a number stale sockets and
run into a issue.

MMm On the other hand I see you say you've tried it with 1000 clients,  
I think the default limit is 1024, so you'll hit the limit really  fast  
I'm sure.

Lazy, I've not got a project builder project open so I can't quickly  
see if say a 1000 is some magic array upper bound issue in the
socket or aio.c logic.

However I'd suggest you fiddle with ulimit first and see what happens.

On Dec 15, 2003, at 8:31 PM, Julian Fitzell wrote:

> I'm doing some load testing on Seaside at work and I wrote up some  
> code that creates a lot of connections to the server.  If I have 100  
> simultaneous Processes going, it seems to be ok (at least in terms of  
> the bug I'm about to describe).  When I tried it with 1000  
> simultaneous client Processes, however, after about a minute and a  
> half the server image starts pumping out "select: Bad file number" to  
> the console as quickly as its little legs will let it.
>
> Now I assume this is related to running out of sockets or something,  
> but does this trigger anything for anybody?  Does this represent some  
> problem in the VM or in the Seaside code or is it just a fact of life?  
> Seems like we should be able to handle it better somehow...
>
> Both images are 3.6-g2 VM's, the client on linux and the server on  
> solaris.
>
> Any help appreciated,
>
> Julian
>
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===




More information about the Squeak-dev mailing list