Bug 972756 - GET operation history right after scheduling operation returns 404 if client is too fast
Summary: GET operation history right after scheduling operation returns 404 if client ...
Alias: None
Product: RHQ Project
Classification: Other
Component: REST
Version: 4.8
Hardware: Unspecified
OS: Unspecified
unspecified vote
Target Milestone: ---
: RHQ 4.9
Assignee: Heiko W. Rupp
QA Contact: Mike Foley
Depends On:
TreeView+ depends on / blocked
Reported: 2013-06-10 14:20 UTC by Libor Zoubek
Modified: 2015-11-02 00:43 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-03-26 08:31:31 UTC

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

Description Libor Zoubek 2013-06-10 14:20:32 UTC
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 09:00:26 UTC
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 15:30:18 UTC
Created attachment 786576 [details]
Proposed patch

Comment 5 Heiko W. Rupp 2013-08-14 15:30:59 UTC
Mazz, could you please review that proposed patch?

Comment 6 John Mazzitelli 2013-08-16 17:28:31 UTC
(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 19:37:12 UTC
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 11:44:03 UTC
master 1cd277b34e9

Comment 9 Heiko W. Rupp 2014-03-26 08:31:31 UTC
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.