[Catalyst] Test server not releasing socket

Will Hawes info at whawes.co.uk
Thu Apr 27 12:22:37 CEST 2006


Matt S Trout wrote:
> Will Hawes wrote:
>> Will Hawes wrote:
>>> Matt S Trout wrote:
>>>> Will Hawes wrote:
>>>>> FreeBSD 4.10-STABLE, Catalyst 5.66:
>>>>>
>>>>> [Mon Apr 24 17:29:56 2006] [catalyst] [info] Application powered by 
>>>>> Catalyst 5.66
>>>>> Couldn't create daemon: Address already in use at 
>>>>> /usr/local/lib/perl5/site_perl/5.8.7/Catalyst/Engine/HTTP.pm line 135.
>>>>>
>>>>> admin at ds645# netstat -p tcp
>>>>> Active Internet connections
>>>>> Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
>>>>> ...
>>>>> tcp4       0      0  ds645.3000             XXX-XXX-XXX-XXX-nl.2500 
>>>>> TIME_WAIT
>>>> *cough*
>>>>
>>>> Notice that there's a foreign address there. Whatever that is had a connection 
>>>> to the socket at the time, meaning that when it got suddenly closed down it 
>>>> entered TIME_WAIT until a full double-close was completed.
>>>>
>>> That's me connecting to the test server via a web browser. I don't see 
>>> the problem if the server is running on the same machine as the web 
>>> browser used to test the app, only (as in this case) when they are on 
>>> separate machines.
>>>
>>> Does this mean if there are clients connected to the server, it will be 
>>> unable to restart until those clients disconnect/time out? I'd expected 
>>> (seemingly wrongly) that the test server would nuke even active 
>>> connections at shutdown time. Or is that not possible?
>>>
>> Or, phrased differently, is there any way I can prevent this error other 
>> than restarting the web browser every time I want to restart the test 
>> server?
> 
> You could submit a failing test (and if possible a fixup patch :) for this 
> issue. I don't think I've ever seen it myself.
> 

I'd be happy to, but:

1) The error seems only to occur when at least one remote client has 
connected to the test server (local client connections do not seem to 
trigger it). I can't see how to reproduce the remote client scenario in 
a test.

2) The problem is very intermittent - several restarts in succession 
sometimes work fine even after a remote client has connected. I could 
probably produce a test that would fail sometimes, but it wouldn't do so 
all the time.

These may be possible to overcome, but I need some guidance :)



More information about the Catalyst mailing list