[omniORB] Time patch for omniorb 2.8

[Sai-Lai Lo]

Fixed added to 2.8 and 3.0. 2.8 snapshot in the ftp server has been updated.
Changes to 3.0 will be propagated overnight.

Thanks for the reminder.

Sai-Lai

----- Original Message -----
From: <Peter.Ronnquist@nokia.com>
To: <Peter.Ronnquist@nokia.com>; <omniorb-list@uk.research.att.com>;
<omniorb@uk.research.att.com>
Sent: Monday, May 28, 2001 5:15 PM
Subject: RE: [omniORB] Time patch for omniorb 2.8




-----Original Message-----
From: ext Peter.Ronnquist@nokia.com [mailto:Peter.Ronnquist@nokia.com]
Sent: 21. May 2001 20:38
To: omniorb-list@uk.research.att.com; omniorb@uk.research.att.com
Subject: [omniORB] Time patch for omniorb 2.8



Hello,

We had problems with omniorb 2.8 when we changed the date to some date a
number of years into the future.
The result was that omniNames got stuck in a loop scanning for
<<scavenger.cc>>
connections. This is because the method omniORB_Scavanger::run_undetached
adds the ScanPeriod to the
absolut time in a loop until the system time is hit.

To verifiy this bug just run omniNames -ORBtraceLevel 15, do a date -s "1
jan 2001" and then a date -s "19 may 2001", omniNames
will then print out a lot of scanning connections. If I tried to start some
corba servers in this state then they could not connect
to the naming server.

Attached to this email is a fix for this problem (just to do a get_time
inside the loop and add the ScanPeriod to that instead).
So the only change is an addtition of:

omni_thread::get_time(&abs_sec, &abs_nsec);

in the end of omniORB_Scavanger::run_undetached(void*)

I don't know if this affects omniOrb 3 as well, but I would be happy if this
fix could go into omniOrb2.8.

----------------------------------
Hello again,

I just looked at the omniOrb3 source and it has the same error in its
scavanger.cc. So this fix is useful there as well.

Best Regards
Peter Rönnquist