Myrna van Lunteren wrote:
Could this really be a bug, if the server doesn't start in over five
minutes, even on a slow machine?
Dan.
I guess it could be...But, wouldn't it just never come up, then?
No idea, that's the definition of a bug, unexpected/unexplained
behaviour. :-)
DERBY-2616 indicates the problem in a slow starting server might be due
to the tcp/ip state TIMED_WAIT. However the fix there was just to
increase the default wait time (which actually makes the tests run
slower). If TIMED_WAIT is the problem then tcp/ip and the Java Socket
api provides ways to get around it. Using the Socket.setReuseAddress()
call and SocketSessionConfig.setReuseAddress().
Maybe the real fix to this issue is to use setReuseAddress() in some
way, maybe one or a combination of:
- provide a property to configure setReuseAddress for the server
- set that property in the decorator that starts the network server
- always set setReuseAddress(true) for localhost (unlikely to lose
network packets talking to localhost)
- always set setReuseAddress(true) (possibly a bad idea since
TIMED_WAIT is there for a reason but I haven't looked in enough detail)
E.g. http://osflash.org/pipermail/red5devs_osflash.org/2007-May/002857.html
DERBY-1966 indicates there does seem to be a bug if some network server
resources are held onto after the server is shutdown.
The problem I see isn't with just starting network server, but more
with running the tests...
And I could get the test to pass when I increased both sleep and wait time...
Actually, it seemed to me on the one machine I'm currently thinking
of, it was more the shutting down that took a very long time...It
appears to me on this machine deleting of files takes especially long,
could that be related?
Do the tests have some time based wait for the shutdown? I thought it
was only for the server start, can you specify which values you want to
make into properties.
Dan.
