Hi, That's interesting. I haven't seen it but it's interesting.
Just curious, when the systems is exhibiting this behavior and you try to bring up a browser and re-inact a testing scenerio what happens? Is the system still responsive? Can you duplicate the error by hand? When you get that error what is the user experience? I spend about as much time debugging testing tools as I do application systems. So I'm wondering what could be so different in 4.1.24 that would cause that. I think it's odd that it would goof up on the TCP because that's handled at a much lower level. It's also odd that the clients exit out instead of chalking it up as an error and restarting themselves. That just might be a limitation of your testing tool though. Check on the health of your testing tool (RAM, CPU) when it cracks up. I don't know what kind of system you are using but make sure to check the basics. Make sure you have forced the systems (and the testing tools and any switches in between) interfaces at 100 FDX (no auto-negogiate) and tune the TCP settings. That makes a world of difference. -e On Fri, 25 Jul 2003, McClure, Timothy J(IndSys, GE Interlogix) wrote: > We have a testsuite that sends 3 messages per second from 100 clients. > With Tomcat version 4.1.18 this test runs for 24 hours. With tomcat > 4.1.24 the clients all eventually exit with a socket connect error after > 2 hours. Does anyone know why this might be happening? Any help would > be greatly appreciated > > Tim McClure [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
