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)