You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by "EXT-Raiteri, Ashley L" <as...@boeing.com> on 2002/02/20 18:24:47 UTC
RE: Thread Behavior - Deadlock -one extra part
sorry, forgot about one other part
********** - Webserver.java Webserver.run()
finally
{
System.err.println("Closing XML-RPC server socket");
try
{
serversSocket.close();
serverSocket = null;
}
catch (IOException ignore)
{}
++ listner = null;
++ runners = null;
}
}
***********************************
-----Original Message-----
From: EXT-Raiteri, Ashley L [mailto:ashley.l.raiteri@boeing.com]
Sent: Wednesday, February 20, 2002 9:18 AM
To: 'rpc-user@xml.apache.org'; 'rpc-dev@xml.apache.org'
Subject: RE: Thread Behavior - Deadlock
I couldn't file an issue at ISSUE tracker because bugzilla still doesnt have
an xmlrpc project yet.
below is a patch I suggested to hannes a couple of days ago.
Obviously I beleive there are better solutions than the quik patch i have
posted here. Ideally,
the NORMAL method for making threads terminate -
as shown by Eckel ("thinking in java -p.874) &
Oreilley's Oaks & Wong (Java Threads 2nd ed - p. 160)
A semaphore would be best:
This implementation is shown after the FIRST one below:
(Also, in BOTH patches, a BETTER EXCEPTION catch is needed - i just am too
ignorant to know what to
put in the catch clauses for these kinds of try blocks!)
*****************************
qUIKPATch
*****************************
I am discovering that when I call shutdown on my instantiated Webserver,
It does not completely exit all threads.
I tried a minor modification to shutdown
********** - Webserver.java Shutdown()
if (listener != null)
{
++ try {
++ runners.interrupt();
++ }
++ catch (Exception er)
++ {
++ System.err.println ( er);
++ er.printStackTrace();
++ }
Thread l = listener;
listenr = null;
l.interrupt();
**********
which required adding a safety clause in Runner.run
********** Webserver.java Runner.run()
-- while (Thread.currentThread() == thread)
++ while (con != null && Thread.currentThread() == thread)
**********
This seemed to solve my problem, which was that the thread created by
Webserver would not go away!
Any ideas...was I doing something incorrectly in the first place?
Or is this a bug that should be fixed?
ignorantly,
ashley raiteri
*****************
*****************************
qUIKPATch
*****************************
********** - Webserver.java Shutdown()
if (listener != null)
{
++ ThreadGroup r = runners;
++ runners = null;
++ try {
++ r.interrupt();
++ }
++ catch (Exception er)
++ {
++ System.err.println ( er);
++ er.printStackTrace();
++ }
Thread l = listener;
listenr = null;
l.interrupt();
********** Webserver.java Runner.run()
-- while (Thread.currentThread() == thread)
++ while (runners && (Thread.currentThread() == thread))
**********
THERE is no Need to improve the Connection.run thread, because it does not
perform a While loop!
stuggling,
ashley raiteri
-----Original Message-----
From: dlr@apache.org [mailto:dlr@apache.org]
Sent: Saturday, August 11, 2001 3:13 AM
To: xml-rpc-cvs@apache.org
Subject: cvs commit: xml-rpc/src/java/org/apache/xmlrpc WebServer.java
dlr 01/08/11 03:13:07
Modified: src/java/org/apache/xmlrpc WebServer.java
Log:
* Added createServerSocket() factory method (for subclassing by
SecureWebServer).
* Refactored setupServerSocket() method to initialize the WebServer's
listener to the socket created by createServerSocket(). Also set a
timeout on the socket so it doesn't block forever when accept() is
called (more on this below).
* Since SO_TIMEOUT is now being set on our listener socket, we can
actually shutdown properly now. An InterruptedIOException will be
thrown every 4 seconds while the listener is blocking on accept(). If
the server has been told to shutdown, this will allow it to actually
happen before another client connection comes in. This bug was
originally reported by Ilkka Priha <ip...@surfeu.fi>, and was fixed
by myself long ago (while it was still @ Helma):
"The helma webserver shutdown method sets a listener acting as a flag
to null and calls interrupt() for the thread, but blocking I/O
operations don't care about thread interrupts. By default, the server
socket accept() method waits forever or until the socket is closed. I
think that the server socket should either have a preset SO_TIMEOUT
interrupting I/O waits at regular intervals or the shutdown() method
should simply close the server socket."
* Formatting cleanup.
Revision Changes Path
1.3 +34 -6 xml-rpc/src/java/org/apache/xmlrpc/WebServer.java
Index: WebServer.java
===================================================================
RCS file: /home/cvs/xml-rpc/src/java/org/apache/xmlrpc/WebServer.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -u -r1.2 -r1.3
--- WebServer.java 2001/08/06 01:36:53 1.2
+++ WebServer.java 2001/08/11 10:13:07 1.3
@@ -64,6 +64,7 @@
*
* @author <a href="mailto:hannes@apache.org">Hannes Wallnoefer</a>
* @author <a href="mailto:jvanzyl@apache.org">Jason van Zyl</a>
+ * @author <a href="mailto:dlr@finemaltcoding.com">Daniel Rall</a>
*/
public class WebServer
implements Runnable
@@ -162,10 +163,31 @@
start();
}
- public void setupServerSocket(int port, int x, InetAddress add)
+ /**
+ * Factory method to manufacture the server socket. Useful as a
+ * hook method for subclasses to override when they desire
+ * different flavor of socket (i.e. a <code>SSLServerSocket</code>).
+ *
+ * @exception Exception Error creating listener socket.
+ */
+ protected ServerSocket createServerSocket(int port, int backlog,
InetAddress add)
+ throws Exception
+ {
+ return new ServerSocket(port, backlog, add);
+ }
+
+ /**
+ * Initializes this server's listener socket with the specified
+ * attributes. The <code>createServerSocket()</code> method can
+ * be overridden to change the flavor of socket used.
+ *
+ * @see #createServerSocket(int port, int backlog, InetAddress add)
+ */
+ public void setupServerSocket(int port, int backlog, InetAddress add)
throws Exception
{
- this.serverSocket = new ServerSocket (port, x, add);
+ serverSocket = createServerSocket(port, backlog, add);
+ serverSocket.setSoTimeout(4096);
}
public void start()
@@ -285,6 +307,11 @@
else
socket.close ();
}
+ catch (InterruptedIOException checkState)
+ {
+ // Timeout while waiting for a client (from
+ // SO_TIMEOUT)...try again if still listening.
+ }
catch (Exception ex)
{
System.err.println(
@@ -304,7 +331,9 @@
System.err.println( "Error accepting XML-RPC connections (" +
exception + ").");
}
- finally { System.err.println("Closing XML-RPC server socket.");
+ finally
+ {
+ System.err.println("Closing XML-RPC server socket.");
try
{
serverSocket.close();
@@ -312,8 +341,8 @@
}
catch (IOException ignore)
{}
- } }
-
+ }
+ }
/**
* Stop listening on the server port.
@@ -599,4 +628,3 @@
}
}
}
-
-----Original Message-----
From: Richie McMahon [mailto:richie.mcmahon@digitalbridges.com]
Sent: Wednesday, February 20, 2002 1:24 AM
To: rpc-user@xml.apache.org
Subject: RE: Thread Behavior - Deadlock
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: dlr@despot.finemaltcoding.com
> [mailto:dlr@despot.finemaltcoding.com]On Behalf Of Daniel Rall
> Sent: 20 February 2002 02:13
> To: rpc-user@xml.apache.org
> Subject: Re: Thread Behavior - Deadlock
>
>
> "EXT-Raiteri, Ashley L" <as...@boeing.com> 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.
________________________________________________________________________