Hi,
I've noticed some weird performance problems using jersey-client 1.8. The
server is running Jersey and the client using Jersey-client. When the client
invokes:
WebResource resource = client.resource(someUri);
resource.accept(DevicesEntity.JSON_TYPE_V1).get(DevicesEntity.GetDevices.class);
I see a 500ms delay between the time the client invokes the method and the
time the server method begins running. Upon adding trace logs to the server
code I observed the following:
2011-08-22 14:50:08.654,TRACE,ConnectionFilter.doFilter,qtp13211767-17 start
HTTP/1.1 GET
http://localhost/devices
2011-08-22 14:50:08.656,TRACE,ConnectionFilter.doFilter,qtp13211767-17 end
HTTP/1.1 GET
http://localhost/devices
2011-08-22 14:50:09.166,TRACE,ConnectionFilter.doFilter,qtp13211767-18 start
HTTP/1.1 GET
http://localhost/devices/
Seeing as this ServletFilter is suffiently low-level I assume that the delay
is coming from the client side. Notice that a redirect is taking over 500ms.
Weird.
Upon stepping through the client code I discovered that
URLConnectionClientHandler line 240 invokes:
return new URLConnectionResponse(
uc.getResponseCode(),
getInBoundHeaders(uc),
getInputStream(uc),
ro.getMethod(),
uc);
where "uc" is an instance of HttpURLConnection. uc.getResponseCode() invokes
HttpURLConnection.getInputStream() which seems to handle redirects under the
hood. It seems Oracle does not ship the source-code to getInputStream() with
the JDK so I can't step into it.
Does anyone have any idea on what's going on? 500ms seems extremely slow for
something as simple as URL redirects, especially when all communication is
taking place on localhost.
Gili
--
View this message in context: http://jersey.576304.n2.nabble.com/Slow-redirects-using-HttpUrlConnection-tp6712832p6712832.html
Sent from the Jersey mailing list archive at Nabble.com.