You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Ilkka Priha <ex...@nokia.com> on 2001/03/16 14:35:45 UTC
XmlRpc service not shutting down
The XmlRpc service seems to leave some socket listeners/non-daemon threads
running when shutting down services. Is it possible to pass a shutdown message
to the server part by implementing Turbine's shutdown() callback in the service?
-- Ilkka
[mailto:ext-ilkka.priha@nokia.com]
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: XmlRpc service not shutting down
Posted by Daniel Rall <dl...@finemaltcoding.com>.
This patch is finally in XML-RPC CVS (checked in it a few minutes
ago).
> > -----Original Message-----
> > From: dlr@despot.finemaltcoding.com
> > [mailto:dlr@despot.finemaltcoding.com]On Behalf Of Daniel Rall
> > Sent: Saturday, March 17, 2001 18:59
> > To: xmlrpc@helma.org
> > Cc: turbine-dev@jakarta.apache.org
> > Subject: Re: XmlRpc service not shutting down
> >
> >
> > [helma.org guys, please CC the Turbine list on any responses...thanks!]
> >
> > "Ilkka Priha" <ip...@surfeu.fi> writes:
> >
> > > Sorry, didn't help. 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.
> >
> > Ah, indeed. Nice description of the problem--so nice, in fact, that I've
> > attempted an implementation:
> >
> > diff -u
> > /home/dlr/src/xmlrpc-java/src/helma/xmlrpc/WebServer.java-ORIG
> > /home/dlr/src/xmlrpc-java/src/helma/xmlrpc/WebServer.java
> > ---
> > /home/dlr/src/xmlrpc-java/src/helma/xmlrpc/WebServer.java-ORIG
> > Sat Mar 17 08:49:13 2001
> > +++ /home/dlr/src/xmlrpc-java/src/helma/xmlrpc/WebServer.java Sat
> > Mar 17 08:49:13 2001
> > @@ -76,14 +76,15 @@
> > /**
> > * Creates a Web server at the specified port number and IP address.
> > */
> > - public WebServer (int port, InetAddress add) throws IOException {
> > + public WebServer (int port, InetAddress addr) throws IOException {
> > this.port = port;
> > xmlrpc = new XmlRpcServer ();
> > accept = new Vector ();
> > deny = new Vector ();
> > threadpool = new Stack ();
> > runners = new ThreadGroup ("XML-RPC Runner");
> > - this.serverSocket = new ServerSocket (port, 50, add);
> > + serverSocket = new ServerSocket (port, 50, addr);
> > + serverSocket.setSoTimeout (8192);
> > listener = new Thread (this, "XML-RPC Weblistener");
> > listener.start();
> > }
> > @@ -179,6 +180,8 @@
> > // new Connection (socket);
> > } else
> > socket.close ();
> > + } catch (InterruptedIOException checkState) {
> > + // Timeout waiting for a client...try again if still
> > listening.
> > } catch (Exception ex) {
> > System.err.println("Exception in XML-RPC listener
> > loop (" + ex + ").");
> > } catch (Error err) {
> >
> > In the above patch, I worry about how clients will react during the
> > short period where the WebServer does not have a ServerSocket accepting
> > connections. Additionally, the ~8 sec. SO_TIMEOUT wait time was guess.
> >
> > Thoughts?
> > --
> >
> > Daniel Rall <dl...@collab.net>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: XmlRpc service not shutting down
Posted by Ilkka Priha <ex...@nokia.com>.
There is another problem also. Now we can stop the socket listener, thanks
to Daniel, by breaking the I/O wait by opening one client connection after
the shutdown() call. However, also the runners in the thread pool are
non-daemon threads waiting forever to get new connections to handle.
It would be good if a thread pool implementation supported an interruption
mechanism. There is a superb open source Java concurrency package available
at
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.h
tml
by Doug Lea, the writer of Concurrent Programming in Java. That package
contains an efficient solution for almost all concurrency problems,
including thread pools, schedulers, locks, queues, barriers, semaphores,
etc. I've used the package a lot and can recommend it to everyone planning
to program multi-threaded Java applications :-)
-- Ilkka
[mailto:ext-ilkka.priha@nokia.com]
> -----Original Message-----
> From: dlr@despot.finemaltcoding.com
> [mailto:dlr@despot.finemaltcoding.com]On Behalf Of Daniel Rall
> Sent: Saturday, March 17, 2001 18:59
> To: xmlrpc@helma.org
> Cc: turbine-dev@jakarta.apache.org
> Subject: Re: XmlRpc service not shutting down
>
>
> [helma.org guys, please CC the Turbine list on any responses...thanks!]
>
> "Ilkka Priha" <ip...@surfeu.fi> writes:
>
> > Sorry, didn't help. 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.
>
> Ah, indeed. Nice description of the problem--so nice, in fact, that I've
> attempted an implementation:
>
> diff -u
> /home/dlr/src/xmlrpc-java/src/helma/xmlrpc/WebServer.java-ORIG
> /home/dlr/src/xmlrpc-java/src/helma/xmlrpc/WebServer.java
> ---
> /home/dlr/src/xmlrpc-java/src/helma/xmlrpc/WebServer.java-ORIG
> Sat Mar 17 08:49:13 2001
> +++ /home/dlr/src/xmlrpc-java/src/helma/xmlrpc/WebServer.java Sat
> Mar 17 08:49:13 2001
> @@ -76,14 +76,15 @@
> /**
> * Creates a Web server at the specified port number and IP address.
> */
> - public WebServer (int port, InetAddress add) throws IOException {
> + public WebServer (int port, InetAddress addr) throws IOException {
> this.port = port;
> xmlrpc = new XmlRpcServer ();
> accept = new Vector ();
> deny = new Vector ();
> threadpool = new Stack ();
> runners = new ThreadGroup ("XML-RPC Runner");
> - this.serverSocket = new ServerSocket (port, 50, add);
> + serverSocket = new ServerSocket (port, 50, addr);
> + serverSocket.setSoTimeout (8192);
> listener = new Thread (this, "XML-RPC Weblistener");
> listener.start();
> }
> @@ -179,6 +180,8 @@
> // new Connection (socket);
> } else
> socket.close ();
> + } catch (InterruptedIOException checkState) {
> + // Timeout waiting for a client...try again if still
> listening.
> } catch (Exception ex) {
> System.err.println("Exception in XML-RPC listener
> loop (" + ex + ").");
> } catch (Error err) {
>
> In the above patch, I worry about how clients will react during the
> short period where the WebServer does not have a ServerSocket accepting
> connections. Additionally, the ~8 sec. SO_TIMEOUT wait time was guess.
>
> Thoughts?
> --
>
> Daniel Rall <dl...@collab.net>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: XmlRpc service not shutting down
Posted by Daniel Rall <dl...@collab.net>.
[helma.org guys, please CC the Turbine list on any responses...thanks!]
"Ilkka Priha" <ip...@surfeu.fi> writes:
> Sorry, didn't help. 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.
Ah, indeed. Nice description of the problem--so nice, in fact, that I've
attempted an implementation:
diff -u /home/dlr/src/xmlrpc-java/src/helma/xmlrpc/WebServer.java-ORIG /home/dlr/src/xmlrpc-java/src/helma/xmlrpc/WebServer.java
--- /home/dlr/src/xmlrpc-java/src/helma/xmlrpc/WebServer.java-ORIG Sat Mar 17 08:49:13 2001
+++ /home/dlr/src/xmlrpc-java/src/helma/xmlrpc/WebServer.java Sat Mar 17 08:49:13 2001
@@ -76,14 +76,15 @@
/**
* Creates a Web server at the specified port number and IP address.
*/
- public WebServer (int port, InetAddress add) throws IOException {
+ public WebServer (int port, InetAddress addr) throws IOException {
this.port = port;
xmlrpc = new XmlRpcServer ();
accept = new Vector ();
deny = new Vector ();
threadpool = new Stack ();
runners = new ThreadGroup ("XML-RPC Runner");
- this.serverSocket = new ServerSocket (port, 50, add);
+ serverSocket = new ServerSocket (port, 50, addr);
+ serverSocket.setSoTimeout (8192);
listener = new Thread (this, "XML-RPC Weblistener");
listener.start();
}
@@ -179,6 +180,8 @@
// new Connection (socket);
} else
socket.close ();
+ } catch (InterruptedIOException checkState) {
+ // Timeout waiting for a client...try again if still listening.
} catch (Exception ex) {
System.err.println("Exception in XML-RPC listener loop (" + ex + ").");
} catch (Error err) {
In the above patch, I worry about how clients will react during the
short period where the WebServer does not have a ServerSocket accepting
connections. Additionally, the ~8 sec. SO_TIMEOUT wait time was guess.
Thoughts?
--
Daniel Rall <dl...@collab.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: XmlRpc service not shutting down
Posted by Daniel Rall <dl...@collab.net>.
"Ilkka Priha" <ex...@nokia.com> writes:
> Well, as the helma server can also be used as a stand-alone system, it's
> possible that they can't or don't want to implement a solution that is the
> best for a service based system. E.g. in the timeout based listener
> solution, I don't know what actually happens between two accept() calls.
> It's possible that the client party tries a couple of times, which would
> make it work. On the other hand, I've heard that in some OS level socket
> implementations (Linux) SO_TIMEOUT doesn't work reliably. The optimal
> timeout period for a stand-alone system can also be longer than for a
> service.
Specifying the timeout via the WebServer class's constructor might
adequately support either scenario.
> First I thought that the suggestion below is a hack, but maybe it can be
> thought of as relevant check that a service maintainer makes to guarantee
> that its services act properly. So why not to add it and even keep it
> regardless of helma's solution?
I've added the code to make the socket connection to break the
WebServer's I/O wait state. It's now in CVS.
--
Daniel Rall <dl...@collab.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: XmlRpc service not shutting down
Posted by Ilkka Priha <ex...@nokia.com>.
Well, as the helma server can also be used as a stand-alone system, it's
possible that they can't or don't want to implement a solution that is the
best for a service based system. E.g. in the timeout based listener
solution, I don't know what actually happens between two accept() calls.
It's possible that the client party tries a couple of times, which would
make it work. On the other hand, I've heard that in some OS level socket
implementations (Linux) SO_TIMEOUT doesn't work reliably. The optimal
timeout period for a stand-alone system can also be longer than for a
service.
First I thought that the suggestion below is a hack, but maybe it can be
thought of as relevant check that a service maintainer makes to guarantee
that its services act properly. So why not to add it and even keep it
regardless of helma's solution?
-- Ilkka
[mailto:ext-ilkka.priha@nokia.com]
> -----Original Message-----
> From: dlr@despot.finemaltcoding.com
> [mailto:dlr@despot.finemaltcoding.com]On Behalf Of Daniel Rall
> Sent: Saturday, March 17, 2001 18:59
> To: turbine-dev@jakarta.apache.org
> Subject: Re: XmlRpc service not shutting down
>
>
> > A hack in Turbine could try to open a connection to the server after the
> > shutdown() call, because that would break the I/O wait and let
> the listener
> > to check the flag, though I hope they'll fix this at helma
> (this is posted
> > to their list also).
>
> Should I put this in place until we hear back from the helma.org guys?
> --
>
> Daniel Rall <dl...@collab.net>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: XmlRpc service not shutting down
Posted by Daniel Rall <dl...@collab.net>.
> A hack in Turbine could try to open a connection to the server after the
> shutdown() call, because that would break the I/O wait and let the listener
> to check the flag, though I hope they'll fix this at helma (this is posted
> to their list also).
Should I put this in place until we hear back from the helma.org guys?
--
Daniel Rall <dl...@collab.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: XmlRpc service not shutting down
Posted by Ilkka Priha <ip...@surfeu.fi>.
Sorry, didn't help. 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.
> /**
> * Stop listening on the server port.
> */
> public void shutdown () {
> if (listener != null) {
> Thread l = listener;
> listener = null;
> l.interrupt ();
> }
> }
A hack in Turbine could try to open a connection to the server after the
shutdown() call, because that would break the I/O wait and let the listener
to check the flag, though I hope they'll fix this at helma (this is posted
to their list also).
-- Ilkka
[mailto:ext-ilkka.priha@nokia.com]
> -----Original Message-----
> From: dlr@despot.finemaltcoding.com
> [mailto:dlr@despot.finemaltcoding.com]On Behalf Of Daniel Rall
> Sent: Friday, March 16, 2001 20:20
> To: turbine-dev@jakarta.apache.org
> Subject: Re: XmlRpc service not shutting down
>
>
> Jason van Zyl <jv...@apache.org> writes:
>
> > Ilkka Priha wrote:
> > >
> > > The XmlRpc service seems to leave some socket
> listeners/non-daemon threads
> > > running when shutting down services. Is it possible to pass a
> shutdown message
> > > to the server part by implementing Turbine's shutdown()
> callback in the service?
> >
> > Yes, definitely. If someone else doesn't get to it. I will fix this
> > when I am done with the template services.
>
> I took a stab at this. Ilkka, please give the latest CVS a try.
> --
>
> Daniel Rall <dl...@collab.net>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: XmlRpc service not shutting down
Posted by Daniel Rall <dl...@collab.net>.
Jason van Zyl <jv...@apache.org> writes:
> Ilkka Priha wrote:
> >
> > The XmlRpc service seems to leave some socket listeners/non-daemon threads
> > running when shutting down services. Is it possible to pass a shutdown message
> > to the server part by implementing Turbine's shutdown() callback in the service?
>
> Yes, definitely. If someone else doesn't get to it. I will fix this
> when I am done with the template services.
I took a stab at this. Ilkka, please give the latest CVS a try.
--
Daniel Rall <dl...@collab.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: XmlRpc service not shutting down
Posted by Jason van Zyl <jv...@apache.org>.
Ilkka Priha wrote:
>
> The XmlRpc service seems to leave some socket listeners/non-daemon threads
> running when shutting down services. Is it possible to pass a shutdown message
> to the server part by implementing Turbine's shutdown() callback in the service?
Yes, definitely. If someone else doesn't get to it. I will fix this
when I am done with the template services.
>
> -- Ilkka
>
> [mailto:ext-ilkka.priha@nokia.com]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org