| Summary: | RoundtripTimeout Policy doesn't work - socketTimeOuts exceed | ||
|---|---|---|---|
| Product: | JacORB | Reporter: | rolf gall <rolfgall> |
| Component: | ORB | Assignee: | André Spiegel <spiegel> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | Peter.Nikol |
| Priority: | P2 | ||
| Version: | 2.2.1 | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
rolf gall
2004-12-22 15:28:40 UTC
I will respond to your message in the jacorb-developer mailing list about this. Below is my reply from jacorb-developer about this. Bottom line: I don't think this needs to be changed. Since there were no replies to this, I figure that people are happy with it. I've added a footnote in the QoS chapter of the Programming Guide about this issue. --snip-- I am not sure how to handle this. To begin with, the timeout for connection establishment can also be set with the standard socket factory, via the property jacorb.connection.client.connect_timeout. So with this property, and jacorb.retries, you have full control over the connection establishment timing. You don't need to implement your own socket factory to achieve this. Now, should the RoundtripTimeout take precedence over this setting? I tend to say no. Connection establishment can be a costly process, involving DNS lookups and the like. If you do get a connection to the target, but only after the RoundtripTimeout has elapsed, the client code gets a TIMEOUT exception anyway. But if you don't succeed to establish a connection at all, then the client gets a TRANSIENT exception (or another I/O related one). It will get this exception after jacorb.connection.client.connect_timeout was exceeded jacorb.retries times. I think it is correct to throw a different exception here, because this is not just a timing problem, but likely a general network error. If you want to make sure that you get this exception within the same time frame as your RoundtripTimeout specifies, you can set the connect_timeout and jacorb.retries accordingly. So, I believe there is no need for the ReplyEndTime to actually override the connection-establishment properties, but if anybody feels otherwise, please say so. Note also that it would be quite difficult to implement this, because the two timeouts are handled very differently in the JacORB souce code, so unless there's a very compelling reason to do so, I would rather not do this. (Of course it would be good to add a sentence about this in the documentation.) 1. We have to deal with two problems here not only one. First problem is already discussed. When the connection isn't established the used timeout is not what was set by the Roundtrip Timeout (RTT) but by the connection timeout * retrys (1s * 5 = 5s) from the jaco property file. Second problem is much more worse. If a number of let's say N clients are trying to send requests to the same server the request processing will queue up in the ClientIIOPConnection.connect (syncronized) method. Each client will have to wait until the previous clients timeout is reached and all retrys are tried (5s). Then it is not checked if the RTT is already timed out and so this client and all the followers also try to establish the connection one by one . This approach ends up with the last client (lets say of 30) waiting N * connection timout * retrys (30 * 5s = 150s). If the application is continously creating new requests with a cycle lower than 5s this will also end up in resource shortness. 2. As far as I know is the RTT defined to limit the requests lifecycle. I didn't find anything that the RTT will manage to inform the application exactly when the request times out. But isn't that exactly what the application programmer is expecting? Just to comment that I also see & suffer from this behaviour - unexpectedly long timeouts when creating new connections. Especially interesting in relation to bug 810. Please see also <a href="http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi? id=787">Bug 787</a> where I reported the summation of timeout's as a separate Bug. I also tried to support a solution as there patch. Sorry for the mixup maybe caused by the reporting of the same item twice. |