Bug 535930 (RHQ-332)
| Summary: | Improve handling of double submission of operation schedules | ||
|---|---|---|---|
| Product: | [Other] RHQ Project | Reporter: | Charles Crouch <ccrouch> |
| Component: | Operations | Assignee: | Joseph Marques <jmarques> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Corey Welton <cwelton> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.0 | CC: | hbrock |
| Target Milestone: | --- | Keywords: | SubBug |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://jira.rhq-project.org/browse/RHQ-332 | ||
| Whiteboard: | |||
| 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 536330 | ||
JBoss Seam has a mechanism for handling double-submissions. Once that comes in (hopefully 1.2), we'll use that across the board. 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. 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. This bug was previously known as http://jira.rhq-project.org/browse/RHQ-332 |
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)