I was just about to report this very fault... We use xmlrpc between our server and loadtest agents. As the OP points out, the runners threadgroup seems to remains active even after calling
Webserver.shutdown() If you wait long enough on Win2K, the threads evenutally do shutdown (but print stacktraces to the console). On Linux, it seems like they remain up indefinitely - any attempt to form new connections over the same ports results in a 'Address already in use' type runtime exception. This reminds me of another improvement I'd like to see. Currently, the WebServer class dumps exceptions to the console during execution. This looks really bad if the console output is being captured to a report. Is there any way this could be either: a) Configurable based on XmlRpc.debug like I've seen in some other parts of the code. b) Better yet, allow for some installable 'error handler' that allows the exceptions to be dealt with in an application specific manner. Cheers --Richie. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel Rall > Sent: 20 February 2002 02:13 > To: [EMAIL PROTECTED] > Subject: Re: Thread Behavior - Deadlock > > > "EXT-Raiteri, Ashley L" <[EMAIL PROTECTED]> writes: > > > As a newbie I am embarrassed to ask this question: > > but, is everyone Certain that the current implementation with > Thread Groups, > > and using the Shutdown method will actually terminate an instantiated > > WebServer object? > > I am not certain. > > > Our client instantiates a Webserver to process it's xmlrpc > calls, and then > > when the client is told to shutdown, > > it calls the Shutdown method in WebServer. > > But looking my debugger it doesn't look like the Thread created by the > > Webserver ever terminates. > > I have verified that the Webserver run methods does complete > and exit, but > > for some reason there seems to be something else waiting.... > > If you would file an issue in the issue tracker > (http://nagoya.apache.org/bugizlla), and attach code and describe the > steps to reproduce the problem, someone will take a look at it. > > Dan > ________________________________________________________________________ E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ________________________________________________________________________
