RHQ GUI: how to deal with user clicking to navigate to view X and then clicking to navigate to view Y before X has finished loading

Ian Springer ian.springer at redhat.com
Mon Aug 15 19:31:35 UTC 2011


On 08/15/2011 01:27 PM, Robert Buck wrote:
> Outbound-filtering was an optimization to avoid unnecessary busywork, to
> reduce CPU load and reduce the number of branches in the code (a
> simplification actually to a single case).
>
> Yes, somewhere have some global state, a static if you will, that is the
> UUID. A mouse-click, e.g., would trigger an update to the UUID
> request-id. This occurs before any RPC request is sent out. But you need
> to make sure that the following holds true:
>
>     for each Ei of Ai, all Ui must be identical; that is all causally
> related events MUST use the same UUID
>
> , where E=event, A=action, U=unique-ids.
>
> Bob

In most cases, the Ei RPC requests are sequential, where E1's 
onSuccess() handler invokes E2, E2's onSuccess() handler invokes E3, 
etc. In such cases, we'd be fine, because if the uuid changed during E1, 
when E1 returned, it would drop its response, and E2, E3, etc. would 
never get invoked.

However, I'm not sure if there are exceptions to this, where for a given 
navigation, some of the requests are initiated in parallel. If there are 
any such exceptions, we might need to store away the current uuid at the 
time the navigation is initiated and then compare it the current uuid 
prior to making the parallel outgoing RPC requests, in order to prevent 
these requests from getting assigned the wrong uuid.

One example of parallel RPC requests I can think of off the top of my 
head is ConfigurationEditor.onDraw(), which initiates two RPC requests 
in parallel - one to retrieve the Configuration and one to retrieve the 
ConfigurationDefinition. So there may certainly be other places where we 
do it.



More information about the rhq-devel mailing list