Bug 4741 - ServiceGroupRegistrationClient: getting the remote CurrentTime missed
: ServiceGroupRegistrationClient: getting the remote CurrentTime missed
Status: RESOLVED FIXED
: MDS4
wsrf_servicegroup
: 4.0.3
: All All
: P3 normal
: 4.0.4
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2006-10-03 10:04 by
Modified: 2007-02-20 20:24 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2006-10-03 10:04:32
I'm experiencing an issue with the renewal of registrations using Java WS Core
version 4.0.3 + the Aggregator Framework. It seems that the ServiceGroup client
is not able to get the remote time from my aggregator service. 
By logging at debug level the client, I obtain the following messages:

2006-09-30 12:55:09,110 DEBUG client.ServiceGroupRegistrationClient
[Timer-4,status:474] Attempting to get current time, preferring remote.
2006-09-30 12:36:09,110 DEBUG client.ServiceGroupRegistrationClient
[Timer-4,status:474] No remote current time available. Getting from local clock
instead.

and I understand that there is a problem while it is trying to get the remote
time.
Then, by studying the source code of the ServiceGroupRegistrationClient class,
I see the following piece of code:
_____________________________________________________

/** Gets the current time, preferably from the remote resource
           specified, and failing that from local system. */
       private Calendar getCurrentTimePreferringRemote(  EndpointReferenceType
epr)         {
           ServiceGroupRegistrationClient.this.status(LOG_D,     "Attempting to
get current time, preferring remote.");

           Calendar now = null;

           if(epr!=null && maybeHasLifetime) {

               try {
               GetResourceProperty getRPPort =   
rpLocator.getGetResourcePropertyPort(epr);
               setSecurity((Stub)getRPPort);

               GetResourcePropertyResponse resp =   
getRPPort.getResourceProperty(WSRFConstants.CURRENT_TIME);
               } catch(InvalidResourcePropertyQNameFaultType e) {
                   /* this fault means that we can talk to the
                      resource but it does not have current time,
                      which implies that it does not support
                      WS-ResourceLifetime mechanisms */
                   maybeHasLifetime=false;
                   /* now fall through */
               } catch(Exception e) {
                   /* some other exception occurred. return null, but
                   don't change maybeHasLifetime */
                   ;
               }
                          }

           // if the above hasn't produced a time, then pull time from
           // local clock
           if(now == null) {
               ServiceGroupRegistrationClient.this.status(LOG_D,
                   "No remote current time available. Getting from local clock
instead.");
               now = Calendar.getInstance();
           }

           return now;
       }
_____________________________________________________

In my opinion, there is a bug in this code, because it does not extract the
time from the "resp" object  and it never sets the "now" object in the try
block. Therefore, the local time is alway used.
Since the machines that join the infrastructure of the project I'm working in
are located in different timezones, this causes sometimes that the
ServiceGroupEntries created by the Agggregator Framework and connected to my
Sinks are always out of date at creation time. So, the sweeper of the
Aggregator Framework immediately deletes them at its next execution. In fact,
the next renewal attempt always creates a new ServiceGroupEntry because, of
course, it fails to acquire to the removed resource.
------- Comment #1 From 2006-10-03 14:37:39 -------
This bug has been fixed in all relevant CVS branches, but has not been released
as part of an official toolkit release yet. It will be included in the next
point release (4.0.4) but I personally don't know when that will be at this
time.  

In the meantime you can patch your installation with a overlay build of
ws-mds/servicegroup from the globus_4_0_branch, or use the offical GPT
patch/update package that will be released in the near future.

There is an early version of the GT4.0.3 MDS update patch available for testing
here:

http://www.isi.edu/~mdarcy/globus/gt4.0.3-wsmds-update-1.0-src_bundle.tar.gz
http://www.isi.edu/~mdarcy/globus/gt4.0.3-wsmds-update-1.0-src_bundle.tar.gz.md5

If you would like to test it and report back whether it fixes your issue, that
could help us with finalizing the patch.  

Also, if you do not wish to apply the entire update, you could extract the file
globus_wsrf_servicegroup-0.56.tar.gz from the archive file and run gpt-build
against that file only in order to fix this bug only.
------- Comment #2 From 2006-11-03 14:32:53 -------
A GPT update package containing the fix for this bug has been posted on the
advisories page at: http://www.globus.org/toolkit/advisories.html

The package can be downloaded from this link: 
http://www-unix.globus.org/ftppub/gt4/4.0/4.0.3/updates/src/globus_wsrf_servicegroup-0.56.tar.gz

Note that this fix will also still be included in the development patch
mentioned above, so if you apply the development patch to your 4.0.3
installation you do not need to apply the updated
globus_wsrf_servicegroup-0.56.tar.gz from the advisory page.
------- Comment #3 From 2007-02-20 20:24:44 -------
This bug has been fixed and will be included in the upcoming 4.0.4 release.