Description of problem: There are multiple API calls, which returns ConfigRevision objects. In some use case, user should get the very same object from different API call. For instance, when user creates multiple file revisions of a given file by API call configchannel.createOrUpdatePath. The exactly same revisions should be returned by configchannel.getFileRevisions API call. The problem is that they might differ in the 'modified' item. Revisions returned by configchannel.createOrUpdatePath API call might have 'modified' time of 1 second earlier ... compared to configchannel.getFileRevisions. Version-Release number of selected component (if applicable): Spacewalk 1.5 Spacewalk nightly How reproducible: not deterministic, but easily reproducible Steps to Reproduce: 1. Call configchannel.createOrUpdatePath for a given file with some arbitrary values. 2. save a return value (struct - Configuration Revision information) 3. repeat a few times 4. Compare these saved values with configchannel.getFileRevisions API call Actual results: Revisions sometimes differs in 'modified' item. Expected results: Revisions are equal. Additional info:
Investigation: The problem is that spacewalk-java sets the 'modified' field during a construction of ConfigurationRevision object, returns it to the user, and attempts to store it in the database. Unfortunately, in the database, there is a trigger which overrides 'modified' field on insert.
Hey Simon, now I'm not sure, what version you have the trouble with. The reason is, we've fixed Bug 593300, that shall not create another file revision, if the new one doesn't differ from the previous one. At the time, you've reported the bug was the 593300 already fixed. Is it possible that your problem was fixed with 593300 fix?
I believe that this problem was not addressed by fix for bug 593300.
(In reply to comment #3) > Hey Simon, > > now I'm not sure, what version you have the trouble with. > > The reason is, we've fixed Bug 593300, that shall not create another file > revision, if the new one doesn't differ from the previous one. At the time, > you've reported the bug was the 593300 already fixed. > > Is it possible that your problem was fixed with 593300 fix? From Šimon's description it looks like you create one timestamp in the Java stack and return that when creating the revision. But in the database (and thus returned by subsequent calls that properly retrieve the object from the database), the value is set by the trigger, and depending on the load on the Spacewalk machine, you have nonzero chance that the trigger will fire after the second "ticks". Any chance of not setting the modified value in Java at all? Are the other API calls that use the same workflow and could have the same problem?
Tomáš, ping?
pong fixed spacewalk.git: 9f312438c263899b64fc218e0ae707f5a46f21f1 howg
This issue is resolved with the release of RHN Satellite 5.5. As of September 20th 2012, RHN Satellite 5.5 has been generally available. Release Notes and other 5.5 documentation can be found here: https://access.redhat.com/knowledge/docs/Red_Hat_Network_Satellite/ The associated Errata for the 5.5 release are: 5.5 Satellite GA Errata - http://rhn.redhat.com/errata/RHEA-2012-1296.html 5.5 Upgrade Errata - http://rhn.redhat.com/errata/RHEA-2012-1298.html 5.5 RHN Proxy GA Errata - http://rhn.redhat.com/errata/RHEA-2012-1297.html 5.5 RHN Tools GA Errata - http://rhn.redhat.com/errata/RHEA-2012-1299.html Regards, Clifford - Engineering Manager, Satellite