[omniORB] changing system clock

Geoffrey Hanson hanson at fabric7.com
Tue May 16 16:50:16 BST 2006


We're currently using omniORB version 4.01 and are interoperating
with Java Sun ORB.

We've encountered a problem where if you change the system clock
backwards, then all requests from a Java ORB client to a omniORB
server are serialized within a single thread.

I was wondering if anyone had encountered this before and knows
of a solution?

The Java ORB client only opens a single connection to the omniORB
server. Under normal conditions, if a second request is received
while the first is being processed, a new thread is created to
service the second request.

But in the case of changing the system clock backwards (when
server is running), new threads are no longer created in this
scenario.
 
I tracked down some code in:
orbcore/SocketCollection.cc::Select()
which seems to be the culprit.

When calculating a timeout value for the select() call,
it calls SocketSetTimeOut() to calculate the difference
between the current time and a pre-saved absolute
timestamp. It only resets the timestamp when this timeout
expires.

One suggested approach was to change the implementation of
get_time() for posix to return the time since boot up as
reported by the kernel, rather than gettimeofday(). All of
the callers of get_time() don't seem to really care about the
wall clock anyway, and using the time since boot up cannot be
changed by the user.

Comments?

Any suggestions are appreciated.

Thanks,
Geoff

---
Geoff Hanson         Fabric7 Systems
hanson at fabric7.com   1300 Crittenden Lane,       
650-210-0116              Suite 302
                     Mountain View, CA 94043



More information about the omniORB-list mailing list