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 dl...@apache.org on 2004/05/01 02:39:05 UTC
cvs commit: ws-xmlrpc/src/java/org/apache/xmlrpc XmlRpcServer.java WebServer.java
dlr 2004/04/30 17:39:05
Modified: src/java/org/apache/xmlrpc Tag: XMLRPC_1_2_BRANCH
XmlRpcServer.java WebServer.java
Log:
Corrected a leak in XmlRpcServer's worker count, and normalized
concurrency maximums on XmlRpc.getMaxThreads().
* src/java/org/apache/xmlrpc/XmlRpcServer.java
execute(InputStream, XmlRpcContext): Fix the possibility of
inaccurate tracking of the worker count which can be caused by a
XmlRpcWorker's execute() method throwing a AuthenticationFailed,
ParseFailed, or java.lang.Error. Use a try/finally block to assure
that this leak condition is avoided, and that the worker count
accurately reflects the number of available workers.
getWorker(): Added JavaDoc. Improved error message.
* src/java/org/apache/xmlrpc/WebServer.java
getRunner(): Use the XmlRpc.getMaxThreads() method for the maximum
number of Runner instances, rather than a hardcoded value of 255.
Improved error message.
repoolRunner(Runner): Renamed from releaseRunner(), and JavaDoc'd.
Runner.handle(Socket): Added inline comment doc'ing reason for the
call to "this.notify()".
Runner.run(): Added inline comment doc'ing the reason for the
"count" and "threadpool.size()" checks. Updated method name for
repoolRunner().
Connection.run(): Remove duplicate error output when XmlRpc.debug is
true.
Issue: CollabNet PCN27955
Submitted by: Daniel Ral and Jack Repenning
Revision Changes Path
No revision
No revision
1.35.2.1 +14 -5 ws-xmlrpc/src/java/org/apache/xmlrpc/XmlRpcServer.java
Index: XmlRpcServer.java
===================================================================
RCS file: /home/cvs/ws-xmlrpc/src/java/org/apache/xmlrpc/XmlRpcServer.java,v
retrieving revision 1.35
retrieving revision 1.35.2.1
diff -u -u -r1.35 -r1.35.2.1
--- XmlRpcServer.java 21 Oct 2002 13:08:50 -0000 1.35
+++ XmlRpcServer.java 1 May 2004 00:39:04 -0000 1.35.2.1
@@ -148,15 +148,22 @@
public byte[] execute(InputStream is, XmlRpcContext context)
{
XmlRpcWorker worker = getWorker();
- byte[] retval = worker.execute(is, context);
- pool.push(worker);
- return retval;
+ try
+ {
+ return worker.execute(is, context);
+ }
+ finally
+ {
+ pool.push(worker);
+ }
}
/**
* Hands out pooled workers.
*
- * @return A worker.
+ * @return A worker (never <code>null</code>).
+ * @throws RuntimeException If the server exceeds its maximum
+ * number of allowed requests.
*/
protected XmlRpcWorker getWorker()
{
@@ -176,7 +183,9 @@
}
return createWorker();
}
- throw new RuntimeException("System overload");
+ throw new RuntimeException("System overload: Maximum number of " +
+ "concurrent requests (" + maxThreads +
+ ") exceeded");
}
}
1.22.2.1 +16 -6 ws-xmlrpc/src/java/org/apache/xmlrpc/WebServer.java
Index: WebServer.java
===================================================================
RCS file: /home/cvs/ws-xmlrpc/src/java/org/apache/xmlrpc/WebServer.java,v
retrieving revision 1.22
retrieving revision 1.22.2.1
diff -u -u -r1.22 -r1.22.2.1
--- WebServer.java 3 Dec 2002 17:22:26 -0000 1.22
+++ WebServer.java 1 May 2004 00:39:05 -0000 1.22.2.1
@@ -600,19 +600,23 @@
}
catch (EmptyStackException empty)
{
- if (runners.activeCount () > 255)
+ int maxRequests = XmlRpc.getMaxThreads();
+ if (runners.activeCount() > XmlRpc.getMaxThreads())
{
- throw new RuntimeException("System overload");
+ throw new RuntimeException("System overload: Maximum number " +
+ "of concurrent requests (" +
+ maxRequests + ") exceeded");
}
return new Runner();
}
}
/**
+ * Put <code>runner</code> back into {@link #threadpool}.
*
- * @param runner
+ * @param runner The instance to reclaim.
*/
- void releaseRunner(Runner runner)
+ void repoolRunner(Runner runner)
{
threadpool.push(runner);
}
@@ -642,6 +646,7 @@
}
else
{
+ // Wake the thread waiting in our run() method.
this.notify();
}
}
@@ -659,11 +664,13 @@
if (count > 200 || threadpool.size() > 20)
{
+ // We're old, or the number of threads in the pool
+ // is large.
return;
}
synchronized(this)
{
- releaseRunner(this);
+ repoolRunner(this);
try
{
this.wait();
@@ -790,10 +797,13 @@
}
catch (Exception exception)
{
- System.err.println(exception);
if (XmlRpc.debug)
{
exception.printStackTrace();
+ }
+ else
+ {
+ System.err.println(exception);
}
}
finally
Re: [VOTE] 1.2 b2 release
Posted by Daniel Rall <dl...@collab.net>.
Daniel Rall wrote:
> I was hoping that 1.2 b1 would end up being the final release, but a
> co-worker (Jack Repenning) led me to a fairly serious leakage of the
> count of Worker objects used by XmlRpcServer. (I've committed fixes for
> this to the HEAD and XMLRPC_1_2_BRANCH.)
>
> In light of this significant stability change, I'd like to formerly
> release 1.2 b2 (which I've created a tag for), which will hopefull end
> up tagged as the final release in the 1.2 series. Committers, may I
> have your votes please:
>
> [X] Yes, please proceed with the release (+1).
> [ ] Don't have an opinion or won't block the release (+0)
> [ ] No (-1), because: ____________________________________________
Re: 1.2 b2 and gzip compression
Posted by Daniel Rall <dl...@collab.net>.
Henri Gomez wrote:
> Hi to all,
>
> Did there is plan to support gzip in XML-RPC 1.2 final ?
Henri, no. 1.x is supposed to be our maintainence branch. However, I'd be
willing to do a quick 1.3 to get that feature, or perhaps cut 2.0. XML is such
a ridiculously bloated data format that it screams for compression. You haven't
by any chance done any work towards this goal, have you?
- Dan
1.2 b2 and gzip compression
Posted by Henri Gomez <hg...@apache.org>.
Hi to all,
Did there is plan to support gzip in XML-RPC 1.2 final ?
Regards
Re: 1.2 b2 release issues
Posted by Davanum Srinivas <da...@gmail.com>.
Yes, Please. all releases have to use ASL 2.0
-- dims
On Sat, 15 May 2004 06:09:37 -0500, Ryan Hoegg <rh...@isisnetworks.net> wrote:
>
> OK I'm +1.
>
> With regards to 26386, I think we have to use the ASF license 2.0 for
> any releases after March 1. I remember much conversation on commons-dev
> about automation of this, and I found these two posts:
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgNo=44521
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgNo=44496
>
> --
> Ryan Hoegg
> ISIS Networks
> http://www.isisnetworks.net/
>
>
>
> Daniel Rall wrote:
>
> > Ryan, thanks for coming up with a strawman list.
> >
> > 17789 will be fixed by the next source tarball (of 1.2 b2 or 1.2
> > final). Now marked as such.
> >
> > 17665 looks like it requires numerous changes, including a change to
> > MinML. I'd rather push out 1.2 with a release note for encoding
> > problems, and work on fixing that in the 2.x or 1.3 series.
> >
> > 19620 was a no brainer, so I've committed a fix similar to the one
> > suggested by Lee Haslup (which mirrors the duplicate code from the
> > XmlRpc class) to the 1.2 and 2.0 streams, and marked the issue as fixed.
> >
> > 19746 had quite the hack proposed by Lee, but as it certainly makes
> > the code less broken than it currently is, I've gone ahead and
> > committed it as a stop-gap measure. Long term, 28982 nees to be
> > implemented in its place.
> >
> > 26386 would be nice to have for 1.2, but is not something I recommend
> > holding up the release for. Now, that said, there are a couple of
> > scripts floating around which could resolve this quickly and easily,
> > and I would love someone to take the initiative of emailing
> > infrastructure@ and doing the conversion.
> >
> > > Andrew wrote:
> >
> >>
> >> I have a small patch that a collegue is working on that I would like
> >> to see on the 1.2 branch. It adds support for an input encoding to
> >> XmlRpc. This allows it to work correctly on z/OS and other EBCDIC
> >> systems, where the default encoding is EBCDIC but the network
> >> is ASCII.
> >
> > ...
> >
> > Personally, I don't see this as essential for the 1.2 release, but am
> > very much in favor of including this in the code base. My strawman
> > suggestion is to ship 1.2 without it, and ship a subsequent 1.3 with
> > -- possibly -- only this change. I have no compunction about this
> > being committed to the 2.0 stream immediately.
> >
> > [I have a separate email out to Andrew about getting his new key
> > installed.]
> >
> >> We've been running 1.2 quite successfully with customers for
> >> a while now. We don't use the XmlRpcServer/XmlRpcWorker
> >> stuff though.
> >
> >
> > What do you use instead?
> >
> > - Dan
>
>
Re: 1.2 b2 release issues
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
OK I'm +1.
With regards to 26386, I think we have to use the ASF license 2.0 for
any releases after March 1. I remember much conversation on commons-dev
about automation of this, and I found these two posts:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgNo=44521
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgNo=44496
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net/
Daniel Rall wrote:
> Ryan, thanks for coming up with a strawman list.
>
> 17789 will be fixed by the next source tarball (of 1.2 b2 or 1.2
> final). Now marked as such.
>
> 17665 looks like it requires numerous changes, including a change to
> MinML. I'd rather push out 1.2 with a release note for encoding
> problems, and work on fixing that in the 2.x or 1.3 series.
>
> 19620 was a no brainer, so I've committed a fix similar to the one
> suggested by Lee Haslup (which mirrors the duplicate code from the
> XmlRpc class) to the 1.2 and 2.0 streams, and marked the issue as fixed.
>
> 19746 had quite the hack proposed by Lee, but as it certainly makes
> the code less broken than it currently is, I've gone ahead and
> committed it as a stop-gap measure. Long term, 28982 nees to be
> implemented in its place.
>
> 26386 would be nice to have for 1.2, but is not something I recommend
> holding up the release for. Now, that said, there are a couple of
> scripts floating around which could resolve this quickly and easily,
> and I would love someone to take the initiative of emailing
> infrastructure@ and doing the conversion.
>
> > Andrew wrote:
>
>>
>> I have a small patch that a collegue is working on that I would like
>> to see on the 1.2 branch. It adds support for an input encoding to
>> XmlRpc. This allows it to work correctly on z/OS and other EBCDIC
>> systems, where the default encoding is EBCDIC but the network
>> is ASCII.
>
> ...
>
> Personally, I don't see this as essential for the 1.2 release, but am
> very much in favor of including this in the code base. My strawman
> suggestion is to ship 1.2 without it, and ship a subsequent 1.3 with
> -- possibly -- only this change. I have no compunction about this
> being committed to the 2.0 stream immediately.
>
> [I have a separate email out to Andrew about getting his new key
> installed.]
>
>> We've been running 1.2 quite successfully with customers for
>> a while now. We don't use the XmlRpcServer/XmlRpcWorker
>> stuff though.
>
>
> What do you use instead?
>
> - Dan
1.2 b2 release issues
Posted by Daniel Rall <dl...@collab.net>.
Ryan Hoegg wrote:
> My +0 will graduate to +1 if we get current with Bugzilla. Some bugs
> that look like 1.2 final material are 17789, 17665, 19620, 19746, and of
> course 26386 (ASL 2.0). I am willing to jump in and help out, what is
> everyone's feeling on post-1.2? I would like to do only bugfixes on 1.2
> and pull the applet code out into a separate build for 2.0. Once that
> happens, we might consider Java 1.2 Collections for the rest?
...
>> [ ] Yes, please proceed with the release (+1).
>> [X] Don't have an opinion or won't block the release (+0)
>> [ ] No (-1), because: ____________________________________________
Ryan, thanks for coming up with a strawman list.
17789 will be fixed by the next source tarball (of 1.2 b2 or 1.2 final). Now
marked as such.
17665 looks like it requires numerous changes, including a change to MinML. I'd
rather push out 1.2 with a release note for encoding problems, and work on
fixing that in the 2.x or 1.3 series.
19620 was a no brainer, so I've committed a fix similar to the one suggested by
Lee Haslup (which mirrors the duplicate code from the XmlRpc class) to the 1.2
and 2.0 streams, and marked the issue as fixed.
19746 had quite the hack proposed by Lee, but as it certainly makes the code
less broken than it currently is, I've gone ahead and committed it as a stop-gap
measure. Long term, 28982 nees to be implemented in its place.
26386 would be nice to have for 1.2, but is not something I recommend holding up
the release for. Now, that said, there are a couple of scripts floating around
which could resolve this quickly and easily, and I would love someone to take
the initiative of emailing infrastructure@ and doing the conversion.
> Andrew wrote:
>
> I have a small patch that a collegue is working on that I would like
> to see on the 1.2 branch. It adds support for an input encoding to
> XmlRpc. This allows it to work correctly on z/OS and other EBCDIC
> systems, where the default encoding is EBCDIC but the network
> is ASCII.
...
Personally, I don't see this as essential for the 1.2 release, but am very much
in favor of including this in the code base. My strawman suggestion is to ship
1.2 without it, and ship a subsequent 1.3 with -- possibly -- only this change.
I have no compunction about this being committed to the 2.0 stream immediately.
[I have a separate email out to Andrew about getting his new key installed.]
> We've been running 1.2 quite successfully with customers for
> a while now. We don't use the XmlRpcServer/XmlRpcWorker
> stuff though.
What do you use instead?
- Dan
Re: [VOTE] 1.2 b2 release
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
My +0 will graduate to +1 if we get current with Bugzilla. Some bugs
that look like 1.2 final material are 17789, 17665, 19620, 19746, and of
course 26386 (ASL 2.0). I am willing to jump in and help out, what is
everyone's feeling on post-1.2? I would like to do only bugfixes on 1.2
and pull the applet code out into a separate build for 2.0. Once that
happens, we might consider Java 1.2 Collections for the rest?
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net/
Daniel Rall wrote:
> I was hoping that 1.2 b1 would end up being the final release, but a
> co-worker (Jack Repenning) led me to a fairly serious leakage of the
> count of Worker objects used by XmlRpcServer. (I've committed fixes
> for this to the HEAD and XMLRPC_1_2_BRANCH.)
>
> In light of this significant stability change, I'd like to formerly
> release 1.2 b2 (which I've created a tag for), which will hopefull end
> up tagged as the final release in the 1.2 series. Committers, may I
> have your votes please:
>
> [ ] Yes, please proceed with the release (+1).
> [X] Don't have an opinion or won't block the release (+0)
> [ ] No (-1), because: ____________________________________________
>
> Thanks, Dan
[VOTE] 1.2 b2 release
Posted by Daniel Rall <dl...@collab.net>.
I was hoping that 1.2 b1 would end up being the final release, but a co-worker
(Jack Repenning) led me to a fairly serious leakage of the count of Worker
objects used by XmlRpcServer. (I've committed fixes for this to the HEAD and
XMLRPC_1_2_BRANCH.)
In light of this significant stability change, I'd like to formerly release 1.2
b2 (which I've created a tag for), which will hopefull end up tagged as the
final release in the 1.2 series. Committers, may I have your votes please:
[ ] Yes, please proceed with the release (+1).
[ ] Don't have an opinion or won't block the release (+0)
[ ] No (-1), because: ____________________________________________
Thanks, Dan
dlr@apache.org wrote:
> dlr 2004/04/30 17:39:05
>
> Modified: src/java/org/apache/xmlrpc Tag: XMLRPC_1_2_BRANCH
> XmlRpcServer.java WebServer.java
> Log:
> Corrected a leak in XmlRpcServer's worker count, and normalized
> concurrency maximums on XmlRpc.getMaxThreads().
>
> * src/java/org/apache/xmlrpc/XmlRpcServer.java
> execute(InputStream, XmlRpcContext): Fix the possibility of
> inaccurate tracking of the worker count which can be caused by a
> XmlRpcWorker's execute() method throwing a AuthenticationFailed,
> ParseFailed, or java.lang.Error. Use a try/finally block to assure
> that this leak condition is avoided, and that the worker count
> accurately reflects the number of available workers.
>
> getWorker(): Added JavaDoc. Improved error message.
>
> * src/java/org/apache/xmlrpc/WebServer.java
> getRunner(): Use the XmlRpc.getMaxThreads() method for the maximum
> number of Runner instances, rather than a hardcoded value of 255.
> Improved error message.
>
> repoolRunner(Runner): Renamed from releaseRunner(), and JavaDoc'd.
>
> Runner.handle(Socket): Added inline comment doc'ing reason for the
> call to "this.notify()".
>
> Runner.run(): Added inline comment doc'ing the reason for the
> "count" and "threadpool.size()" checks. Updated method name for
> repoolRunner().
>
> Connection.run(): Remove duplicate error output when XmlRpc.debug is
> true.
>
> Issue: CollabNet PCN27955
> Submitted by: Daniel Ral and Jack Repenning
>
> Revision Changes Path
> No revision
> No revision
> 1.35.2.1 +14 -5 ws-xmlrpc/src/java/org/apache/xmlrpc/XmlRpcServer.java
>
> Index: XmlRpcServer.java
> ===================================================================
> RCS file: /home/cvs/ws-xmlrpc/src/java/org/apache/xmlrpc/XmlRpcServer.java,v
> retrieving revision 1.35
> retrieving revision 1.35.2.1
> diff -u -u -r1.35 -r1.35.2.1
> --- XmlRpcServer.java 21 Oct 2002 13:08:50 -0000 1.35
> +++ XmlRpcServer.java 1 May 2004 00:39:04 -0000 1.35.2.1
> @@ -148,15 +148,22 @@
> public byte[] execute(InputStream is, XmlRpcContext context)
> {
> XmlRpcWorker worker = getWorker();
> - byte[] retval = worker.execute(is, context);
> - pool.push(worker);
> - return retval;
> + try
> + {
> + return worker.execute(is, context);
> + }
> + finally
> + {
> + pool.push(worker);
> + }
> }
>
> /**
> * Hands out pooled workers.
> *
> - * @return A worker.
> + * @return A worker (never <code>null</code>).
> + * @throws RuntimeException If the server exceeds its maximum
> + * number of allowed requests.
> */
> protected XmlRpcWorker getWorker()
> {
> @@ -176,7 +183,9 @@
> }
> return createWorker();
> }
> - throw new RuntimeException("System overload");
> + throw new RuntimeException("System overload: Maximum number of " +
> + "concurrent requests (" + maxThreads +
> + ") exceeded");
> }
> }
>
>
>
>
> 1.22.2.1 +16 -6 ws-xmlrpc/src/java/org/apache/xmlrpc/WebServer.java
>
> Index: WebServer.java
> ===================================================================
> RCS file: /home/cvs/ws-xmlrpc/src/java/org/apache/xmlrpc/WebServer.java,v
> retrieving revision 1.22
> retrieving revision 1.22.2.1
> diff -u -u -r1.22 -r1.22.2.1
> --- WebServer.java 3 Dec 2002 17:22:26 -0000 1.22
> +++ WebServer.java 1 May 2004 00:39:05 -0000 1.22.2.1
> @@ -600,19 +600,23 @@
> }
> catch (EmptyStackException empty)
> {
> - if (runners.activeCount () > 255)
> + int maxRequests = XmlRpc.getMaxThreads();
> + if (runners.activeCount() > XmlRpc.getMaxThreads())
> {
> - throw new RuntimeException("System overload");
> + throw new RuntimeException("System overload: Maximum number " +
> + "of concurrent requests (" +
> + maxRequests + ") exceeded");
> }
> return new Runner();
> }
> }
>
> /**
> + * Put <code>runner</code> back into {@link #threadpool}.
> *
> - * @param runner
> + * @param runner The instance to reclaim.
> */
> - void releaseRunner(Runner runner)
> + void repoolRunner(Runner runner)
> {
> threadpool.push(runner);
> }
> @@ -642,6 +646,7 @@
> }
> else
> {
> + // Wake the thread waiting in our run() method.
> this.notify();
> }
> }
> @@ -659,11 +664,13 @@
>
> if (count > 200 || threadpool.size() > 20)
> {
> + // We're old, or the number of threads in the pool
> + // is large.
> return;
> }
> synchronized(this)
> {
> - releaseRunner(this);
> + repoolRunner(this);
> try
> {
> this.wait();
> @@ -790,10 +797,13 @@
> }
> catch (Exception exception)
> {
> - System.err.println(exception);
> if (XmlRpc.debug)
> {
> exception.printStackTrace();
> + }
> + else
> + {
> + System.err.println(exception);
> }
> }
> finally
>
>
>