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

Bug 340725

Summary:

Make server-side exceptions easier to correlate with their client-side causes

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:

enhancement

Priority:

CC:

saulius.tvarijonas

Version:

4.0

Flags:

stepper: review-
stepper: review-
stepper: review+

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Patch	none
Demo (as a patch)	none
Patch v2	none
Patch v3	none
Patch v4	none
Patch v5	none

Description Caspar D.

2011-03-23 02:08:14 EDT

We have a properly functioning mechanism in place for communicating
remote exceptions back to the client through a separate
RemoteExceptionRequest. The corresponding indication notifies the client-side
signal of the remote problem, cancels the signal, etc. etc. Works beautifully,
but...

In practice, client-side application logic doesn't deal with signal objects
directly, so all it can do is catch a RemoteException. But this object doesn't
contain a reference to the signal that caused the remote exception. So even
though the relevant info is present on the client side, the app logic can't
really get to it, which makes debugging remote exceptions pretty hard.

In order to address this, I propose that the RemoteException be given a 
reference to the client-side signal that caused the problem, and also
a stacktrace at the time the problem is detected locally.

Patch coming up.

Comment 1 Caspar D.

2011-03-23 02:15:58 EDT

Created attachment 191722 [details]
Patch

Comment 2 Caspar D.

2011-03-23 02:36:12 EDT

Created attachment 191725 [details]
Demo (as a patch)

This 'unit test' doesn't really test anything, but shows how
I envision the new info being retrieved and used. I think it
really makes debugging the client-side in case of a remoteEx
a lot easier.

Comment 3 Caspar D.

2011-03-30 03:46:35 EDT

Internal note: SVR-1277

Comment 4 Eike Stepper

2011-04-04 01:10:59 EDT

Created attachment 192434 [details]
Patch v2

Some tests in SessionTest are failing.

Comment 5 Eike Stepper

2011-04-04 01:12:29 EDT

The tests fail with the original patch, too. Please investigate...

Comment 6 Caspar D.

2011-04-04 06:31:13 EDT

Hmm... a curious situation. What happens is that the openSessionRequest
from the client to the server, triggers an authenticationRequest from
the server to the client, which then fails on the client side because
there is no credentialsProvider. And the exception to that effect is
serialized back to the server, which is wrapped into a RemoteException
after deserialization and associated with the original openSessionRequest.
In turn, the openSessionRequest then notifies the client of this exception,
which leads to a "RemoteRemoteException" on the client...

Comment 7 Caspar D.

2011-04-04 06:57:17 EDT

And the problem lies therein, that a remote-remote-exception, requires
the original remoteException to be serialized... but with my patch,
this object has a field localRequest, which (in this case) references
the AuthenthicationRequest instance -- which is not serializable.
Hence, a NotSerializableException occurs, which is snuffed on the server
side (why?), and leaves the client side without a remoteEx object to
deserialize.

Comment 8 Caspar D.

2011-04-04 07:10:26 EDT

Created attachment 192448 [details]
Patch v3

Made localRequest field transient + some additional patching to avoid
wrapping a remoteEx twice.

Comment 9 Eike Stepper

2011-04-04 10:41:28 EDT

The diff of BufferInputStream.java shows that you've removed "import org.eclipse.net4j.util.io.IOTimeoutException;" while it's still being referened: https://bugs.eclipse.org/bugs/attachment.cgi?id=192448&action=diff . This leads to a compile error. Can't we trust in SVN anymore?

Comment 10 Caspar D.

2011-04-04 22:26:16 EDT

Created attachment 192515 [details]
Patch v4

My fault, not SVN's. Attaching patch v4, same as v3 except 
without the import removal.

Comment 11 Eike Stepper

2011-04-05 00:10:30 EDT

Created attachment 192517 [details]
Patch v5

Comment 12 Caspar D.

2011-04-05 00:41:35 EDT

Committed revision 7587.

Comment 13 Eike Stepper

2011-06-23 03:40:08 EDT

Available in R20110608-1407