Bug 534190 (RHQ-100)

Summary:	Operation history shows intermittend failue, but success later
Product:	[Other] RHQ Project	Reporter:	Heiko W. Rupp <hrupp>
Component:	Operations	Assignee:	RHQ Project Maintainer <rhq-maint>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	0.1	Keywords:	SubBug
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
URL:	http://jira.rhq-project.org/browse/RHQ-100
Whiteboard:
Fixed In Version:	1.3	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	536412

Description Heiko W. Rupp 2008-03-14 14:59:00 UTC

15:55:48 < pil> This is not consistent. The previous restart action took some time, but completed. This time it failed and I got an error: "Timed out : did not complete after 27017ms (the timeout period was [0] ms)"
15:56:02 < pil> Ah, now it is marked as success
15:56:08 < pil> even worse ..
15:58:05 < mazz> if a timeout occurs, but the plugin actuall succeeded, I believe the agent will come in and tell the server and the server will change that timeout to success
15:58:50 < mazz> because if the plugin really did complete successfully, even after a timeout occurred, we should indicate that (to let the user know it really did complete)
16:00:31 < ghinkle> if the op timesout
16:00:39 < ghinkle> there will be nothing to check if it succeeded

Comment 1 Joseph Marques 2008-09-08 05:13:24 UTC

heiko, i think this is working as intended.  there are certain rare circumstances under which the agent-side and server-side are not completely in sync.  if the user pressed "cancel" for some operation, the operation history will be marked as canceled and the cancel-request will make it down to the agent.  however, the agent-side operation has to be written in a way to respond to this request, because it if isn't the operation will proceed to some terminal state (success or failure), and that result will be sent up to the server and override the cancel request.  there is also a possibility that the cancel request went out but the agent-side operation has already completed (and the result is en route to the server).  in all of these cases, you might see the operation history flip-flop.  but, again, this is rare.  quite rare.  and shouldn't be looked at as a bad thing.  the server tries to mark the status correctly but in the end the agent has final say (if there is a disagreement).  if you have a specific use case that is reproducible that you feel doesn't match the above description, let me know.

for now, putting it into NEED INFO state.  heiko, please close or re-open as you see appropriate according to my feedback.

Comment 2 Heiko W. Rupp 2008-09-17 18:57:30 UTC

I don't really think this applies here, but as I can't remember any details from march and I did not see the issue when running operations lately, I think we can just close it.

Comment 3 Red Hat Bugzilla 2009-11-10 20:21:48 UTC

This bug was previously known as http://jira.rhq-project.org/browse/RHQ-100
This bug is related to RHQ-628