Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Jetty 7.4.2 to 7.6.1 upgrade: Losing final packets in large responses

Clients:

Internet Explorer 8, Google Chrome 17.0.963, Silverlight 4.0 in ClientHttp mode

Rough content information:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Length: 30636
Content-Type: text/plain; charset=UTF-8

In this case, data received before stopping was around 16421. (looking
only at body)

HTTP/1.1 200 OK
Accept-Ranges: bytes
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Length: 191395
Content-Type: text/plain; charset=UTF-8

In this case, rough data received before stopping was around 183019.
(looking only at body)

The response is raw XML data. It is not compressed in any way.

It is a single REST style HTTP/1.1 GET call, though a favicon download
occurs following making this call through internet explorer or chrome
and Silverlight performs a preceding download of XML files for client
access policy and cross domain policy.

Multiple tests were performed between different sets of machines, with
connections between the two including:
22/5 Cable connection (with VPN overhead)
12/3 Cable connection (with VPN overhead)
Loopback (performed GET from the same server hosting the running Jetty)

Tomorrow I will have the chance to perform some tests over a 10/100
LAN in place of the VPN.

On Thu, Feb 23, 2012 at 23:02, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
> 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
> joakim@xxxxxxxxxxx
>
> http://webtide.com | http://intalio.com
> (the people behind jetty and cometd)
>
>
>
> On Thu, Feb 23, 2012 at 8:02 PM, Michael Henderson <dillius@xxxxxxxxx>
> 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
>> jetty-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
>
>
> _______________________________________________
> jetty-users mailing list
> jetty-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>


Back to the top