Re: What governs a URL connection timeout?
On 25-02-10 18:37, Chris Mannion wrote: Very helpful advice. I can't help but feel a little out of my depth with this one :-\ Hi Chris, You may want to check if your JVM is started with one of the following options: -Dsun.net.client.defaultConnectTimeout= -Dsun.net.client.defaultReadTimeout= For both of these the default is -1, which means no timeout is set. For more information: http://java.sun.com/j2se/1.5.0/docs/guide/net/properties.html Regards, Stephan. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What governs a URL connection timeout?
Thanks Chris,
Very helpful advice. I can't help but feel a little out of my depth
with this one :-\
On 19 February 2010 16:46, Christopher Schultz
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Chris,
>
> On 2/19/2010 11:08 AM, Chris Mannion wrote:
>> Thank, genuinely, for the responses, I've learned how I *could* set a
>> timeout, which I didn't know before. However, what I'm actually
>> trying to get to the bottom of is what timeout could be in play
>> *without* me setting it.
>
> Well, try this:
>
> URLConnection t_connection = t_url.openConnection();
> System.out.println("Read timeout for URLConnection: " +
> t_connection.getReadTimeout());
>
> That ought to tell you what the default read timeout is: the Java API
> doesn't specify what the default read timeout is, so it's up to the
> implementation to choose a default. I would expect that the default
> would be 0 (wait forever), but it might not be.
>
>> As I said, the connection is already timing out and I don't want it
>> to.
>
> It's possible that this exception is not accurately reporting the real
> problem. It might be something else happening that is triggering a
> ReadTimeoutException: check the source code for the HttpURLConnection
> class to see if any particular default read timeout is being set, and
> the code for the SocketInputStream class to.. oh, wait, that's a native
> method so you're out of luck, there.
>
>> Shouldn't the socket wait indefinitely for a response if nothing set
>> a finite timeout length?
>
> That's a reasonable expectation, but there's no documentation that says
> that behavior is the default.
>
>> This is code in an already release product so if I can track down an
>> environment setting that's governing the timeout then I can just
>> adjust that setting for the one customer with the problem rather than
>> having to patch the code and release it to everyone.
>
> I think you're going to require a patch, though it's possible that some
> of these defaults are settable via system properties, etc.
>
> I can't find any documentation for java.net.SocketInputStream: it must
> not be a public API. Yup:
>
> /**
> * This stream extends FileInputStream to implement a
> * SocketInputStream. Note that this class should NOT be
> * public.
> *
> * @version 1.34, 12/19/03
> * @author Jonathan Payne
> * @author Arthur van Hoff
> */
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkt+wF0ACgkQ9CaO5/Lv0PAtXACgnS7F/c/VAAa1baQiJMm7oXtm
> lNkAmwXP4ifzV/2xB6NID2ZMhQ7hoeLh
> =TKYk
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
--
Chris Mannion
iCasework and LocalAlert implementation team
0208 144 4416
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What governs a URL connection timeout?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris,
On 2/19/2010 11:08 AM, Chris Mannion wrote:
> Thank, genuinely, for the responses, I've learned how I *could* set a
> timeout, which I didn't know before. However, what I'm actually
> trying to get to the bottom of is what timeout could be in play
> *without* me setting it.
Well, try this:
URLConnection t_connection = t_url.openConnection();
System.out.println("Read timeout for URLConnection: " +
t_connection.getReadTimeout());
That ought to tell you what the default read timeout is: the Java API
doesn't specify what the default read timeout is, so it's up to the
implementation to choose a default. I would expect that the default
would be 0 (wait forever), but it might not be.
> As I said, the connection is already timing out and I don't want it
> to.
It's possible that this exception is not accurately reporting the real
problem. It might be something else happening that is triggering a
ReadTimeoutException: check the source code for the HttpURLConnection
class to see if any particular default read timeout is being set, and
the code for the SocketInputStream class to.. oh, wait, that's a native
method so you're out of luck, there.
> Shouldn't the socket wait indefinitely for a response if nothing set
> a finite timeout length?
That's a reasonable expectation, but there's no documentation that says
that behavior is the default.
> This is code in an already release product so if I can track down an
> environment setting that's governing the timeout then I can just
> adjust that setting for the one customer with the problem rather than
> having to patch the code and release it to everyone.
I think you're going to require a patch, though it's possible that some
of these defaults are settable via system properties, etc.
I can't find any documentation for java.net.SocketInputStream: it must
not be a public API. Yup:
/**
* This stream extends FileInputStream to implement a
* SocketInputStream. Note that this class should NOT be
* public.
*
* @version 1.34, 12/19/03
* @author Jonathan Payne
* @author Arthur van Hoff
*/
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkt+wF0ACgkQ9CaO5/Lv0PAtXACgnS7F/c/VAAa1baQiJMm7oXtm
lNkAmwXP4ifzV/2xB6NID2ZMhQ7hoeLh
=TKYk
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What governs a URL connection timeout?
Guys Thank, genuinely, for the responses, I've learned how I *could* set a timeout, which I didn't know before. However, what I'm actually trying to get to the bottom of is what timeout could be in play *without* me setting it. As I said, the connection is already timing out and I don't want it to. Basically, I can hit the URL in question in a browser and, after a few second, get a response. When that piece of code hits the same URL, the Read timeout exception is thrown. So, it seems to me that the code isn't waiting long enough for the response to arrive, so something seems to be governing how long it waits. As we've established, it's not something that I've done in the code, so what is the timeout based on? Shouldn't the socket wait indefinitely for a response if nothing set a finite timeout length? This is code in an already release product so if I can track down an environment setting that's governing the timeout then I can just adjust that setting for the one customer with the problem rather than having to patch the code and release it to everyone. On 12 February 2010 15:57, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Chuck, > > On 2/12/2010 10:46 AM, Caldarale, Charles R wrote: >>> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >>> Subject: Re: What governs a URL connection timeout? >>> >>> It's possible that (the other) Chris is using a library >> >> The OP already posted the code of interest > > Duh. That's what I get for not reading every word of the OP. > >> Just replace: >> >> InputStream t_inputStream = t_url.openStream(); >> >> with >> >> URLConnection t_connection = t_url.openConnection(); >> t_connection.setReadTimeout(desiredValue); >> InputStream t_inputStrem = t_connection.getInputStream(); > > +1 > > Or, setConnectTimeout() which answers the OP's actual question, but > wouldn't end up solving his problem. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkt1el4ACgkQ9CaO5/Lv0PBcZwCgs0DDTQpjlCzo7QJ+kP84Obo0 > E9UAoIOk6Bm5CLCNWBb1g/jXy9p8hDZ8 > =6wCb > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Chris Mannion iCasework and LocalAlert implementation team 0208 144 4416 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What governs a URL connection timeout?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 2/12/2010 10:46 AM, Caldarale, Charles R wrote: >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Subject: Re: What governs a URL connection timeout? >> >> It's possible that (the other) Chris is using a library > > The OP already posted the code of interest Duh. That's what I get for not reading every word of the OP. > Just replace: > > InputStream t_inputStream = t_url.openStream(); > > with > > URLConnection t_connection = t_url.openConnection(); > t_connection.setReadTimeout(desiredValue); > InputStream t_inputStrem = t_connection.getInputStream(); +1 Or, setConnectTimeout() which answers the OP's actual question, but wouldn't end up solving his problem. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1el4ACgkQ9CaO5/Lv0PBcZwCgs0DDTQpjlCzo7QJ+kP84Obo0 E9UAoIOk6Bm5CLCNWBb1g/jXy9p8hDZ8 =6wCb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: What governs a URL connection timeout?
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: What governs a URL connection timeout? > > It's possible that (the other) Chris is using a library The OP already posted the code of interest, and it would be simple to modify it to set an appropriate timeout value, as Peter pointed out. Just replace: InputStream t_inputStream = t_url.openStream(); with URLConnection t_connection = t_url.openConnection(); t_connection.setReadTimeout(desiredValue); InputStream t_inputStrem = t_connection.getInputStream(); - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: What governs a URL connection timeout?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter, On 2/12/2010 7:34 AM, Peter Crowther wrote: > Chris, did you actually read the link or was that a knee-jerk > response? Notably the following, taken from between the first and > second boxed pieces of code on that page: > > "The openStream() method is actually just a shortcut for > openConnection().getInputStream()." > ... plus the source of openStream() to prove it. > > So, yes, you *are* using a URLConnection internally. And... correct, > you're not setting any timeouts in your code. But you want to. That > page provides code further down that allows you to set such a timeout. It's possible that (the other) Chris is using a library (ep.ext, whatever that is) that hides the complexities of the connection, etc. His only recourse might be to abandon the use of that library and instead code directly to URLConnection, where he /can/ set timeouts. I'd first check the ep.ext library, though. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1cpEACgkQ9CaO5/Lv0PCsagCdENcFHvtDaZi+sJGfOsj3Ok/f kTYAoJYammldKfhOU5x/FpIFTB7oUrzQ =XoCj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What governs a URL connection timeout?
Chris, did you actually read the link or was that a knee-jerk
response? Notably the following, taken from between the first and
second boxed pieces of code on that page:
"The openStream() method is actually just a shortcut for
openConnection().getInputStream()."
... plus the source of openStream() to prove it.
So, yes, you *are* using a URLConnection internally. And... correct,
you're not setting any timeouts in your code. But you want to. That
page provides code further down that allows you to set such a timeout.
- Peter
On 12 February 2010 12:24, Chris Mannion wrote:
> Thanks Peter but we're not using a URLConnection, nor are we
> explicitly setting any timeouts, as you can see from the code.
>
> On 12 February 2010 12:06, Peter Crowther wrote:
>> A swift Google for:
>> java url openStream timeout
>> reveals:
>> http://stuffthathappens.com/blog/2007/09/10/urlopenstream-might-leave-you-hanging/
>> as its first hit.
>>
>> In essence: the timeout is controlled by setTimeout on UrlConnection.
>>
>> On 12 February 2010 11:59, Chris Mannion wrote:
>>> Hi all
>>>
>>> Hoping someone can shed some light on a little puzzle I have. This
>>> may be more a Java programming problem than a Tomcat problem so
>>> apologies if that is the case but it's specific to a system running on
>>> Tomcat so I'm asking here too. One of our servlets is opening a URL
>>> connection to hit an external URL, the external URL can sometimes take
>>> a while to respond and when that happens the URL connection throws a
>>> socket timeout exception (see the stack trace below). What I can't
>>> work out is what determines how long the connection waits before it
>>> times-out, we don't set anything explicitly in our code and it doesn't
>>> seem to be related to the servlet timeout in the connector, does
>>> anyone know what determines the timeout length and how it can be
>>> changed? The code is simply -
>>>
>>> public void outputUrl(OutputStream p_out, String p_url) {
>>> try {
>>> URL t_url = new URL(p_url);
>>> InputStream t_inputStream = t_url.openStream();
>>> // Read from the input stream, and write to the output stream
>>> byte[] l_buffer = new byte[10]; // buffer holding bytes to
>>> be transferred
>>> int l_nbytes = 0; // Number of bytes read
>>> while ((l_nbytes = t_inputStream.read(l_buffer)) != -1)
>>> p_out.write(l_buffer,0,l_nbytes);
>>> t_inputStream.close();
>>> }
>>> catch (Exception e)
>>> {
>>> nsglog.error(String.valueOf(e), e);
>>> }
>>> }
>>>
>>> The error trace is -
>>>
>>> java.net.SocketTimeoutException: Read timed out
>>> at java.net.SocketInputStream.socketRead0(Native Method)
>>> at java.net.SocketInputStream.read(SocketInputStream.java:129)
>>> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
>>> at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
>>> at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
>>> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:659)
>>> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:604)
>>> at
>>> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:961)
>>> at java.net.URL.openStream(URL.java:1007)
>>> at ep.ext.outputUrl(ext.java:446)
>>>
>>> So it's the attempt to open the input stream on the URL that is timing
>>> out, what governs that timeout?
>>>
>>> --
>>> Chris Mannion
>>> iCasework and LocalAlert implementation team
>>> 0208 144 4416
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
>
>
> --
> Chris Mannion
> iCasework and LocalAlert implementation team
> 0208 144 4416
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What governs a URL connection timeout?
Thanks Peter but we're not using a URLConnection, nor are we
explicitly setting any timeouts, as you can see from the code.
On 12 February 2010 12:06, Peter Crowther wrote:
> A swift Google for:
> java url openStream timeout
> reveals:
> http://stuffthathappens.com/blog/2007/09/10/urlopenstream-might-leave-you-hanging/
> as its first hit.
>
> In essence: the timeout is controlled by setTimeout on UrlConnection.
>
> On 12 February 2010 11:59, Chris Mannion wrote:
>> Hi all
>>
>> Hoping someone can shed some light on a little puzzle I have. This
>> may be more a Java programming problem than a Tomcat problem so
>> apologies if that is the case but it's specific to a system running on
>> Tomcat so I'm asking here too. One of our servlets is opening a URL
>> connection to hit an external URL, the external URL can sometimes take
>> a while to respond and when that happens the URL connection throws a
>> socket timeout exception (see the stack trace below). What I can't
>> work out is what determines how long the connection waits before it
>> times-out, we don't set anything explicitly in our code and it doesn't
>> seem to be related to the servlet timeout in the connector, does
>> anyone know what determines the timeout length and how it can be
>> changed? The code is simply -
>>
>> public void outputUrl(OutputStream p_out, String p_url) {
>> try {
>> URL t_url = new URL(p_url);
>> InputStream t_inputStream = t_url.openStream();
>> // Read from the input stream, and write to the output stream
>> byte[] l_buffer = new byte[10]; // buffer holding bytes to
>> be transferred
>> int l_nbytes = 0; // Number of bytes read
>> while ((l_nbytes = t_inputStream.read(l_buffer)) != -1)
>> p_out.write(l_buffer,0,l_nbytes);
>> t_inputStream.close();
>> }
>> catch (Exception e)
>> {
>> nsglog.error(String.valueOf(e), e);
>> }
>> }
>>
>> The error trace is -
>>
>> java.net.SocketTimeoutException: Read timed out
>> at java.net.SocketInputStream.socketRead0(Native Method)
>> at java.net.SocketInputStream.read(SocketInputStream.java:129)
>> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
>> at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
>> at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
>> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:659)
>> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:604)
>> at
>> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:961)
>> at java.net.URL.openStream(URL.java:1007)
>> at ep.ext.outputUrl(ext.java:446)
>>
>> So it's the attempt to open the input stream on the URL that is timing
>> out, what governs that timeout?
>>
>> --
>> Chris Mannion
>> iCasework and LocalAlert implementation team
>> 0208 144 4416
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
--
Chris Mannion
iCasework and LocalAlert implementation team
0208 144 4416
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What governs a URL connection timeout?
A swift Google for:
java url openStream timeout
reveals:
http://stuffthathappens.com/blog/2007/09/10/urlopenstream-might-leave-you-hanging/
as its first hit.
In essence: the timeout is controlled by setTimeout on UrlConnection.
On 12 February 2010 11:59, Chris Mannion wrote:
> Hi all
>
> Hoping someone can shed some light on a little puzzle I have. This
> may be more a Java programming problem than a Tomcat problem so
> apologies if that is the case but it's specific to a system running on
> Tomcat so I'm asking here too. One of our servlets is opening a URL
> connection to hit an external URL, the external URL can sometimes take
> a while to respond and when that happens the URL connection throws a
> socket timeout exception (see the stack trace below). What I can't
> work out is what determines how long the connection waits before it
> times-out, we don't set anything explicitly in our code and it doesn't
> seem to be related to the servlet timeout in the connector, does
> anyone know what determines the timeout length and how it can be
> changed? The code is simply -
>
> public void outputUrl(OutputStream p_out, String p_url) {
> try {
> URL t_url = new URL(p_url);
> InputStream t_inputStream = t_url.openStream();
> // Read from the input stream, and write to the output stream
> byte[] l_buffer = new byte[10]; // buffer holding bytes to
> be transferred
> int l_nbytes = 0; // Number of bytes read
> while ((l_nbytes = t_inputStream.read(l_buffer)) != -1)
> p_out.write(l_buffer,0,l_nbytes);
> t_inputStream.close();
> }
> catch (Exception e)
> {
> nsglog.error(String.valueOf(e), e);
> }
> }
>
> The error trace is -
>
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:129)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:659)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:604)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:961)
> at java.net.URL.openStream(URL.java:1007)
> at ep.ext.outputUrl(ext.java:446)
>
> So it's the attempt to open the input stream on the URL that is timing
> out, what governs that timeout?
>
> --
> Chris Mannion
> iCasework and LocalAlert implementation team
> 0208 144 4416
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
