RoundtripTimeout Policy doesn't work correctly.
When the orb is not able to create a socket connection the setting of the
RoundtripTimeout has no effect. So it happens, that RoundtripTimeout is
exceeded, because the socket-creation timeout and the jacORB.retries can lead
to longer times than one would expect by setting RoundtripTimeout - and than
an SocketException is raised! RoundtripTimeout should allways be the dominant
setting in my opinion.
We found a workaround: by implementing our own socket_factory and setting the
property jacorb.net.socket_factory on it. There we use the
java.net.Socket.connect(address, timeout). As long the timeout we set there is
smaller than the RoundtripTimeout this works. But there is no coupling between
the settings - if the (sockettimeout times the jacORB.retries) is higher than
the RoundtripTimeout we still have the mess.
I dont know how other orb s can handle that problem.
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.
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
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
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
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
I also tried to support a solution as there patch.
Sorry for the mixup maybe caused by the reporting of the same item twice.
*** This bug has been marked as a duplicate of 787 ***