Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 321193

Summary:

CDOServerProtocol can get deactivated while associated Signals are still executing

Product:

[Modeling] EMF

Reporter:

Caspar D. <caspar_d>

Component:

cdo.net4j

Assignee:

Caspar D. <caspar_d>

Status:

CLOSED FIXED

QA Contact:

Eike Stepper <stepper>

Severity:

normal

Priority:

CC:

saulius.tvarijonas, stepper

Version:

4.0

Flags:

stepper: review+

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Patch	none
Patch v2 - ready to be committed	none

Description Caspar D.

2010-07-29 04:13:51 EDT

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)

Comment 1 Caspar D.

2010-07-29 04:16:11 EDT

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.

Comment 2 Eike Stepper

2010-07-29 04:36:19 EDT

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;
  }

Comment 3 Caspar D.

2010-08-02 06:17:40 EDT

Created attachment 175699 [details]
Patch

Yours noted. See patch.

Comment 4 Eike Stepper

2010-08-07 04:00:02 EDT

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.

Comment 5 Caspar D.

2010-08-08 23:17:47 EDT

Committed to HEAD

Comment 6 Eike Stepper

2011-06-23 03:39:28 EDT

Available in R20110608-1407