Read only archive ; use for new issues
Bug 549 - RoundtripTimeout Policy doesn't work - socketTimeOuts exceed
Summary: RoundtripTimeout Policy doesn't work - socketTimeOuts exceed
Status: RESOLVED DUPLICATE of bug 787
Alias: None
Product: JacORB
Classification: Unclassified
Component: ORB (show other bugs)
Version: 2.2.1
Hardware: All All
: P2 normal
Assignee: André Spiegel
Depends on:
Reported: 2004-12-22 15:28 CET by rolf gall
Modified: 2007-11-13 11:51 CET (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description rolf gall 2004-12-22 15:28:40 CET
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 on it. There we use the, 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.
Comment 1 André Spiegel 2005-01-03 08:17:37 CET
I will respond to your message in the jacorb-developer mailing list about this.
Comment 2 André Spiegel 2005-01-28 16:34:39 CET
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
Comment 3 Peter.Nikol 2007-06-14 16:28:48 CEST
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
Comment 4 Richard Ridgway 2007-11-12 22:40:57 CET
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.
Comment 5 Peter.Nikol 2007-11-13 11:40:57 CET
Please see also <a href="
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.

Comment 6 Richard Ridgway 2007-11-13 11:51:38 CET

*** This bug has been marked as a duplicate of 787 ***