« Return to Thread: More fixes and testing results.

Re: More fixes and testing results.

by Suresh Sundriyal-2 :: Rate this Message:

Reply to Author | View in Thread

Hi Klaus,

I'm glad you did not check this particular change in (enum-expires.diff), yet. :-)
It does fix the problem where enumerations with explicit expiretime are
deleted immediately but it breaks normal enumerations.

Looking at the code it seems like the way Openwsman handles time is
messed up. According to the comment in __WsEnumerateInfo the expires
is expected to be in milliseconds since epoch time. However, the method
wsman_set_expiretime() sets it in seconds and time_expired() also checks
for this time in seconds. However, with normal enumeration requests with
no explicit expire time, the timestamp is set to milliseconds and in
wsman_get_expired_enuminfos, the timestamp as well as the expires field
in the enuminfos are checked against mytime which is in milliseconds. Which
is why if I fix one check the other breaks.

There are two ways to solve this problem, one is I convert all the methods
that set/serialize/deserialize expiretime to set the time in milliseconds, this
is pervasive since lots more code to fix. However, looking at the comment
in the __WsEnumerateInfo enum, it would be according to the original
design. I think I already have a changeset for this which I will be testing
tomorrow.

The other way would be to just change the code where enum timestamp is
set to use seconds instead of milliseconds. This should be pretty easy to do,
I think since I see only one place where the timestamp is set. However, I
haven't explored this one as well as the solution I described above

Let me know which solution you prefer?

--
Suresh
 
________________________________________
From: Suresh Sundriyal [ssundriy@...]
Sent: Wednesday, September 16, 2009 4:37 PM
To: Klaus Kaempf; openwsman-devel@...
Subject: Re: [Openwsman-devel] More fixes and testing results.

Suresh Sundriyal wrote:

> Enumeration with expire time:
> =============================
>
> This could just be a problem at my end, since I've been playing around
> with the code so much that my local client is completely messed up at
> the moment (I tend to work off of 2.1.0 code and then patching it with
> the changes) but it seems like if I send an enumeration request with an
> expire time, the server does not honor the expire time and immidiately
> deletes the results. If anyone could chime in and confirm whether this
> is a problem or not before I start investigating this, it would be
> appreciated.
>


I'm sending along a patch for the problem above. It seems that when we
calculate the timestamp for the enumeration results in
wsman_set_expiretime (wsman-soap-envelope.c), we set it to:

*expire = tv.tv_sec + timeout;

This is basically (epoch seconds + offset).

When we check to see whether the enumeration has expired or not in
wsman_get_expired_enuminfos (wsman-soap.c), we test it against:

mytime = tv.tv_sec * 1000 + tv.tv_usec / 1000;

This is epoch seconds converted to microseconds + epoch microseconds
converted to seconds(?!!). This pretty much always ensures that mytime
will always be greater than expire_time. Thus the enumeration results
expire as soon as they are created.

To fix this, I changed mytime to :

mytime = tv.tv_sec

This seems to work fine. I could not correct the code in
wsman_get_expired_enuminfos, since that code is also used by
subscription_expiration and changing the code there makes subscriptions
act weird.

Tested the code with enumeration intrinsic with expiration time (PT45S,
did not get a chance to test it with datetime format but even that code
seems to convert everything to sec, so I think it should be OK). Also
tested the subscriptions to make sure they were working correctly.

--
Suresh

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Openwsman-devel mailing list
Openwsman-devel@...
https://lists.sourceforge.net/lists/listinfo/openwsman-devel

 « Return to Thread: More fixes and testing results.