You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Serdyn du Toit <du...@gmail.com> on 2012/03/23 16:26:07 UTC
partial response from non-browser clients
Hi,
Using Tomcat 6.0.35 I got the server up and running and could retrieve
webpages from my application perfectly - using the browser. Now I've
written some client code of my own in Java and for one or other reason it
doesn't want to retrieve everything - it only returns a partial response
and then hangs. Multiple attempts at returning the webpage returns the
same partial response - in other words its still a partial response but its
the exact same length as the partial responses returned by the other
attempts.
I had the same issue in Jetty so I'm not sure what it could be, but maybe
there is some setting on my machine (Windows Vista) that's preventing any
non-browser connection with the webservers to work 100%?
The client code was first in Jersey (jersey.java.net), then written in
plain Java, and then using Apache HttpComponents (hc.apache.org). All
versions of client code hanged. The Java code (though its 100%) is as
follows:
String jsonResponse = "";
{
//
http://docs.oracle.com/javase/tutorial/networking/urls/readingWriting.html
URLConnection urlConnection = new URL(uri).openConnection();
BufferedReader br = new BufferedReader(new
InputStreamReader(urlConnection.getInputStream()));
String inputLine = null;
while ((inputLine = br.readLine()) != null)
jsonResponse += inputLine;
br.close();
}
One clue - when I changed the connector's socketBuffer (
http://tomcat.apache.org/tomcat-5.5-doc/config/http.html) the length of the
partial response varied. But it still didn't return the full response.
And the default setting worked for the browser...so no idea what could be
wrong...
Probably not a Tomcat issue - but any suggestions on what could be causing
this would be appreciated.
Kind regards,
Serdyn du Toit
Re: partial response from non-browser clients
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/3/23 Serdyn du Toit <du...@gmail.com>:
> Hi,
>
> Using Tomcat 6.0.35 I got the server up and running and could retrieve
> webpages from my application perfectly - using the browser. Now I've
> written some client code of my own in Java and for one or other reason it
> doesn't want to retrieve everything - it only returns a partial response
> and then hangs. Multiple attempts at returning the webpage returns the
> same partial response - in other words its still a partial response but its
> the exact same length as the partial responses returned by the other
> attempts.
>
> I had the same issue in Jetty so I'm not sure what it could be, but maybe
> there is some setting on my machine (Windows Vista) that's preventing any
> non-browser connection with the webservers to work 100%?
>
> The client code was first in Jersey (jersey.java.net), then written in
> plain Java, and then using Apache HttpComponents (hc.apache.org). All
> versions of client code hanged.
Take a thread dump to see where you code spends its time when you
think it is hanging. Is is better to take several (3) dumps with some
time interval.
See FAQ
http://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics
-> "How To: Capture a thread dump"
> The Java code (though its 100%) is as
> follows:
>
> String jsonResponse = "";
> {
> //
> http://docs.oracle.com/javase/tutorial/networking/urls/readingWriting.html
> URLConnection urlConnection = new URL(uri).openConnection();
> BufferedReader br = new BufferedReader(new
> InputStreamReader(urlConnection.getInputStream()));
Using InputStreamReader(stream) constructor is wrong in 90% of cases.
You should always pass an encoding as the second argument.
For JSON it is usually "UTF-8".
> String inputLine = null;
> while ((inputLine = br.readLine()) != null)
> jsonResponse += inputLine;
The above is a wrong way to concatenate strings. Do not do it in a
loop. Use a StringBuilder.
If you just need the text (not the lines), I would recommend to use
reader.read(char[])
> br.close();
> }
>
> One clue - when I changed the connector's socketBuffer (
> http://tomcat.apache.org/tomcat-5.5-doc/config/http.html) the length of the
> partial response varied. But it still didn't return the full response.
> And the default setting worked for the browser...so no idea what could be
> wrong...
>
> Probably not a Tomcat issue - but any suggestions on what could be causing
> this would be appreciated.
>
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: partial response from non-browser clients
Posted by André Warnier <aw...@ice-sa.com>.
Serdyn du Toit wrote:
> Hi,
>
> Using Tomcat 6.0.35 I got the server up and running and could retrieve
> webpages from my application perfectly - using the browser. Now I've
> written some client code of my own in Java and for one or other reason it
> doesn't want to retrieve everything - it only returns a partial response
> and then hangs. Multiple attempts at returning the webpage returns the
> same partial response - in other words its still a partial response but its
> the exact same length as the partial responses returned by the other
> attempts.
>
[...]
That sounds a bit like the webserver sending a "chunked" response, but the client not
being able to deal with it and thinking it gets the whole response the first time.
(I say "sounds like", because I really don't know if the Java code you're using can deal
with this or not).
Maybe you would benefit from having a look at the Apache HttpClient classes at
http://hc.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: partial response from non-browser clients
Posted by Rob Koberg <ro...@gmail.com>.
Hi,
I bet this issue has to do with the client not sending the proper
Accepts header info and the rest resource does not see it as
appropriate. Apparently jQuery is not doing the 'right thing'. I
recently had this issue. My working example of a jQuery function for a
conditional get looks like:
conditionalGet: function(contentType, path, options, success) {
var accepts = {}
, headers = {};
switch(contentType) {
case "html":
accepts.html = "text/html";
headers["Accept"] = "text/html; charset=utf-8";
headers["Content-Type"] = "text/html; charset=utf-8";
break;
case "xml":
accepts.xml = "application/xml";
accepts.text = "text/xml";
headers["Accept"] = "application/xml; charset=utf-8";
headers["Content-Type"] = "application/xml; charset=utf-8";
break;
case "json":
accepts.json = "application/json";
accepts.text = "text/plain";
headers["Accept"] = "application/xhtml+xml; charset=utf-8";
headers["Content-Type"] = "application/xhtml+xml; charset=utf-8";
break;
}
var ajaxOptions = {
accepts: accepts
, headers: headers
, cache: true
, dataType: 'xml'
, error: function(jqXHR, textStatus, errorThrown) {
console.error('jqXHR: ', jqXHR);
console.error('textStatus: ', textStatus);
console.error('errorThrown: ', errorThrown);
}
, ifModified: true
, statusCode: {
404: function() {
alert('The requested file was not found at: \n\n' + path);
}
,304: function() {
//console.log('Getting from cache...');
success(_cache[path]);
}
}
, success: function(data, textStatus, jqXHR) {
if (data !== undefined) {
_cache[path] = data;
success(data);
}
}
, url: path
};
$.extend(true, ajaxOptions, options);
$.ajax(ajaxOptions);
}
On Mon, Mar 26, 2012 at 10:00 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Serdyn,
>
> On 3/23/12 11:26 AM, Serdyn du Toit wrote:
>> The client code was first in Jersey (jersey.java.net), then written
>> in plain Java, and then using Apache HttpComponents
>> (hc.apache.org). All versions of client code hanged.
>
> Could you try using this little utility I wrote?
>
> http://www.christopherschultz.net/projects/java/URLFetch.java
>
> Let me know if that works. If it fails, please send me a thread dump
> of the hung process and a wireshark dump of the HTTP conversation.
>
> Thanks,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk9woLwACgkQ9CaO5/Lv0PDA8QCeNTcwtbt3pIODkAWcfNKL69jl
> 5hMAn1nBooVh7gepdGVsuioqP39OqPMt
> =uq8o
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: partial response from non-browser clients
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Serdyn,
On 3/23/12 11:26 AM, Serdyn du Toit wrote:
> The client code was first in Jersey (jersey.java.net), then written
> in plain Java, and then using Apache HttpComponents
> (hc.apache.org). All versions of client code hanged.
Could you try using this little utility I wrote?
http://www.christopherschultz.net/projects/java/URLFetch.java
Let me know if that works. If it fails, please send me a thread dump
of the hung process and a wireshark dump of the HTTP conversation.
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9woLwACgkQ9CaO5/Lv0PDA8QCeNTcwtbt3pIODkAWcfNKL69jl
5hMAn1nBooVh7gepdGVsuioqP39OqPMt
=uq8o
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: partial response from non-browser clients
Posted by Pid * <pi...@pidster.com>.
On 23 Mar 2012, at 15:26, Serdyn du Toit <du...@gmail.com> wrote:
> Hi,
>
> Using Tomcat 6.0.35 I got the server up and running and could retrieve
> webpages from my application perfectly - using the browser. Now I've
> written some client code of my own in Java and for one or other reason it
> doesn't want to retrieve everything - it only returns a partial response
> and then hangs. Multiple attempts at returning the webpage returns the
> same partial response - in other words its still a partial response but its
> the exact same length as the partial responses returned by the other
> attempts.
>
> I had the same issue in Jetty so I'm not sure what it could be, but maybe
> there is some setting on my machine (Windows Vista) that's preventing any
> non-browser connection with the webservers to work 100%?
>
> The client code was first in Jersey (jersey.java.net), then written in
> plain Java, and then using Apache HttpComponents (hc.apache.org). All
> versions of client code hanged. The Java code (though its 100%) is as
> follows:
>
> String jsonResponse = "";
Why do you open a block below, is there some code missing?
> {
> //
> http://docs.oracle.com/javase/tutorial/networking/urls/readingWriting.html
> URLConnection urlConnection = new URL(uri).openConnection();
Where does 'uri' come from?
> BufferedReader br = new BufferedReader(new
> InputStreamReader(urlConnection.getInputStream()));
> String inputLine = null;
> while ((inputLine = br.readLine()) != null)
> jsonResponse += inputLine;
> br.close();
> }
I can't see any Tomcat related code here. How are you interacting with
the container?
p
> One clue - when I changed the connector's socketBuffer (
> http://tomcat.apache.org/tomcat-5.5-doc/config/http.html) the length of the
> partial response varied. But it still didn't return the full response.
> And the default setting worked for the browser...so no idea what could be
> wrong...
>
> Probably not a Tomcat issue - but any suggestions on what could be causing
> this would be appreciated.
>
> Kind regards,
> Serdyn du Toit
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org