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?
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?
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
What governs a URL connection timeout?
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
Re: Odd encoding of servlet parameters
André
Thanks for the comments, I will definitely look into the approach of
sending the data in the request body, probably something that should
have been done originally.
It's true that the program sending the data is ours as well but I
don't suspect it to be the culprit because the problem doesn't occur
in a way consistent with that. For example, I can send data from my
local client to my local server and it arrives intact but when I send
the same data from the same client to the problem server, it arrives
with the HTML encoding. And, in fact, the sending program has been
distributed to several customers who use it with the same results,
uploads to a test server arrive well formed, to the problem server
they are HTML encoded. And it's the fact that both servers are
running the exact same code that receives the upload that made me
wonder if it could be a Tomcat setting that was causing the problem.
2008/11/27 André Warnier <[EMAIL PROTECTED]>:
> Chris Mannion wrote:
>>
>> Hi All
>>
>> I've recently started having a problem with one of the servlets I'm
>> running on a Tomcat 5.5 system. The code of the servlet hasn't
>> changed at all so I'm wondering if there are any Tomcat settings that
>> could affect this kind of thing or if anyone has come across a similar
>> problem before.
>>
>> The servlet in question accepts XML data that is posted to it as a URL
>> parameter called 'xml'. The code to retrieve the XML as a String
>> (which is then used to build a document object) is simply -
>>
>> String xmlMessage = req.getParameter("xml");
>>
>> - where req is the HttpServletRequest object. Until recently this has
>> worked fine with the XML being received properly formatted -
>>
>>
>>...
>> etc.
>>
>> However, recently something has changed and the XML is now being
>> retrieved from the request object with escape characters in, so the
>> above has become -
>> <xml version="1.0" encoding="UTF-8"?>
>> <records>
>><record>
>>
>> Before sending the XML is encoded using the java.net.URLEncoder object
>> and the UTF-8 character set, but using a java.net.URLDecoder on
>> receiving it does not get rid of the encoded characters. I did some
>> reading about a possible Tomcat 6.0 bug and so tried explicitly
>> setting the character encoding (req.setCharacterEncoder("UTF-8"))
>> before retrieving the parameter but that had no effect either and even
>> if there's something that could explicitly decode the < > etc. I
>> couldn't use it as the XML data often contains characters like &
>> which have to remain encoded to keep the XML valid.
>>
>> As I said, this problem started without the servlet code having
>> changed at all so is there any Tomcat setting that could be
>> responsible for this?
>>
> Just a couple of indirect comments on the above.
>
> In your post, you seem to indicate that you also control the client which
> sends the request to Tomcat.
> If so, and for that kind of data, might it not be better to send the data in
> the body of a request, instead of in the URL ?
> That is probably not the bottom reason of the issue you describe above, but
> it may avoid similar questions of encoding in the future.
> (check the HTTP POST method, and enctype=multipart/form-data)
> It will also avoid the case where your data gets so long that the request
> URLs (and thus your data) get cut off at a certain length.
>
> Next, the way you indicate that the data is now received, shows an "html
> style" encoding, rather than a "URL style" encoding.
> If the data was now URL-encoded, it would not have (for example) """
> replacing a quotation mark, but it would have some %xy sequence instead
> (where xy is the iso-8859-1 codepoint of the character, expressed in
> hexdecimal digits).
> What I mean is that it is very unlikely that this encoding just happens
> "automatically" due to some protocol layer at the browser or HTTP server
> level. There must be something that explicitly encodes your original
> request data in this way, before it even gets put in a URL.
>
> I guess what I am trying to say, is that maybe you are looking in the wrong
> place for your problem, by focusing on the receiving Tomcat side first. I
> believe you should first have a good look at the sending side.
>
>
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Chris Mannion
iCasework and LocalAlert implementation team
0208 144 4416
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Odd encoding of servlet parameters
Hi All
I've recently started having a problem with one of the servlets I'm
running on a Tomcat 5.5 system. The code of the servlet hasn't
changed at all so I'm wondering if there are any Tomcat settings that
could affect this kind of thing or if anyone has come across a similar
problem before.
The servlet in question accepts XML data that is posted to it as a URL
parameter called 'xml'. The code to retrieve the XML as a String
(which is then used to build a document object) is simply -
String xmlMessage = req.getParameter("xml");
- where req is the HttpServletRequest object. Until recently this has
worked fine with the XML being received properly formatted -
...
etc.
However, recently something has changed and the XML is now being
retrieved from the request object with escape characters in, so the
above has become -
<xml version="1.0" encoding="UTF-8"?>
<records>
<record>
Before sending the XML is encoded using the java.net.URLEncoder object
and the UTF-8 character set, but using a java.net.URLDecoder on
receiving it does not get rid of the encoded characters. I did some
reading about a possible Tomcat 6.0 bug and so tried explicitly
setting the character encoding (req.setCharacterEncoder("UTF-8"))
before retrieving the parameter but that had no effect either and even
if there's something that could explicitly decode the < > etc. I
couldn't use it as the XML data often contains characters like &
which have to remain encoded to keep the XML valid.
As I said, this problem started without the servlet code having
changed at all so is there any Tomcat setting that could be
responsible for this?
--
Chris Mannion
iCasework and LocalAlert implementation team
0208 144 4416
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Underlying implementations of SOAPBody, SOAPElement etc.
Hi All I'm not sure this is exactly the place to be asking but I can't think of anywhere else so here goes. I have the same piece of code running on two different Tomcat installations, one Tomcat 5.0, the other Tomcat 5.5. The code calls and web service and produces a javax.xml.soap.SOAPMessage in response. Having noticed a slight difference in behaviour I debugged and found that on the Tomcat 5.0 system the underlying implementations of the javax.xml.soap interfaces (SOAPBody, SOAPElement etc.) were Axis classes such as org.apache.axis.message.SOAPBody. On the Tomcat 5.5 system the underlying implementations are all from a com.sun.xml.internal.messaging.saaj.soap.impl package. My question is what would be causing this difference, I thought perhaps libraries in Tomcat but have tried replacing all my libraries on Tomcat 5.0(including common, endorsed and those in the webapp) with those from Tomcat 5.5 but that didn't make any difference. Has anyone got any more ideas? -- Chris Mannion iCasework and LocalAlert implementation team 0208 144 4416
