Bugzilla – Full Text Bug Listing
| Summary: | Ajp13Parser IOException | ||
|---|---|---|---|
| Product: | [RT] Jetty | Reporter: | David Seymore <david.seymore> |
| Component: | server | Assignee: | Greg Wilkins <gregw> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | CC: | janb, jetty-inbox |
| Version: | 8.1.0 | ||
| Target Milestone: | 7.5.x | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
I just switched over to http proxy instead of the ajp; this worked around the problem, so, crtical level of this has dropped me. FYI, we are planning on retiring support for ajp13 in jetty-9, as its well past its prime and unncecessary with mod_proxy. Also planning on retiring the blocking connectors which I note you're using. Here's the relevant excerpt from Greg's posting on jetty-dev list recently: - - - Remove the Blocking Connectors Jetty currently supports a full set of blocking and non-blocking connectors. This results in either duplicated code or code that has to be more complex/generic then it would if only a single mode was supported. Much of the difficulty with the recent refactoring of the IO layer was due to need to keep both blocking and nonblocking connectors working. While there are some traffic profiles that are faster with the blocking connectors, this is only a marginal improvement, which may well be recouped by the simplification of an async only IO layer. Features like continuations and websockets currently only work with the asynchronous connectors. Remove the modjk/AJP connector The mod_proxy_http module has long been our preferred connection type from apache, offering greater speed and reliability than AJP. There is no reason to keep the AJP connector. - - - Jan closing as workarounds exist and ajp support itself is being retired |
Build Identifier: jetty-8.1.0.v20120127 This appears to happen only when performing DWR/AJAX calls through an apache webserver proxying with AJP. Jetty Output: 2012-02-07 17:20:41.915:WARN:oejsb.SocketConnector:handle failed? java.io.IOException: FULL at org.eclipse.jetty.ajp.Ajp13Parser.fill(Ajp13Parser.java:197) at org.eclipse.jetty.ajp.Ajp13Parser.parseNext(Ajp13Parser.java:544) at org.eclipse.jetty.ajp.Ajp13Parser.parseAvailable(Ajp13Parser.java:158) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:722) Apache Error Log Output: [Mon Feb 06 19:23:57 2012] [error] (111)Connection refused: proxy: AJP: attempt to connect to 10.112.41.76:9090 (10.112.41.76) failed [Mon Feb 06 19:23:57 2012] [error] proxy: AJP: failed to make connection to backend: 10.112.41.76 Server version: Apache/2.2.20 (Ubuntu) Reproducible: Always Steps to Reproduce: I'd have to toss together a test application with similar behavior to reliably reproduce, all I can say is that we have a DWR call, that executes a POST command with a rather large amount of content, here is the request details: Request URL:https://obfuscated.com/obfuscated/secure/call/plaincall/obfuscated.obfuscated.dwr Request Method:POST Status Code:200 OK Request Headersview source Accept:*/* Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 Accept-Encoding:gzip,deflate,sdch Accept-Language:en-US,en;q=0.8 Connection:keep-alive Content-Length:40155 Content-Type:text/plain Cookie:SPRING_SECURITY_REMEMBER_ME_COOKIE=ZHNleW1vcmU6MTMyODg4NDU5NTAzNDozMTY0MDg1OWViMDkzMWNmZmY5ZmQwZDM0M2JmYzI0Yg; JSESSIONID=obfuscated11orohpyhhdtestvz5o8wnc36w.obfuscated1 Host:labs.i3analytics.com Origin:https://obfuscated.com Referer:https://obfuscated.com/obfuscated/secure/search User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7