| Summary: | Async of HttpClient does not work on Jetty 7.2.2 and 7.3.0? | ||
|---|---|---|---|
| Product: | [RT] Jetty | Reporter: | mickyp <mickyp100> |
| Component: | client | Assignee: | Greg Wilkins <gregw> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | gregw, jetty-inbox, mickyp100, simone.bordet |
| Version: | 7.3.0 | ||
| Target Milestone: | 7.2.x | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
mickyp
Simone, Did you/we change HttpClient connection to be blocking? If so, does that explain this difference? Greg, you changed the relevant code in revision 2189 with the comment "314087 Simplified SelectorManager", I think on the verge of the discussion we had about simplifying the handling of initial connection management in the selector. The main point of this trickery is that it is difficult to implement connect timeouts for channels in non blocking mode. The only way is to submit a scheduled task that expires and checks if the connection is established. Prior to your change I was submitting an instance of inner class SelectConnector.ConnectTimeout to a timer to implement connect timeouts. This class is still present in the current sources but now it's unused. Perhaps you can obtain the same effect by changing line 143 from: channel.connect(address.toSocketAddress()); to channel.socket().connect(address.toSocketAddress(), _httpClient.getConnectTimeout()); I do not think that the SO timeout is affecting the connect timeout, but only the read timeout, so the current code is ineffective (and explains why Socket.connect() takes a connect timeout parameter). If you have further insights, comment here, otherwise I am going to fix this using the 2-parameter connect() method as above. I think having the timeout will help somewhat, but it will not help with the scenario reported, where 4 connections to non existent hosts want to be attempted in parallel. I'll have a look a re-enabling an async connect - at least as an option. r2809 I readded the async connect mode, but it is now optional, so you need to do a httpclient.setAsyncConnect(true) It would be great if you could try this out from source or snapshot before we do a release. Greg, the blocking connect functionality was already present in SelectConnector but never used because SelectConnector is package private (so user code cannot cast to it and configure the blocking of the connects). I removed that code from SelectConnector since now you added the same functionality in HttpClient, and renamed from "asyncConnects" to "connectBlocking" like it was in SelectConnector, and updated the code accordingly. Excuse me, I want to know if there is a patch for it? Or I just need to checkout the source code from SVN and build it by myself? |