Can you tell us a bit about the conditions of this? We'd like to setup a unit test to attempt to replicate it.
What kind of client? What is the size of the content? Is the response gzip'd? Is this large content part of a HTTP/1.1 pipeline request chain? What speed is the network connection? (such as wired 1gbit / wifi g / 4g / 3g / edge / 14.4k modem, etc...) -- Joakim Erdfelt [email protected] http://webtide.com | http://intalio.com (the people behind jetty and cometd) On Thu, Feb 23, 2012 at 8:02 PM, Michael Henderson <[email protected]>wrote: > I've been working on a REST solution that makes use of an embedded > Jetty instance (specifically Restlet). Currently, the framework's > built in extension for Jetty support only up to version 7.4.2 due to > some class name and package changes (HttpConnection -> > AbstractHttpConnection, the change of the preferred SslContextFactory > to being that in org.eclipse.jetty.util.ssl rather than > org.eclipse.jetty.http.ssl). > > Therefore, I have been looking to create a connector based off the > existing that I can keep up to date with newest Jetty versions. > > I encountered little trouble until I began wider testing, and found > that with either Jetty 7.6.1 or Jetty 8.1.1 in use, certain requests > whose responses were large enough to exceed a single packet/buffer > size, would fail to ever receive the final response packet. The > responses would be cut off at the same point each time in these larger > responses. (to the exact same byte each time) > > To further confuse this issue, the cut off would occur differently on > different machines, and for a few machines it would not occur > whatsoever. It does not appear to be browser or operating system > dependent (though they only ones I test with at this early stage are > IE8 and Google Chrome, and Windows 7 varieties). > > I am trying to determine what could have changed in the response > behavior of Jetty between versions 7.4 and 7.6 that could cause such a > failure. The connection appears to simply idle out rather than > providing the final packet needed. The behavior for the REST > application interacting with the Jetty instance has not changed > outside of the renaming mentioned above, so I expect there is > something new that needs to be done to properly provide a response. > > Any insight that could be provided would be appreciated, as my > knowledge of Jetty is quite limited. > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
