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 Jim Redman <ji...@ergotech.com> on 2002/02/27 13:42:06 UTC
Keep-alive timeout
The code in the exception clause of:
public void write (byte[] request) throws IOException
in XmlRpcClientLite does not seem to be effective in handling keep-alive
timeouts. The solution that works for me is to repeat the call to:
Object execute (String method,
Vector params) throws XmlRpcException, IOException
{
the code we've been using looks like this:
public Object execute (String method, Vector params)
throws XmlRpcException, IOException
{
try {
return executeInternal(method, params);
} catch (Exception e) {
System.err.println("Warning: Execute Internal (" + method + ") -
" + e.getMessage() + " transient error - retrying");
}
// we'll give it two attempts, if it fails the first time it will
// come here for a retry
client = null; // make sure
return executeInternal(method, params);
}
public Object executeInternal (String method, Vector params)
<<<<----- the old execute method
throws XmlRpcException, IOException
{
Unless someone has a better solution, I'd like to get the code into the
distro so that I don't have to modify future releases of the library.
Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Keep-alive timeout
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jim Redman <ji...@ergotech.com> writes:
> The code in the exception clause of:
>
> public void write (byte[] request) throws IOException
>
> in XmlRpcClientLite does not seem to be effective in handling
> keep-alive timeouts. The solution that works for me is to repeat the
> call to:
>
> Object execute (String method,
> Vector params) throws XmlRpcException, IOException
> {
>
> the code we've been using looks like this:
>
> public Object execute (String method, Vector params)
> throws XmlRpcException, IOException
> {
> try {
> return executeInternal(method, params);
> } catch (Exception e) {
> System.err.println("Warning: Execute Internal (" + method +
> ") -
> " + e.getMessage() + " transient error - retrying");
> }
>
> // we'll give it two attempts, if it fails the first time it will
> // come here for a retry
> client = null; // make sure
> return executeInternal(method, params);
> }
>
>
> public Object executeInternal (String method, Vector params)
> <<<<----- the old execute method
> throws XmlRpcException, IOException
> {
>
> Unless someone has a better solution, I'd like to get the code into
> the distro so that I don't have to modify future releases of the
> library.
Interesting. Submit a patch <http://jakarta.apache.org/site/source.html>
with multiple retries (so a constant or something can be changed to
configure the number of retries to attempt), and remove the early
return. Also, I'm not especially familiar with the client code, but
does this change belong in the XmlRpcClient super-class?
Dan
Re: Keep-alive timeout
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jim Redman <ji...@ergotech.com> writes:
> The code in the exception clause of:
>
> public void write (byte[] request) throws IOException
>
> in XmlRpcClientLite does not seem to be effective in handling
> keep-alive timeouts. The solution that works for me is to repeat the
> call to:
>
> Object execute (String method,
> Vector params) throws XmlRpcException, IOException
> {
>
> the code we've been using looks like this:
>
> public Object execute (String method, Vector params)
> throws XmlRpcException, IOException
> {
> try {
> return executeInternal(method, params);
> } catch (Exception e) {
> System.err.println("Warning: Execute Internal (" + method +
> ") -
> " + e.getMessage() + " transient error - retrying");
> }
>
> // we'll give it two attempts, if it fails the first time it will
> // come here for a retry
> client = null; // make sure
> return executeInternal(method, params);
> }
>
>
> public Object executeInternal (String method, Vector params)
> <<<<----- the old execute method
> throws XmlRpcException, IOException
> {
>
> Unless someone has a better solution, I'd like to get the code into
> the distro so that I don't have to modify future releases of the
> library.
Interesting. Submit a patch <http://jakarta.apache.org/site/source.html>
with multiple retries (so a constant or something can be changed to
configure the number of retries to attempt), and remove the early
return. Also, I'm not especially familiar with the client code, but
does this change belong in the XmlRpcClient super-class?
Dan
Re: Keep-alive timeout
Posted by Hannes Wallnöfer <ha...@helma.at>.
Jim,
I just committed a fix for the problem to CVS. The solution I used is
slightly different from yours: Instead of the whole LiteWorker.execute()
method, only the sending of the request and the parsing of the response
headers are put into a try-retry wrapper. Otherwise, we'd retry to call
the server even if the first call actually got through already and the
error occurred somewhere later, e.g. when parsing the response.
thanks,
Hannes
Jim Redman wrote:
> On 2002.02.27 08:43:34 -0700 Hannes Wallnöfer wrote:
>
>> Thanks Jim. One problem I see with your solution is that it retries
>> on *every* exception, which is not what we want (or do we?). I'll
>> give it a try.
>
>
>
> I'm not sure that there is sufficient information at this point to
> determine whether the write failed because of an expired keep-alive or
> for other reasons. In a practical sense, once the system is running
> we see exceptions here only because of failed keep-alives.
>
> Which leads into Dan's point
> On 2002.02.27 08:31:58 -0700 Daniel Rall wrote:
>
>> Interesting. Submit a patch
>> <http://jakarta.apache.org/site/source.html>
>> with multiple retries (so a constant or something can be changed to
>> configure the number of retries to attempt), and remove the early
>> return.
>
>
> The number of retries is exactly one if the cause of the failure is an
> expired keep-alive. The system should not just quit becuase the
> keep-alive expired, but if the (single) retry doesn't succeed then the
> problem is not an expired keep-alive.
>
>> Also, I'm not especially familiar with the client code, but
>> does this change belong in the XmlRpcClient super-class?
>
>
> I have no idea - I don't use the XmlRpcClient directly, only the Lite
> so I don't know the behavior of the XmlRpcClient in this case.
>
>
> Jim
>
>
Re: Keep-alive timeout
Posted by Hannes Wallnöfer <ha...@helma.at>.
Jim Redman wrote:
> Dan,
>
> On 2002.02.27 11:10:10 -0700 Daniel Rall wrote:
>
>> Jim Redman <ji...@ergotech.com> writes:
>>
>> > I have no idea - I don't use the XmlRpcClient directly, only the Lite
>> > so I don't know the behavior of the XmlRpcClient in this case.
>>
>> public class XmlRpcClientLite
>> extends XmlRpcClient
>>
>
> Surely, but the action is in the "Worker" and I have no idea whether
> the behavior of the XmlRpcClient.Worker is the same as
> XmlRpcClientLite.LiteWorker. The execute methods are completely
> different and may, or may not, exhibit the same problems.
>
> If they don't, perhaps my fix is entirly at the wrong level and the
> problem is correctable lower in the protocol. If they do, then
> probably the fix should be applied in the superclass.
>
> Jim
>
I'm sure this was a problem of the XmlRpcClientLite class only.
XmlRpcClient uses java.net.URLConnection, and even if it should use
keepalive it definitely doesn't put the burden of checking for keepalive
intricacies (like closed connections) on the programmer.
Hannes
Re: Keep-alive timeout
Posted by Hannes Wallnöfer <ha...@helma.at>.
Jim Redman wrote:
> Dan,
>
> On 2002.02.27 11:10:10 -0700 Daniel Rall wrote:
>
>> Jim Redman <ji...@ergotech.com> writes:
>>
>> > I have no idea - I don't use the XmlRpcClient directly, only the Lite
>> > so I don't know the behavior of the XmlRpcClient in this case.
>>
>> public class XmlRpcClientLite
>> extends XmlRpcClient
>>
>
> Surely, but the action is in the "Worker" and I have no idea whether
> the behavior of the XmlRpcClient.Worker is the same as
> XmlRpcClientLite.LiteWorker. The execute methods are completely
> different and may, or may not, exhibit the same problems.
>
> If they don't, perhaps my fix is entirly at the wrong level and the
> problem is correctable lower in the protocol. If they do, then
> probably the fix should be applied in the superclass.
>
> Jim
>
I'm sure this was a problem of the XmlRpcClientLite class only.
XmlRpcClient uses java.net.URLConnection, and even if it should use
keepalive it definitely doesn't put the burden of checking for keepalive
intricacies (like closed connections) on the programmer.
Hannes
Re: Keep-alive timeout
Posted by Jim Redman <ji...@ergotech.com>.
Dan,
On 2002.02.27 11:10:10 -0700 Daniel Rall wrote:
> Jim Redman <ji...@ergotech.com> writes:
>
> > I have no idea - I don't use the XmlRpcClient directly, only the Lite
> > so I don't know the behavior of the XmlRpcClient in this case.
>
> public class XmlRpcClientLite
> extends XmlRpcClient
>
Surely, but the action is in the "Worker" and I have no idea whether the
behavior of the XmlRpcClient.Worker is the same as
XmlRpcClientLite.LiteWorker. The execute methods are completely different
and may, or may not, exhibit the same problems.
If they don't, perhaps my fix is entirly at the wrong level and the
problem is correctable lower in the protocol. If they do, then probably
the fix should be applied in the superclass.
Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Keep-alive timeout
Posted by Jim Redman <ji...@ergotech.com>.
Dan,
On 2002.02.27 11:10:10 -0700 Daniel Rall wrote:
> Jim Redman <ji...@ergotech.com> writes:
>
> > I have no idea - I don't use the XmlRpcClient directly, only the Lite
> > so I don't know the behavior of the XmlRpcClient in this case.
>
> public class XmlRpcClientLite
> extends XmlRpcClient
>
Surely, but the action is in the "Worker" and I have no idea whether the
behavior of the XmlRpcClient.Worker is the same as
XmlRpcClientLite.LiteWorker. The execute methods are completely different
and may, or may not, exhibit the same problems.
If they don't, perhaps my fix is entirly at the wrong level and the
problem is correctable lower in the protocol. If they do, then probably
the fix should be applied in the superclass.
Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Keep-alive timeout
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jim Redman <ji...@ergotech.com> writes:
> I have no idea - I don't use the XmlRpcClient directly, only the Lite
> so I don't know the behavior of the XmlRpcClient in this case.
public class XmlRpcClientLite
extends XmlRpcClient
Re: Keep-alive timeout
Posted by Hannes Wallnöfer <ha...@helma.at>.
Jim,
I just committed a fix for the problem to CVS. The solution I used is
slightly different from yours: Instead of the whole LiteWorker.execute()
method, only the sending of the request and the parsing of the response
headers are put into a try-retry wrapper. Otherwise, we'd retry to call
the server even if the first call actually got through already and the
error occurred somewhere later, e.g. when parsing the response.
thanks,
Hannes
Jim Redman wrote:
> On 2002.02.27 08:43:34 -0700 Hannes Wallnöfer wrote:
>
>> Thanks Jim. One problem I see with your solution is that it retries
>> on *every* exception, which is not what we want (or do we?). I'll
>> give it a try.
>
>
>
> I'm not sure that there is sufficient information at this point to
> determine whether the write failed because of an expired keep-alive or
> for other reasons. In a practical sense, once the system is running
> we see exceptions here only because of failed keep-alives.
>
> Which leads into Dan's point
> On 2002.02.27 08:31:58 -0700 Daniel Rall wrote:
>
>> Interesting. Submit a patch
>> <http://jakarta.apache.org/site/source.html>
>> with multiple retries (so a constant or something can be changed to
>> configure the number of retries to attempt), and remove the early
>> return.
>
>
> The number of retries is exactly one if the cause of the failure is an
> expired keep-alive. The system should not just quit becuase the
> keep-alive expired, but if the (single) retry doesn't succeed then the
> problem is not an expired keep-alive.
>
>> Also, I'm not especially familiar with the client code, but
>> does this change belong in the XmlRpcClient super-class?
>
>
> I have no idea - I don't use the XmlRpcClient directly, only the Lite
> so I don't know the behavior of the XmlRpcClient in this case.
>
>
> Jim
>
>
Re: Keep-alive timeout
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jim Redman <ji...@ergotech.com> writes:
> I have no idea - I don't use the XmlRpcClient directly, only the Lite
> so I don't know the behavior of the XmlRpcClient in this case.
public class XmlRpcClientLite
extends XmlRpcClient
Re: Keep-alive timeout
Posted by Jim Redman <ji...@ergotech.com>.
On 2002.02.27 08:43:34 -0700 Hannes Wallnöfer wrote:
> Thanks Jim. One problem I see with your solution is that it retries on
> *every* exception, which is not what we want (or do we?). I'll give it a
> try.
I'm not sure that there is sufficient information at this point to
determine whether the write failed because of an expired keep-alive or for
other reasons. In a practical sense, once the system is running we see
exceptions here only because of failed keep-alives.
Which leads into Dan's point
On 2002.02.27 08:31:58 -0700 Daniel Rall wrote:
> Interesting. Submit a patch <http://jakarta.apache.org/site/source.html>
> with multiple retries (so a constant or something can be changed to
> configure the number of retries to attempt), and remove the early
> return.
The number of retries is exactly one if the cause of the failure is an
expired keep-alive. The system should not just quit becuase the
keep-alive expired, but if the (single) retry doesn't succeed then the
problem is not an expired keep-alive.
> Also, I'm not especially familiar with the client code, but
> does this change belong in the XmlRpcClient super-class?
I have no idea - I don't use the XmlRpcClient directly, only the Lite so I
don't know the behavior of the XmlRpcClient in this case.
Jim
>
>
> Jim Redman wrote:
>
>>
>> The code in the exception clause of:
>>
>> public void write (byte[] request) throws IOException
>>
>> in XmlRpcClientLite does not seem to be effective in handling
>> keep-alive timeouts. The solution that works for me is to repeat the
>> call to:
>>
>> Object execute (String method,
>> Vector params) throws XmlRpcException, IOException
>> {
>>
>> the code we've been using looks like this:
>>
>> public Object execute (String method, Vector params)
>> throws XmlRpcException, IOException
>> {
>> try {
>> return executeInternal(method, params);
>> } catch (Exception e) {
>> System.err.println("Warning: Execute Internal (" + method + ")
>> - " + e.getMessage() + " transient error - retrying");
>> }
>>
>> // we'll give it two attempts, if it fails the first time it will
>> // come here for a retry
>> client = null; // make sure
>> return executeInternal(method, params);
>> }
>>
>>
>> public Object executeInternal (String method, Vector params)
>> <<<<----- the old execute method
>> throws XmlRpcException, IOException
>> {
>>
>> Unless someone has a better solution, I'd like to get the code into the
>> distro so that I don't have to modify future releases of the library.
>>
>> Jim
>>
>
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Keep-alive timeout
Posted by Jim Redman <ji...@ergotech.com>.
On 2002.02.27 08:43:34 -0700 Hannes Wallnöfer wrote:
> Thanks Jim. One problem I see with your solution is that it retries on
> *every* exception, which is not what we want (or do we?). I'll give it a
> try.
I'm not sure that there is sufficient information at this point to
determine whether the write failed because of an expired keep-alive or for
other reasons. In a practical sense, once the system is running we see
exceptions here only because of failed keep-alives.
Which leads into Dan's point
On 2002.02.27 08:31:58 -0700 Daniel Rall wrote:
> Interesting. Submit a patch <http://jakarta.apache.org/site/source.html>
> with multiple retries (so a constant or something can be changed to
> configure the number of retries to attempt), and remove the early
> return.
The number of retries is exactly one if the cause of the failure is an
expired keep-alive. The system should not just quit becuase the
keep-alive expired, but if the (single) retry doesn't succeed then the
problem is not an expired keep-alive.
> Also, I'm not especially familiar with the client code, but
> does this change belong in the XmlRpcClient super-class?
I have no idea - I don't use the XmlRpcClient directly, only the Lite so I
don't know the behavior of the XmlRpcClient in this case.
Jim
>
>
> Jim Redman wrote:
>
>>
>> The code in the exception clause of:
>>
>> public void write (byte[] request) throws IOException
>>
>> in XmlRpcClientLite does not seem to be effective in handling
>> keep-alive timeouts. The solution that works for me is to repeat the
>> call to:
>>
>> Object execute (String method,
>> Vector params) throws XmlRpcException, IOException
>> {
>>
>> the code we've been using looks like this:
>>
>> public Object execute (String method, Vector params)
>> throws XmlRpcException, IOException
>> {
>> try {
>> return executeInternal(method, params);
>> } catch (Exception e) {
>> System.err.println("Warning: Execute Internal (" + method + ")
>> - " + e.getMessage() + " transient error - retrying");
>> }
>>
>> // we'll give it two attempts, if it fails the first time it will
>> // come here for a retry
>> client = null; // make sure
>> return executeInternal(method, params);
>> }
>>
>>
>> public Object executeInternal (String method, Vector params)
>> <<<<----- the old execute method
>> throws XmlRpcException, IOException
>> {
>>
>> Unless someone has a better solution, I'd like to get the code into the
>> distro so that I don't have to modify future releases of the library.
>>
>> Jim
>>
>
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: Keep-alive timeout
Posted by Hannes Wallnöfer <ha...@helma.at>.
Thanks Jim. One problem I see with your solution is that it retries on
*every* exception, which is not what we want (or do we?). I'll give it a
try.
Hannes
Jim Redman wrote:
>
> The code in the exception clause of:
>
> public void write (byte[] request) throws IOException
>
> in XmlRpcClientLite does not seem to be effective in handling
> keep-alive timeouts. The solution that works for me is to repeat the
> call to:
>
> Object execute (String method,
> Vector params) throws XmlRpcException, IOException
> {
>
> the code we've been using looks like this:
>
> public Object execute (String method, Vector params)
> throws XmlRpcException, IOException
> {
> try {
> return executeInternal(method, params);
> } catch (Exception e) {
> System.err.println("Warning: Execute Internal (" + method + ")
> - " + e.getMessage() + " transient error - retrying");
> }
>
> // we'll give it two attempts, if it fails the first time it will
> // come here for a retry
> client = null; // make sure
> return executeInternal(method, params);
> }
>
>
> public Object executeInternal (String method, Vector params)
> <<<<----- the old execute method
> throws XmlRpcException, IOException
> {
>
> Unless someone has a better solution, I'd like to get the code into
> the distro so that I don't have to modify future releases of the library.
>
> Jim
>
Re: Keep-alive timeout
Posted by Hannes Wallnöfer <ha...@helma.at>.
Thanks Jim. One problem I see with your solution is that it retries on
*every* exception, which is not what we want (or do we?). I'll give it a
try.
Hannes
Jim Redman wrote:
>
> The code in the exception clause of:
>
> public void write (byte[] request) throws IOException
>
> in XmlRpcClientLite does not seem to be effective in handling
> keep-alive timeouts. The solution that works for me is to repeat the
> call to:
>
> Object execute (String method,
> Vector params) throws XmlRpcException, IOException
> {
>
> the code we've been using looks like this:
>
> public Object execute (String method, Vector params)
> throws XmlRpcException, IOException
> {
> try {
> return executeInternal(method, params);
> } catch (Exception e) {
> System.err.println("Warning: Execute Internal (" + method + ")
> - " + e.getMessage() + " transient error - retrying");
> }
>
> // we'll give it two attempts, if it fails the first time it will
> // come here for a retry
> client = null; // make sure
> return executeInternal(method, params);
> }
>
>
> public Object executeInternal (String method, Vector params)
> <<<<----- the old execute method
> throws XmlRpcException, IOException
> {
>
> Unless someone has a better solution, I'd like to get the code into
> the distro so that I don't have to modify future releases of the library.
>
> Jim
>