[prev in list] [next in list] [prev in thread] [next in thread]
List: xmlrpc-user
Subject: RE: Client side timeout?
From: "Petersen, Jennifer" <Jennifer.Petersen () cbsa-asfc ! gc ! ca>
Date: 2006-02-21 21:43:55
Message-ID: 5FA18F6F32A3D711A5AD00B0D0D1B5D7070B1764 () sh24x694 ! rc ! gc ! ca
[Download RAW message or body]
[Attachment #2 (text/plain)]
I am able to manage my own threads .. just not allowed to :)
-----Original Message-----
From: John Buren Southerland [mailto:john@southerland-consulting.com]
Sent: February 21, 2006 4:40 PM
To: xmlrpc-user@ws.apache.org
Subject: RE: Client side timeout?
You should still be able to manage your own threads, though that could wander outside \
of the thread pool management.
I poked at the code though I would not feel comfortable trying to add a timeout like \
that, which is unsupported in a jvm previous to 1.5
I need a better timeout as well.
I just realized that this was on the XMLRPC thread, I had been watching the \
HttpClient thread to see if anyone had a response on a proposal for a way to set a \
user timeout to go along with the connection and socket timeouts already supported. \
That support however, was added because the underlying jvm started supporting those \
features on the socket class. This timeout would need to be handled in the method \
execution.
here is what I use in another application for timeouts of httpclient requests:
private class TimeoutTimer extends TimerTask {
private HttpMethod method=null;
private int timeout=0;
public void setTimeout( int i ) { timeout = i; }
public int getTimeout() { return timeout; }
public void setMethod( Object i ) { this.method = (HttpMethod)
i; }
public HttpMethod getMethod() { return method; }
public void run() {
logger.error("Fetch URL Timed Out Due to user timeout of "+
(int) timeout/1000 +" seconds being reached");
method.abort();
method=null;
}
}
then schedule it (using java 1.5) and execute your method:
TimeoutTimer timeoutTimer = new TimeoutTimer();
Timer timer = new Timer();
//then create your method as usual.....
timeoutTimer.setMethod(getMethod);
timeoutTimer.setTimeout(userTimeout);
timer.schedule(timeoutTimer, userTimeout);
httpClient.executeMethod(getMethod);
timer.cancel();
Arguably, their must be a better way. Does anyone do anything smarter/faster/better?
Thanks, John
On Tue, 2006-02-21 at 15:56 -0500, Petersen, Jennifer wrote:
I'm limited in what I can do because of J2EE/Websphere/Corporate standards. The \
request is part of a global transaction running on an applciation server thread in \
Websphere. As well there are issues accessing "container managed resources"on \
application threads.
Bottom line is I need an exectue that does not block forever. seems to me that this \
would be the norm and an execute that waits for data foever the exception. no?
So I am wondering if there is technical or spec reason for not supporting it or is \
it just oversight? ie) what would be involved to add this feature.
thanks.
--
Jennifer
-----Original Message-----
From: John Buren Southerland [mailto:john@southerland-consulting.com]
Sent: February 21, 2006 2:54 PM
To: xmlrpc-user@ws.apache.org
Subject: Re: Client side timeout?
Jennifer,
I have to do it now with a thread implementing a sort of sigalarm, I don't see any \
other way to do it. Why can you not use another thread?
On Tue, 2006-02-21 at 14:13 -0500, Petersen, Jennifer wrote:
I've searched high and low and can't seem to find a way to set a client side timeout \
on a request.
My requirement is to return with an error when a response to a request is not \
returned within our SLA (say 2 seconds). Note that I cannot manage threads nor can I \
control this at the service level (I don't own the server code).
I know this question has been asked before but I don't see answers/recommendations, \
other than a suggestion to
use commons HttpClient. Is this the recommended approach? any sample code, hint? \
anyone? :)
thanks.
--
Jennifer
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<META content="MSHTML 6.00.2800.1458" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=492144421-21022006><FONT face=Arial color=#0000ff size=2>I am
able to manage my own threads .. just not allowed to :)</FONT></SPAN></DIV>
<DIV><SPAN class=492144421-21022006></SPAN><SPAN class=492144421-21022006><FONT
face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=492144421-21022006></SPAN><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> John Buren Southerland
[mailto:john@southerland-consulting.com]<BR><B>Sent:</B> February 21, 2006 4:40
PM<BR><B>To:</B> xmlrpc-user@ws.apache.org<BR><B>Subject:</B> RE: Client side
timeout?<BR><BR></DIV></FONT>
<BLOCKQUOTE>You should still be able to manage your own threads, though that
could wander outside of the thread pool management.<BR><BR>I poked at the code
though I would not feel comfortable trying to add a timeout like that, which
is unsupported in a jvm previous to 1.5<BR><BR>I need a better timeout as
well.<BR><BR>I just realized that this was on the XMLRPC thread, I had been
watching the HttpClient thread to see if anyone had a response on a proposal
for a way to set a user timeout to go along with the connection and socket
timeouts already supported. That support however, was added because the
underlying jvm started supporting those features on the socket class.
This timeout would need to be handled in the method execution.<BR><BR>here is
what I use in another application for timeouts of httpclient
requests:<BR><TT> private class TimeoutTimer extends
TimerTask {</TT><BR><TT> private
HttpMethod method=null;</TT><BR><TT>
private int timeout=0;</TT><BR><TT>
public void setTimeout( int i ) { timeout = i;
}</TT><BR><TT> public int
getTimeout() { return timeout;
}</TT><BR><TT> public void
setMethod( Object i ) { this.method = (HttpMethod)</TT><BR><TT>i;
}</TT><BR><TT> public HttpMethod
getMethod() { return method;
}</TT><BR><BR><TT> public void run()
{</TT><BR><TT>
logger.error("Fetch URL Timed Out Due to user timeout of "+</TT><BR><TT>(int)
timeout/1000 +" seconds being
reached");</TT><BR><TT> \
method.abort();</TT><BR><TT> \
method=null;</TT><BR><TT>
}</TT><BR><TT> }</TT><BR><BR><TT>then schedule it (using
java 1.5) and execute your method:</TT><BR><TT> TimeoutTimer
timeoutTimer = new TimeoutTimer();</TT><BR><TT> Timer timer
= new Timer();</TT><BR><BR><TT> //then create your method as
usual.....</TT><BR><BR><TT>
timeoutTimer.setMethod(getMethod);</TT><BR><TT>
timeoutTimer.setTimeout(userTimeout);</TT><BR><TT>
timer.schedule(timeoutTimer, userTimeout);</TT><BR><TT>
httpClient.executeMethod(getMethod);</TT><BR><TT>
timer.cancel();</TT><BR><BR>Arguably, their must be a better way. Does
anyone do anything smarter/faster/better?<BR>Thanks, John<BR><BR>On Tue,
2006-02-21 at 15:56 -0500, Petersen, Jennifer wrote:<BR>
<BLOCKQUOTE TYPE="CITE"><FONT size=2><FONT color=#0000ff>I'm limited in what
I can do because of J2EE/Websphere/Corporate standards. The request is part
of a global transaction running on an applciation server thread in
Websphere. As well there are issues accessing "container managed
resources"on application threads.</FONT></FONT><BR><FONT
color=#000000> </FONT><BR><FONT size=2><FONT color=#0000ff>Bottom line
is I need an exectue that does not block forever. seems to me that
this would be the norm and an execute that waits for data foever the
exception. no?</FONT></FONT><BR><FONT color=#000000> </FONT><BR><FONT
size=2><FONT color=#0000ff>So I am wondering if there is
technical or spec reason for not supporting it or is it just
oversight? </FONT></FONT><BR><FONT size=2><FONT color=#0000ff>ie) what would
be involved to add this feature. </FONT></FONT><BR><FONT
color=#000000> </FONT><BR><FONT size=2><FONT
color=#0000ff>thanks.</FONT></FONT><BR><FONT
color=#000000> </FONT><BR><FONT size=2><FONT
color=#0000ff>--</FONT></FONT><BR><FONT size=2><FONT
color=#0000ff>Jennifer</FONT></FONT><BR><FONT
color=#000000> </FONT><BR><FONT color=#000000> </FONT><BR><FONT
size=2><FONT color=#000000>-----Original
Message-----</FONT></FONT><BR><B><FONT size=2><FONT
color=#000000>From:</FONT></FONT></B><FONT color=#000000><FONT size=2> John
Buren Southerland
[mailto:john@southerland-consulting.com]</FONT></FONT><BR><B><FONT
size=2><FONT color=#000000>Sent:</FONT></FONT></B><FONT color=#000000><FONT
size=2> February 21, 2006 2:54 PM</FONT></FONT><BR><B><FONT size=2><FONT
color=#000000>To:</FONT></FONT></B><FONT color=#000000><FONT size=2>
xmlrpc-user@ws.apache.org</FONT></FONT><BR><B><FONT size=2><FONT
color=#000000>Subject:</FONT></FONT></B><FONT color=#000000><FONT size=2>
Re: Client side timeout?</FONT></FONT><BR><BR><BR>
<BLOCKQUOTE><FONT color=#000000>Jennifer,</FONT><BR><FONT color=#000000>I
have to do it now with a thread implementing a sort of sigalarm, I don't
see any other way to do it. </FONT><BR><FONT color=#000000>Why
can you not use another thread? </FONT><BR><BR><FONT color=#000000>On Tue,
2006-02-21 at 14:13 -0500, Petersen, Jennifer wrote: </FONT>
<BLOCKQUOTE TYPE="CITE"><PRE><FONT color=#000000>I've searched high and low and \
can't seem to find a way to set a client side timeout on a request. </FONT>
<FONT color=#000000>My requirement is to return with an error when a response to a \
request is not returned within our SLA (say 2 seconds). Note that I cannot manage \
threads nor can I control this at the service level (I don't own the server \
code).</FONT>
<FONT color=#000000>I know this question has been asked before but I don't see \
answers/recommendations, other than a suggestion to </FONT> <FONT color=#000000>use \
commons HttpClient. Is this the recommended approach? any sample code, hint? anyone? \
:) </FONT>
<FONT color=#000000>thanks.</FONT>
<FONT color=#000000>--</FONT>
<FONT color=#000000>Jennifer</FONT>
</PRE></BLOCKQUOTE>
<TABLE cellSpacing=0 cellPadding=0 width="100%">
<TBODY>
<TR>
<TD>
<ADDRESS><BR></ADDRESS><BR></TD></TR></TBODY></TABLE></BLOCKQUOTE></BLOCKQUOTE>
<TABLE cellSpacing=0 cellPadding=0 width="100%">
<TBODY>
<TR>
<TD>
<ADDRESS><BR></ADDRESS></TD></TR></TBODY></TABLE></BLOCKQUOTE></BODY></HTML>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic