Red Hat Bugzilla – Bug 719329
(enhancement) add an operation results page that polls the Server for operation completion and displays the results once the operation has completed
Last modified: 2015-02-01 18:29:20 EST
The RHQ server API for invoking an operation is asynchronous, even for immediately executed operations, so the operation results page would have to poll the server (perhaps every 5 or 10 seconds) to check if the operation has completed. Once it knows the operation has completed, it could ask the Server for the results and display them. During the polling, it could display some sort of "waiting" icon and a message stating that is is waiting for the operation to complete. After the user executes an operation immediately, they could be redirected to this new results page. For other scheduled operations, the user could be sent to this page when they click on the operation on the group Operations>Schedule page.
Thanks Ian for raising issue from my request. It might have a problem with long-running operation such as start or shutdown servers. So I think it would be nice if it's selectable for each operation. Now RHQ provides 4 options for operation scheduling: - Now - Now & Repeat - Later - Later & Repeat My idea is adding new option 'Synchronized'. We can specify whether an operation supports 'Synchronized' option or not at operation definition in the rhq-plugin.xml as following: -------- <operation name="helloWorld" supportSynchExec="true"> ... </operation> -------- If supportSynchExec is true, 'Synchronized' is selected in default at the operation scheduling settings, otherwise it can't be chosen.
I assume you mean "Synchronous" not "Synchronized". I'm not sure that would be necessary. I was thinking that the user would always be taken to the operation results page after scheduling an operation to run Now. For long-running operations, they could always navigate away from the page at which point the GUI would stop polling the Server unless they returned to the page. The tricky part is that the results are ultimately part of an operation history item, and there is currently no relationship in the db between an operation schedule and the operation histories corresponding to invocations of that schedule. However, an operation history item does include the Quartz job name, by which the schedule could be queried. A related improvement in the operations GUI would be to add a table on the details page for an existing operation schedule that lists all operation history items, if any, corresponding to that schedule. Without a db relationship between schedules and histories, this would involve querying for all histories with the same quartz job id as the schedule. If we did this, then we could just always redirect users to this page after they create a schedule, even if they specified Now & Repeat, Later, or Later & Repeat.