Bug 972756 - GET operation history right after scheduling operation returns 404 if client is too fast
GET operation history right after scheduling operation returns 404 if client ...
Product: RHQ Project
Classification: Other
Component: REST (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: RHQ 4.9
Assigned To: Heiko W. Rupp
Mike Foley
Depends On:
  Show dependency treegraph
Reported: 2013-06-10 10:20 EDT by Libor Zoubek
Modified: 2015-11-01 19:43 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-03-26 04:31:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch (16.08 KB, patch)
2013-08-14 11:30 EDT, Heiko W. Rupp
no flags Details | Diff

  None (edit)
Description Libor Zoubek 2013-06-10 10:20:32 EDT
Description of problem: I have automation wich schedules operation via REST API and right after that, it starts polling it's status (this way I implement waiting for it to finish). Sometimes server returns 404 instead of operation history.

Version-Release number of selected component (if applicable):
Version: 4.8.0-SNAPSHOT
Build Number: bf44b14

How reproducible:sometimes

Steps to Reproduce:
1. schedule an operation via rest by setting readyToSubmit to true
2. read operation history url from response body
3. try retrieving history

Actual results: if fails with 404

Expected results: server always returns history object, right after operation was scheduled. REST API must make sure, that operation history exists, when it returns from scheduling request. 

Additional info:
Comment 3 Heiko W. Rupp 2013-07-26 05:00:26 EDT
The underlying issue seems to be that the history item is not created by the 
org.rhq.enterprise.server.operation.OperationManagerBean#scheduleResourceOperation method but from the Quartz-triggered org.rhq.enterprise.server.operation.ResourceOperationJob#execute

method, which leaves a time gap in between that you are running into with the fast calls. 
We never had issues on the UI, as humans are just slow enough.

We can work around that limitation inside the REST-api, but should probably just create the history item with state "in progress" directly at job creation time. The quartz job can then update it at will.
Comment 4 Heiko W. Rupp 2013-08-14 11:30:18 EDT
Created attachment 786576 [details]
Proposed patch
Comment 5 Heiko W. Rupp 2013-08-14 11:30:59 EDT
Mazz, could you please review that proposed patch?
Comment 6 John Mazzitelli 2013-08-16 13:28:31 EDT
(In reply to Heiko W. Rupp from comment #5)
> Mazz, could you please review that proposed patch?

The only question I have is the following:

355    public void setStartedTime(long startedTime) {
356        if (this.startedTime != 0) {
357           throw new IllegalArgumentException("Can only start an operation once");
358        }
359        this.startedTime = startedTime;

Is this throwing an exception here purposefully to abort what the OperationManagerBean was doing? I was wondering if you shouldn't just let the operation manager continuing doing what its doing - just don't set the started time and leave it as-is. However, I think you may have done this on purpose because you really don't want the history item touched when this happens so you really do want to abort (??)

Other than that question, it looks OK to me, especially if you can confirm that all unit tests and itests pass with this change.
Comment 7 Heiko W. Rupp 2013-08-16 15:37:12 EDT
Throwing the exception is following the setStartedTime() method, which does that as well.

I basically need to set the started time once the Quartz job has started working and is calling into OperationManager.updateHistory, which is why I need the method with parameter.
Comment 8 Heiko W. Rupp 2013-08-23 07:44:03 EDT
master 1cd277b34e9
Comment 9 Heiko W. Rupp 2014-03-26 04:31:31 EDT
Bulk closing now that 4.10 is out.

If you think an issue is not resolved, please open a new BZ and link to the existing one.

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