You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rpc-dev@xml.apache.org by dl...@apache.org on 2002/08/13 04:02:28 UTC
cvs commit: xml-rpc/src/java/org/apache/xmlrpc WebServer.java
dlr 2002/08/12 19:02:28
Modified: src/java/org/apache/xmlrpc WebServer.java
Log:
start(): Marked the "XML-RPC Weblistener" thread as a daemon thread to
assure the JVM will be able to shutdown if this thread is still
running when System.exit() is called or an appropriate signal is sent.
http://java.sun.com/j2se/1.3/docs/api/java/lang/Thread.html#setDaemon(boolean)
Revision Changes Path
1.12 +2 -1 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.11
retrieving revision 1.12
diff -u -u -r1.11 -r1.12
--- WebServer.java 20 Mar 2002 15:11:03 -0000 1.11
+++ WebServer.java 13 Aug 2002 02:02:28 -0000 1.12
@@ -213,6 +213,7 @@
public void start()
{
listener = new Thread(this, "XML-RPC Weblistener");
+ listener.setDaemon(true);
listener.start();
}
Re: WebServer.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Rob Walker" <ro...@softsell.com> writes:
> > I'd rather have the stability of a full-blown, maintained servlet
> > engine; XML-RPC's spec makes perfomant implementations difficult,
> > anyhow. We avoid doing performance-critical operations over XML-RPC. In
> > the future, we will be using more and more Spread
> > <http://www.spread.org/>, perhaps eventually via JMS
> > <http://jms4spread.tigris.org/>. We may install the XmlRpcServer as the
> > RPC layer to use over Spread or JMS. --
>
> Interesting - thanks for the links. I'll take a look
>
> Performance wise, maybe our app is peculiar, but for us XML/RPC
> absolutely flies. We use it for a variety of things, but one aspect is remote
> log and stats monitoring - which generates a very high rate/volume, of short
> to medium size (http payload wise) xml/rpc calls. Once we got keep alive
> figured, xml/rpc beat the daylights out of most other things we tried - direct
> socket level, binary messaging was about the only thing to beat it, and then
> not by enough to make the loss of flexibility worthwhile.
That's actually why I like message oriented middleware (MOM) so much.
A good implementation (such as Spread) provides a very thin layer
above TCP multicast sockets, yielding an extremely efficient
implementation. JMS provides an excellent Java API abstraction which
works across MOM vendors.
I like Spread as my MOM provider do not only to its implementation
(which avoids a single point of failure), but also to the fact that
there are client language bindings for Java, Python, Perl, C (and I
think, Ruby).
Now, if you need RPC, you have to build something on top of the MOM.
Which is where XML-RPC could come in (let's not invent yet another
custom wire protocol, UGH).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: WebServer.java
Posted by Rob Walker <ro...@softsell.com>.
> Have you had any success with XML-RPC pipelining? XWT just got support
> for it a few weeks ago, but I haven't had a chance to see if it really
> improves real-world performance.
>
> http://lists.xwt.org/pipermail/announce/2002-August/000019.html
No, I hadn't - thanks for the tip though, I'll certainly take a look when I get a
chance.
- Rob
SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
+44 (20) 7488 3470
www.softsell.com
robw@softsell.com
Re: WebServer.java
Posted by Rob Walker <ro...@softsell.com>.
> Have you had any success with XML-RPC pipelining? XWT just got support
> for it a few weeks ago, but I haven't had a chance to see if it really
> improves real-world performance.
>
> http://lists.xwt.org/pipermail/announce/2002-August/000019.html
No, I hadn't - thanks for the tip though, I'll certainly take a look when I get a
chance.
- Rob
SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
+44 (20) 7488 3470
www.softsell.com
robw@softsell.com
Re: WebServer.java
Posted by Adam Megacz <ad...@megacz.com>.
"Rob Walker" <ro...@softsell.com> writes:
> Once we got keep alive figured,
Have you had any success with XML-RPC pipelining? XWT just got support
for it a few weeks ago, but I haven't had a chance to see if it really
improves real-world performance.
http://lists.xwt.org/pipermail/announce/2002-August/000019.html
- a
--
Sick of HTML user interfaces?
www.xwt.org
Re: WebServer.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Rob Walker" <ro...@softsell.com> writes:
> > I'd rather have the stability of a full-blown, maintained servlet
> > engine; XML-RPC's spec makes perfomant implementations difficult,
> > anyhow. We avoid doing performance-critical operations over XML-RPC. In
> > the future, we will be using more and more Spread
> > <http://www.spread.org/>, perhaps eventually via JMS
> > <http://jms4spread.tigris.org/>. We may install the XmlRpcServer as the
> > RPC layer to use over Spread or JMS. --
>
> Interesting - thanks for the links. I'll take a look
>
> Performance wise, maybe our app is peculiar, but for us XML/RPC
> absolutely flies. We use it for a variety of things, but one aspect is remote
> log and stats monitoring - which generates a very high rate/volume, of short
> to medium size (http payload wise) xml/rpc calls. Once we got keep alive
> figured, xml/rpc beat the daylights out of most other things we tried - direct
> socket level, binary messaging was about the only thing to beat it, and then
> not by enough to make the loss of flexibility worthwhile.
That's actually why I like message oriented middleware (MOM) so much.
A good implementation (such as Spread) provides a very thin layer
above TCP multicast sockets, yielding an extremely efficient
implementation. JMS provides an excellent Java API abstraction which
works across MOM vendors.
I like Spread as my MOM provider do not only to its implementation
(which avoids a single point of failure), but also to the fact that
there are client language bindings for Java, Python, Perl, C (and I
think, Ruby).
Now, if you need RPC, you have to build something on top of the MOM.
Which is where XML-RPC could come in (let's not invent yet another
custom wire protocol, UGH).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: WebServer.java
Posted by Adam Megacz <ad...@megacz.com>.
"Rob Walker" <ro...@softsell.com> writes:
> Once we got keep alive figured,
Have you had any success with XML-RPC pipelining? XWT just got support
for it a few weeks ago, but I haven't had a chance to see if it really
improves real-world performance.
http://lists.xwt.org/pipermail/announce/2002-August/000019.html
- a
--
Sick of HTML user interfaces?
www.xwt.org
Re: WebServer.java
Posted by Rob Walker <ro...@softsell.com>.
> I'd rather have the stability of a full-blown, maintained servlet
> engine; XML-RPC's spec makes perfomant implementations difficult,
> anyhow. We avoid doing performance-critical operations over XML-RPC. In
> the future, we will be using more and more Spread
> <http://www.spread.org/>, perhaps eventually via JMS
> <http://jms4spread.tigris.org/>. We may install the XmlRpcServer as the
> RPC layer to use over Spread or JMS. --
Interesting - thanks for the links. I'll take a look
Performance wise, maybe our app is peculiar, but for us XML/RPC
absolutely flies. We use it for a variety of things, but one aspect is remote
log and stats monitoring - which generates a very high rate/volume, of short
to medium size (http payload wise) xml/rpc calls. Once we got keep alive
figured, xml/rpc beat the daylights out of most other things we tried - direct
socket level, binary messaging was about the only thing to beat it, and then
not by enough to make the loss of flexibility worthwhile.
-- Rob
SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
+44 (20) 7488 3470
www.softsell.com
robw@softsell.com
Re: WebServer.java
Posted by Rob Walker <ro...@softsell.com>.
> I'd rather have the stability of a full-blown, maintained servlet
> engine; XML-RPC's spec makes perfomant implementations difficult,
> anyhow. We avoid doing performance-critical operations over XML-RPC. In
> the future, we will be using more and more Spread
> <http://www.spread.org/>, perhaps eventually via JMS
> <http://jms4spread.tigris.org/>. We may install the XmlRpcServer as the
> RPC layer to use over Spread or JMS. --
Interesting - thanks for the links. I'll take a look
Performance wise, maybe our app is peculiar, but for us XML/RPC
absolutely flies. We use it for a variety of things, but one aspect is remote
log and stats monitoring - which generates a very high rate/volume, of short
to medium size (http payload wise) xml/rpc calls. Once we got keep alive
figured, xml/rpc beat the daylights out of most other things we tried - direct
socket level, binary messaging was about the only thing to beat it, and then
not by enough to make the loss of flexibility worthwhile.
-- Rob
SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
+44 (20) 7488 3470
www.softsell.com
robw@softsell.com
Re: WebServer.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Adam Megacz <ad...@megacz.com> writes:
> "Rob Walker" <ro...@softsell.com> writes:
> > Interestingly we've done this for Osgi (the open source Oscar
> > implementation) - by providing a Servlet bridge from the xml/rpc handlers
> > through to Jetty as the HttpServer (which is itself wrappered to provide a
> > standard OSGi HttpService).
>
> Is there a way to design this adapte such that XMLL-RPC handler
> mappings are configurable from the web.xml file like servlets?
>
> Ideally, you'd be able to do stuff like
>
> <xml-rpc>
> <xml-rpc-name> Foo </xml-rpc-name>
> <handler-class> org.xwt.foo.bar </handler-class>
> <mount-point> foo.bar </mount-point>
> </xml-rpc>
With Servlet API 2.2+, you could use servlet initialization parameters
to accomplish this:
<servlet>
<servlet-name>RPC2</servlet-name>
<servlet-class>
org.apache.xmlrpc.XmlRpcServlet
</servlet-class>
<init-param>
<param-name>handler.Foo</param-name>
<param-value>org.xwt.foo.bar</param-value>
</init-param>
</servlet>
Using the above config, XmlRpcServlet would grab its list of
initialization parameters and search for those prefixed with
"handler.", stripping the prefix and using the value as class name.
Since XmlRpcServer uses reflection to invoke its handlers, Your
example's <mount-point> element isn't relevant unless you want to use
an alternate name to invoke a defined method of your class.
Alternately, you could also pass your above snippet of XML in a CDATA
block _inside_ the <param-value> for a more XML-ish style of
configuration.
Random note: JServ supported a similar functionality for Servlet API
2.0.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: WebServer.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Adam Megacz <ad...@megacz.com> writes:
> "Rob Walker" <ro...@softsell.com> writes:
> > Interestingly we've done this for Osgi (the open source Oscar
> > implementation) - by providing a Servlet bridge from the xml/rpc handlers
> > through to Jetty as the HttpServer (which is itself wrappered to provide a
> > standard OSGi HttpService).
>
> Is there a way to design this adapte such that XMLL-RPC handler
> mappings are configurable from the web.xml file like servlets?
>
> Ideally, you'd be able to do stuff like
>
> <xml-rpc>
> <xml-rpc-name> Foo </xml-rpc-name>
> <handler-class> org.xwt.foo.bar </handler-class>
> <mount-point> foo.bar </mount-point>
> </xml-rpc>
With Servlet API 2.2+, you could use servlet initialization parameters
to accomplish this:
<servlet>
<servlet-name>RPC2</servlet-name>
<servlet-class>
org.apache.xmlrpc.XmlRpcServlet
</servlet-class>
<init-param>
<param-name>handler.Foo</param-name>
<param-value>org.xwt.foo.bar</param-value>
</init-param>
</servlet>
Using the above config, XmlRpcServlet would grab its list of
initialization parameters and search for those prefixed with
"handler.", stripping the prefix and using the value as class name.
Since XmlRpcServer uses reflection to invoke its handlers, Your
example's <mount-point> element isn't relevant unless you want to use
an alternate name to invoke a defined method of your class.
Alternately, you could also pass your above snippet of XML in a CDATA
block _inside_ the <param-value> for a more XML-ish style of
configuration.
Random note: JServ supported a similar functionality for Servlet API
2.0.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: WebServer.java
Posted by Rob Walker <ro...@softsell.com>.
>
> "Rob Walker" <ro...@softsell.com> writes:
> > Interestingly we've done this for Osgi (the open source Oscar
> > implementation) - by providing a Servlet bridge from the xml/rpc handlers
> > through to Jetty as the HttpServer (which is itself wrappered to provide a
> > standard OSGi HttpService).
>
> Is there a way to design this adapte such that XMLL-RPC handler
> mappings are configurable from the web.xml file like servlets?
>
> Ideally, you'd be able to do stuff like
>
> <xml-rpc>
> <xml-rpc-name> Foo </xml-rpc-name>
> <handler-class> org.xwt.foo.bar </handler-class>
> <mount-point> foo.bar </mount-point>
> </xml-rpc>
>
> - a
We didn't take it that far for the OSGi based version - but certainly sounds
feasible. In fact the way OSGi works is via "bundles" and "services" so the
XMLRPC bundle exports various methods like addHandler, removeHandler
etc.
So in fact, the above could be done via some form of configurator bundle.
-- Rob
SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
+44 (20) 7488 3470
www.softsell.com
robw@softsell.com
Re: WebServer.java
Posted by Rob Walker <ro...@softsell.com>.
>
> "Rob Walker" <ro...@softsell.com> writes:
> > Interestingly we've done this for Osgi (the open source Oscar
> > implementation) - by providing a Servlet bridge from the xml/rpc handlers
> > through to Jetty as the HttpServer (which is itself wrappered to provide a
> > standard OSGi HttpService).
>
> Is there a way to design this adapte such that XMLL-RPC handler
> mappings are configurable from the web.xml file like servlets?
>
> Ideally, you'd be able to do stuff like
>
> <xml-rpc>
> <xml-rpc-name> Foo </xml-rpc-name>
> <handler-class> org.xwt.foo.bar </handler-class>
> <mount-point> foo.bar </mount-point>
> </xml-rpc>
>
> - a
We didn't take it that far for the OSGi based version - but certainly sounds
feasible. In fact the way OSGi works is via "bundles" and "services" so the
XMLRPC bundle exports various methods like addHandler, removeHandler
etc.
So in fact, the above could be done via some form of configurator bundle.
-- Rob
SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
+44 (20) 7488 3470
www.softsell.com
robw@softsell.com
Re: WebServer.java
Posted by Adam Megacz <ad...@megacz.com>.
"Rob Walker" <ro...@softsell.com> writes:
> Interestingly we've done this for Osgi (the open source Oscar
> implementation) - by providing a Servlet bridge from the xml/rpc handlers
> through to Jetty as the HttpServer (which is itself wrappered to provide a
> standard OSGi HttpService).
Is there a way to design this adapte such that XMLL-RPC handler
mappings are configurable from the web.xml file like servlets?
Ideally, you'd be able to do stuff like
<xml-rpc>
<xml-rpc-name> Foo </xml-rpc-name>
<handler-class> org.xwt.foo.bar </handler-class>
<mount-point> foo.bar </mount-point>
</xml-rpc>
- a
--
Sick of HTML user interfaces?
www.xwt.org
Re: WebServer.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Rob Walker" <ro...@softsell.com> writes:
> >
> > I would very much like to dump the WebServer class in favor of
> > wrapping the XmlRpcServer in a HttpServlet
>
> Interestingly we've done this for Osgi (the open source Oscar
> implementation) - by providing a Servlet bridge from the xml/rpc handlers
> through to Jetty as the HttpServer (which is itself wrappered to provide a
> standard OSGi HttpService).
This is exactly what I am considering. It's perfect for my use case,
considering that we're already running a servlet engine (Tomcat 4.1.x).
> Works fine - no firm stats, but seems somewhat slower than the built in
> WebServer which we still use for performance critical stuff.
I'd rather have the stability of a full-blown, maintained servlet
engine; XML-RPC's spec makes perfomant implementations difficult,
anyhow. We avoid doing performance-critical operations over XML-RPC.
In the future, we will be using more and more Spread
<http://www.spread.org/>, perhaps eventually via JMS
<http://jms4spread.tigris.org/>. We may install the XmlRpcServer as
the RPC layer to use over Spread or JMS.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: WebServer.java
Posted by Adam Megacz <ad...@megacz.com>.
"Rob Walker" <ro...@softsell.com> writes:
> Interestingly we've done this for Osgi (the open source Oscar
> implementation) - by providing a Servlet bridge from the xml/rpc handlers
> through to Jetty as the HttpServer (which is itself wrappered to provide a
> standard OSGi HttpService).
Is there a way to design this adapte such that XMLL-RPC handler
mappings are configurable from the web.xml file like servlets?
Ideally, you'd be able to do stuff like
<xml-rpc>
<xml-rpc-name> Foo </xml-rpc-name>
<handler-class> org.xwt.foo.bar </handler-class>
<mount-point> foo.bar </mount-point>
</xml-rpc>
- a
--
Sick of HTML user interfaces?
www.xwt.org
Re: WebServer.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Rob Walker" <ro...@softsell.com> writes:
> >
> > I would very much like to dump the WebServer class in favor of
> > wrapping the XmlRpcServer in a HttpServlet
>
> Interestingly we've done this for Osgi (the open source Oscar
> implementation) - by providing a Servlet bridge from the xml/rpc handlers
> through to Jetty as the HttpServer (which is itself wrappered to provide a
> standard OSGi HttpService).
This is exactly what I am considering. It's perfect for my use case,
considering that we're already running a servlet engine (Tomcat 4.1.x).
> Works fine - no firm stats, but seems somewhat slower than the built in
> WebServer which we still use for performance critical stuff.
I'd rather have the stability of a full-blown, maintained servlet
engine; XML-RPC's spec makes perfomant implementations difficult,
anyhow. We avoid doing performance-critical operations over XML-RPC.
In the future, we will be using more and more Spread
<http://www.spread.org/>, perhaps eventually via JMS
<http://jms4spread.tigris.org/>. We may install the XmlRpcServer as
the RPC layer to use over Spread or JMS.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: WebServer.java
Posted by Rob Walker <ro...@softsell.com>.
>
> I would very much like to dump the WebServer class in favor of
> wrapping the XmlRpcServer in a HttpServlet
Interestingly we've done this for Osgi (the open source Oscar
implementation) - by providing a Servlet bridge from the xml/rpc handlers
through to Jetty as the HttpServer (which is itself wrappered to provide a
standard OSGi HttpService).
Works fine - no firm stats, but seems somewhat slower than the built in
WebServer which we still use for performance critical stuff.
-- Rob Walker
SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
+44 (20) 7488 3470
www.softsell.com
robw@softsell.com
Re: WebServer.java
Posted by Rob Walker <ro...@softsell.com>.
>
> I would very much like to dump the WebServer class in favor of
> wrapping the XmlRpcServer in a HttpServlet
Interestingly we've done this for Osgi (the open source Oscar
implementation) - by providing a Servlet bridge from the xml/rpc handlers
through to Jetty as the HttpServer (which is itself wrappered to provide a
standard OSGi HttpService).
Works fine - no firm stats, but seems somewhat slower than the built in
WebServer which we still use for performance critical stuff.
-- Rob Walker
SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
+44 (20) 7488 3470
www.softsell.com
robw@softsell.com
Re: WebServer.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Andrew Evers" <an...@redwood.com> writes:
> If you embed the current XmlRpcServer as part of a servlet
> doPost() method, then there is a conflict between the threading
> done by the servlet engine, and that done by the XmlRpcServer.
> The servlet engine has already allocated a thread to the
> request, there is no need to pool and manage threads again.
It would be nice if one could get ahold of a single threaded object
which can process XML-RPC calls like XmlRpcServer can. It would be
very cool if someone would factor that code out of XmlRpcServer.
> It seems to me that the current XmlRpcServer does a good job
> of handling threads in normal operation (without a servlet
> engine out front). If the Worker was split out, and passed
> an extra callback interface to handle the URI -> object mapping,
> then it would be easy to embed XML-RPC into an arbitary HTTP
> implementation without embedding either the XmlRpcServer
> or the WebServer.
Exactly. Is anyone up to this job?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: WebServer.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Andrew Evers" <an...@redwood.com> writes:
> If you embed the current XmlRpcServer as part of a servlet
> doPost() method, then there is a conflict between the threading
> done by the servlet engine, and that done by the XmlRpcServer.
> The servlet engine has already allocated a thread to the
> request, there is no need to pool and manage threads again.
It would be nice if one could get ahold of a single threaded object
which can process XML-RPC calls like XmlRpcServer can. It would be
very cool if someone would factor that code out of XmlRpcServer.
> It seems to me that the current XmlRpcServer does a good job
> of handling threads in normal operation (without a servlet
> engine out front). If the Worker was split out, and passed
> an extra callback interface to handle the URI -> object mapping,
> then it would be easy to embed XML-RPC into an arbitary HTTP
> implementation without embedding either the XmlRpcServer
> or the WebServer.
Exactly. Is anyone up to this job?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: WebServer.java
Posted by Andrew Evers <an...@redwood.com>.
> I would very much like to dump the WebServer class in favor of
> wrapping the XmlRpcServer in a HttpServlet (and not using a XML-RPC
> client to make requests like the current XmlRpcProxyServlet does).
> Basically, we'd mark it as deprecated and cease maintainence on it. As
> is, it has serious problems (as does a lot of the code in this
> package).
Funny that, I was looking at replacing the WebServer for our local
implementation so that I could split off a particular class of HTTP
request.
The problem with relying entirely on a servlet engine is one of
speed (mentioned already), but also of dependencies. The current
xml-rpc package is quite small and is self-contained. Requiring
a servlet implementation means that an application that uses
xml-rpc must embed and distribute a servlet engine, be
embedded in a servlet engine, or distributed as a WAR or similar.
I haven't seen a servlet engine that is as simple to embed as
the WebServer (although I would like to be wrong). I think that
people embedding XML-RPC functionality in their applications may
also be concerned about losing control over how threads and
synchronicity are managed.
If you embed the current XmlRpcServer as part of a servlet
doPost() method, then there is a conflict between the threading
done by the servlet engine, and that done by the XmlRpcServer.
The servlet engine has already allocated a thread to the
request, there is no need to pool and manage threads again.
It seems to me that the current XmlRpcServer does a good job
of handling threads in normal operation (without a servlet
engine out front). If the Worker was split out, and passed
an extra callback interface to handle the URI -> object mapping,
then it would be easy to embed XML-RPC into an arbitary HTTP
implementation without embedding either the XmlRpcServer
or the WebServer.
Andrew.
Re: WebServer.java
Posted by Andrew Evers <an...@redwood.com>.
> I would very much like to dump the WebServer class in favor of
> wrapping the XmlRpcServer in a HttpServlet (and not using a XML-RPC
> client to make requests like the current XmlRpcProxyServlet does).
> Basically, we'd mark it as deprecated and cease maintainence on it. As
> is, it has serious problems (as does a lot of the code in this
> package).
Funny that, I was looking at replacing the WebServer for our local
implementation so that I could split off a particular class of HTTP
request.
The problem with relying entirely on a servlet engine is one of
speed (mentioned already), but also of dependencies. The current
xml-rpc package is quite small and is self-contained. Requiring
a servlet implementation means that an application that uses
xml-rpc must embed and distribute a servlet engine, be
embedded in a servlet engine, or distributed as a WAR or similar.
I haven't seen a servlet engine that is as simple to embed as
the WebServer (although I would like to be wrong). I think that
people embedding XML-RPC functionality in their applications may
also be concerned about losing control over how threads and
synchronicity are managed.
If you embed the current XmlRpcServer as part of a servlet
doPost() method, then there is a conflict between the threading
done by the servlet engine, and that done by the XmlRpcServer.
The servlet engine has already allocated a thread to the
request, there is no need to pool and manage threads again.
It seems to me that the current XmlRpcServer does a good job
of handling threads in normal operation (without a servlet
engine out front). If the Worker was split out, and passed
an extra callback interface to handle the URI -> object mapping,
then it would be easy to embed XML-RPC into an arbitary HTTP
implementation without embedding either the XmlRpcServer
or the WebServer.
Andrew.
WebServer.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Daniel Rall <dl...@finemaltcoding.com> writes:
> Jim Redman <ji...@ergotech.com> writes:
>
> > I don't think that this is correct. If the only thread is the
> > listener then the server should stay listening and not exit. With the
> > thread set to daemon, if the only remaining thread in the application
> > is the server, the application will exit.
>
> I think you are correct. I did not consider this use case. Rolling
> back change.
I would very much like to dump the WebServer class in favor of
wrapping the XmlRpcServer in a HttpServlet (and not using a XML-RPC
client to make requests like the current XmlRpcProxyServlet does).
Basically, we'd mark it as deprecated and cease maintainence on it.
As is, it has serious problems (as does a lot of the code in this
package).
What are people's thoughts on this?
--
Daniel Rall <dl...@finemaltcoding.com>
WebServer.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Daniel Rall <dl...@finemaltcoding.com> writes:
> Jim Redman <ji...@ergotech.com> writes:
>
> > I don't think that this is correct. If the only thread is the
> > listener then the server should stay listening and not exit. With the
> > thread set to daemon, if the only remaining thread in the application
> > is the server, the application will exit.
>
> I think you are correct. I did not consider this use case. Rolling
> back change.
I would very much like to dump the WebServer class in favor of
wrapping the XmlRpcServer in a HttpServlet (and not using a XML-RPC
client to make requests like the current XmlRpcProxyServlet does).
Basically, we'd mark it as deprecated and cease maintainence on it.
As is, it has serious problems (as does a lot of the code in this
package).
What are people's thoughts on this?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: cvs commit: xml-rpc/src/java/org/apache/xmlrpc WebServer.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jim Redman <ji...@ergotech.com> writes:
> I don't think that this is correct. If the only thread is the
> listener then the server should stay listening and not exit. With the
> thread set to daemon, if the only remaining thread in the application
> is the server, the application will exit.
I think you are correct. I did not consider this use case. Rolling
back change.
Re: cvs commit: xml-rpc/src/java/org/apache/xmlrpc WebServer.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jim Redman <ji...@ergotech.com> writes:
> I don't think that this is correct. If the only thread is the
> listener then the server should stay listening and not exit. With the
> thread set to daemon, if the only remaining thread in the application
> is the server, the application will exit.
I think you are correct. I did not consider this use case. Rolling
back change.
Re: cvs commit: xml-rpc/src/java/org/apache/xmlrpc WebServer.java
Posted by Jim Redman <ji...@ergotech.com>.
I don't think that this is correct. If the only thread is the listener
then the server should stay listening and not exit. With the thread
set to daemon, if the only remaining thread in the application is the
server, the application will exit.
If you run the "main" in that class does it exit or continue? If it
continues, what thread is keeping the application alive?
Or did I miss something important?
Jim
On 2002.08.12 20:02 dlr@apache.org wrote:
> dlr 2002/08/12 19:02:28
>
> Modified: src/java/org/apache/xmlrpc WebServer.java
> Log:
> start(): Marked the "XML-RPC Weblistener" thread as a daemon thread
> to
> assure the JVM will be able to shutdown if this thread is still
> running when System.exit() is called or an appropriate signal is
> sent.
>
>
> http://java.sun.com/j2se/1.3/docs/api/java/lang/Thread.html#setDaemon(boolean)
>
> Revision Changes Path
> 1.12 +2 -1
> 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.11
> retrieving revision 1.12
> diff -u -u -r1.11 -r1.12
> --- WebServer.java 20 Mar 2002 15:11:03 -0000 1.11
> +++ WebServer.java 13 Aug 2002 02:02:28 -0000 1.12
> @@ -213,6 +213,7 @@
> public void start()
> {
> listener = new Thread(this, "XML-RPC Weblistener");
> + listener.setDaemon(true);
> listener.start();
> }
>
>
>
>
>
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: cvs commit: xml-rpc/src/java/org/apache/xmlrpc WebServer.java
Posted by Jim Redman <ji...@ergotech.com>.
I don't think that this is correct. If the only thread is the listener
then the server should stay listening and not exit. With the thread
set to daemon, if the only remaining thread in the application is the
server, the application will exit.
If you run the "main" in that class does it exit or continue? If it
continues, what thread is keeping the application alive?
Or did I miss something important?
Jim
On 2002.08.12 20:02 dlr@apache.org wrote:
> dlr 2002/08/12 19:02:28
>
> Modified: src/java/org/apache/xmlrpc WebServer.java
> Log:
> start(): Marked the "XML-RPC Weblistener" thread as a daemon thread
> to
> assure the JVM will be able to shutdown if this thread is still
> running when System.exit() is called or an appropriate signal is
> sent.
>
>
> http://java.sun.com/j2se/1.3/docs/api/java/lang/Thread.html#setDaemon(boolean)
>
> Revision Changes Path
> 1.12 +2 -1
> 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.11
> retrieving revision 1.12
> diff -u -u -r1.11 -r1.12
> --- WebServer.java 20 Mar 2002 15:11:03 -0000 1.11
> +++ WebServer.java 13 Aug 2002 02:02:28 -0000 1.12
> @@ -213,6 +213,7 @@
> public void start()
> {
> listener = new Thread(this, "XML-RPC Weblistener");
> + listener.setDaemon(true);
> listener.start();
> }
>
>
>
>
>
--
Jim Redman
(505) 662 5156
http://www.ergotech.com