[omniORB] changing system clock

[Geoffrey Hanson]

That's great. Thanks! I'll try it out.

Are you saying that all the other callers of
get_time() do not have a problem when the system
clock is changed?

For example, if I have a client timer set to, say
30 seconds, and I change the time backwards, would
the client timer still time out after 30 seconds?

Thanks,
Geoff

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


> -----Original Message-----
> From: Duncan Grisby [mailto:duncan at grisby.org]
> Sent: Wednesday, May 17, 2006 5:58 AM
> To: Geoffrey Hanson
> Cc: omniorb-list at omniorb-support.com
> Subject: Re: [omniORB] changing system clock 
> 
> 
> On Tuesday 16 May, "Geoffrey Hanson" wrote:
> 
> > 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 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.
> 
> Yes. This is necessary for call timeouts specified as an absolute
> deadline, but it's not required in the SocketCollection Select. The
> simple solution is to check that the timeout in select is not longer
> than the select interval. I've checked in a fix to do that, 
> and attached
> a patch here.
> 
> Cheers,
> 
> Duncan.
> 
>