Community
Participate
Working Groups
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.
Created attachment 191722 [details] Patch
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.
Internal note: SVR-1277
Created attachment 192434 [details] Patch v2 Some tests in SessionTest are failing.
The tests fail with the original patch, too. Please investigate...
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...
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.
Created attachment 192448 [details] Patch v3 Made localRequest field transient + some additional patching to avoid wrapping a remoteEx twice.
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?
Created attachment 192515 [details] Patch v4 My fault, not SVN's. Attaching patch v4, same as v3 except without the import removal.
Created attachment 192517 [details] Patch v5
Committed revision 7587.
Available in R20110608-1407
