Now new infrastructure, so this is definitely triggered by upgrading jetty. However, the actual issue might be caused by new behaviour in jetty triggering a bug in big ip.
Stefan 2014-01-28 "" <[email protected]> > Stefan, > > You said this was an 8.x to 9.x upgrade, so if the F5 was existing, it > shouldn't be an issue unless there are infrastructure changes at the same > time for upgrade. We use F5 and the only time we have seen something > similar was where a perimeter f/w was dropping an established connection > (due to inactivity) within the keep alive time. When the f/w does that > the browser does not know the connection it has is stuffed. > > tcpdump is the best approach. > > > > > On 28 January 2014 08:45, Stefan Magnus Landrø <[email protected]>wrote: > >> Thanks, Simone! I'm afraid I have to agree with you - this probably won't >> fix my issue. I'll do some tcpdumping in the next few days - I'll keep you >> posted. This might as well turn out being a f5 big ip issue. >> >> Stefan >> >> >> 2014-01-27 Simone Bordet <[email protected]> >> >> Hi, >>> >>> On Fri, Jan 24, 2014 at 9:36 PM, "" <[email protected]> wrote: >>> > Good find and a _critical_ bug in my view. >>> > >>> > A change that came with 9.0 as it was this in 8.x :- >>> > >>> > _header.put(CONNECTION_KEEP_ALIVE); >>> > if (connection!=null) >>> > { >>> > _header.setPutIndex(_header.putIndex()-2); >>> > _header.put((byte)','); >>> > _header.put(connection.toString().getBytes()); >>> > _header.put(CRLF); >>> > } >>> > >>> > which had less logic, shorter lines... Yes, it copied 2 more bytes >>> than it >>> > needed to but I would prefer less logic/shorter code over saving 2 >>> bytes. >>> > >>> > To fix this, you could _try_ turning off one connect on the f5 if you >>> don't >>> > need it for other reasons. >>> > >>> > We are also behind an F5, and are just about to start looking at >>> moving from >>> > 8.x to 9.x. ... so thanks ... will raise on support. >>> >>> I filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=426739 and fixed >>> it. >>> >>> Note that this is a corner case that should happen very rarely, only >>> when the "Connection" header gets some custom value that is not >>> "close" or "upgrade" or "keep-alive". >>> >>> Therefore, I am dubious that the original problem (curl hanging for >>> chunked responses) is fixed by this fix. >>> >>> Let us know if that is the case, though. >>> >>> -- >>> Simone Bordet >>> ---- >>> http://cometd.org >>> http://webtide.com >>> http://intalio.com >>> Developer advice, training, services and support >>> from the Jetty & CometD experts. >>> Intalio, the modern way to build business applications. >>> _______________________________________________ >>> jetty-users mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>> >> >> >> >> -- >> BEKK Open >> http://open.bekk.no >> >> TesTcl - a unit test framework for iRules >> http://testcl.com >> >> _______________________________________________ >> 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 > >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
