Mm... that seemed to fix it.  It was 256 so I bumped it up to 1024 and 
didn't encounter the problem again.

Thanks John,

Julian

John M McIntosh wrote:
> 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
> ======================================================================== 
> ===
> 
>