Bug 535930 - (RHQ-332) Improve handling of double submission of operation schedules
Improve handling of double submission of operation schedules
Status: CLOSED NEXTRELEASE
Product: RHQ Project
Classification: Other
Component: Operations (Show other bugs)
1.0
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: Joseph Marques
Corey Welton
http://jira.rhq-project.org/browse/RH...
: SubBug
Depends On:
Blocks: RHQ-692
  Show dependency treegraph
 
Reported: 2008-04-17 14:39 EDT by Charles Crouch
Modified: 2015-02-01 18:25 EST (History)
1 user (show)

See Also:
Fixed In Version: 1.2
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: ---


Attachments (Terms of Use)

  None (edit)
Description Charles Crouch 2008-04-17 14:39:00 EDT
I was trying to schedule a Manual Autodiscovery operation on a platform to execute immediately and I got carried away and double clicked on the schedule button. The result was, according to the operation history, that I got one operation started (in progress) which just sat there for a while, longer than the few seconds it should take to complete the operation. Clicking on the details of operation history item I get an error message saying the result could be not retrieved. After about 5mins the operation completed and went to successfully executed. Clicking on the item now shows the results I would expect, i.e. the duration of the execution.

In the server log I see 

2008-04-17 13:05:55,609 ERROR [org.rhq.enterprise.communications.command.client.ClientCommandSenderTask] {ClientCommandSenderTask.send-failed}Failed to send command [Command: type=[remotepojo]; cmd-in-response=[false]; config=[{rhq.guaranteed-delivery=true, rhq.send-throttle=true}]; params=[{targetInterfaceName=org.rhq.core.clientapi.agent.discovery.DiscoveryAgentService, invocation=NameBasedInvocation[synchronizeInventory]}]]. Cause: java.util.concurrent.TimeoutException:null. Cause: java.util.concurrent.TimeoutException
2008-04-17 13:05:55,609 WARN  [org.rhq.enterprise.communications.command.client.ClientCommandSenderTask] {ClientCommandSenderTask.queuing-failed-command}The command that failed has its guaranteed-delivery flag set so it is being queued again


So I think there are maybe two issues here:
1) We need to be able to better handle double submission of forms. This should probably be addressed more globally to see if we can come up with a solution that will work for all JSF backed form submissions.
2) Error when retrieving details on an operation. We should always be able to return the results of an  operation, "in progress" should just return null/empty. Maybe the error I saw here was related to 1)
Comment 1 Joseph Marques 2008-07-20 19:18:44 EDT
JBoss Seam has a mechanism for handling double-submissions.  Once that comes in (hopefully 1.2), we'll use that across the board.
Comment 2 Joseph Marques 2009-02-15 23:53:34 EST
rev3075 - prevent double submissions of operations; 

fixed this using javascript instead of Seam, because it was quicker to add a few lines of JS than migrating the existing components to seam-enabled ones.
Comment 3 Corey Welton 2009-03-24 21:14:18 EDT
QA Verified, I attempted to double schedule ops on a couple different platforms/servers.  One time I did appear to have managed getting two scheduled at once, but never any issues in the serverlog(s) about collisions.
Comment 4 Red Hat Bugzilla 2009-11-10 16:07:12 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-332

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