Community
Participate
Working Groups
See description. We have no safeguard against this. This can be a problem even with a lone single-threaded client, for example, when the client commits a transaction and then immediately closes the session. Depending on the relative execution speeds of the server and the client, this may or may not lead to a server-side exception. One might think this isn't an issue for synchronous signals (i.e. RequestWithConfirmation), for the reason that the client remains suspended until the server is "done". But this assumption isn't entirely valid, because the client only remains suspended until the server is done transmitting his response data to this client. This doesn't mean the server-side Signal.runSync has finished all its work. There might be post-processing such as notifications to other clients, and during the time it takes to perform this work, the same client could close the session and cause the protocol to be deactivated. This can give, for example, an exception such as java.lang.IllegalStateException: Not active: SignalProtocol[cdo] at ... at org.eclipse.emf.cdo.internal.server.protocol.CommitTransactionIndication.getProtocol(CommitTransactionIndication.java:87) at org.eclipse.net4j.signal.Signal.runSync(Signal.java:254)
As discussed on Skype between Eike and myself, I will try to fix this by having deactivation of the protocol join on the execution of associated signals. That is, the deactivation will wait for execution of these signals to finish.
Caspar, please note that you may have to overwrite doBeforeDeactivate() rather than doDeactivate() because of the correlation between deactivate() and isActive(): public final Exception deactivate() { doBeforeDeactivate(); lifecycleState = LifecycleState.DEACTIVATING; doDeactivate(); lifecycleState = LifecycleState.INACTIVE; } public final boolean isActive() { return lifecycleState == LifecycleState.ACTIVE; }
Created attachment 175699 [details] Patch Yours noted. See patch.
Created attachment 176081 [details] Patch v2 - ready to be committed Caspar, I changed the way to ensure that a maximum of 10 seconds is sed to wait for. Please clone this bug to maintenance and commit there without review.
Committed to HEAD
Available in R20110608-1407
