You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leif Mortenson <le...@tanukisoftware.com> on 2002/04/28 18:43:32 UTC
Alrrmi: ExceptionReply - lack of a stack trace.
I spent much of today tracking down a NullPointerException being thrown
on the server,
but detected on the client.
After much investigation, the problem turned out to be a simple mistake
in my server-side code.
The reason that it was so difficult to track down was that in the
process of sending the NPE back
to the client via an ExceptionReply, the stack trace is lost. This
means that when printStackTrace()
is called on the reconstructed exception, you were simply getting the
following:
java.lang.NullPointerException
Not very helpful. I modified the ExceptionReply class to call
fillInStackTrace after the exception
is reconstructed. This makes it at least possible to see that the
exception was remote.
printStackTrace() now shows the following:
java.lang.NullPointerException
at
org.apache.excalibur.altrmi.common.ExceptionReply.readExternal(ExceptionReply.java:117)
at
java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1218)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:392)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:242)
at
org.apache.excalibur.altrmi.common.SerializationHelper.getInstanceFromBytes(SerializationHelper.java:94)
at
org.apache.excalibur.altrmi.client.impl.stream.ClientCustomStreamReadWriter.readReply(ClientCustomStreamReadWriter.java:98)
at
org.apache.excalibur.altrmi.client.impl.stream.ClientCustomStreamReadWriter.postRequest(ClientCustomStreamReadWriter.java:61)
at
org.apache.excalibur.altrmi.client.impl.stream.StreamInvocationHandler.handleInvocation(StreamInvocationHandler.java:131)
at
org.apache.excalibur.altrmi.client.impl.DefaultProxyHelper.processObjectRequestGettingFacade(DefaultProxyHelper.java:143)
at
AltrmiGeneratedInstrumentManagerClient_org$apache$avalon$excalibur$instrument$manager$interfaces$InstrumentDescriptor.createInstrumentSample(AltrmiGeneratedInstrumentManagerClient_org$apache$avalon$excalibur$instrument$manager$interfaces$InstrumentDes
at
org.apache.avalon.excalibur.instrument.client.InstrumentClientFrame$6.run(InstrumentClientFrame.java:438)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:160)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:399)
at
java.awt.EventDispatchThread.pumpOneEvent(EventDispatchThread.java:109)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:99)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Much more useful, but this still does not tell me where in the server
code the exception was happening.
As there is no way to encode the original stack trace, would it be
possible to add some code on either
end to display these stack traces in the debug channel of a logger?
Any other ideas on how to make this work more cleanly?
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Alrrmi: ExceptionReply - lack of a stack trace.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Paul Hammant wrote:
>>>Another technique that I've seen is to capture the stack trace to a string on
>>>the server and then serialize the string. There was some code I found to do
>>>that (it actually broke the stacktrace up into classes) but I can't find it
>>>atm via google.
>>>
>>>
>>>
>>I was thinking about this some more. I have a suggested solution, but
>>it is a bit "hacky".. :-/
>>
>>Server side:
>>1) serialize the Throwable to a byte array.
>>2) capture the output of printStackTrace() including line feeds into
>>another byte array.
>>3) replace the original message of the Throwable with the entire stack
>>trace including message.
>>
>>
>
>
>
>>4) send the modified serialized Throwable off to the client.
>>
>>Client side:
>>1) Deserialize the patched Throwable into a new Throwable instance.
>>2) call fillInStackTrace on the Throwable.
>>
>>
>
>That will be hard as AltRMI supports transport of any exception. Surely to replace the
>getMessage() some custom extension of the problem exception is needed.
>
>If the client wants to do instanceof on the exception, then a general replacement exception will
>not be the same thing.
>
I don't think that I explained myself very well. I am not sure that
this would work for all protocols,
but the idea was to replace the message text in the stream of the
serialized exception.
On the client side, the exception would simply be deserialized and would
never know that it
had been modified. This way, no new classes would be necessary. A
NullPointerException would
really still be a NullPointerException. If we could create a new
subclass, then things would get
easy as we could control the server stide stack trace. But as you said,
this is not possible.
>>Now, when you call printStackTrace, you will see the stack trace on the
>>server followed
>>by the stacktrace on the client. This would give all the information
>>needed.
>>
>>Problem is that when you call getMessage on the client, you will get a
>>message which includes
>>the server-side stack trace. Question is this worth it to make the
>>stack trace useful?
>>
>>
>
>I have doubts as to suitability.
>
>What about a debug mode which does transport the stack trace for each exception and joural it
>to the console on the client side. Maybe also to logkit on the server side...
>
This would work as well. Just add the print stack trace output to the
serialized output on the server
and then get it back out on the client. That output could be sent to
the debug channel on both ends
if it is configured.
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Alrrmi: ExceptionReply - lack of a stack trace.
Posted by Paul Hammant <pa...@yahoo.com>.
> >Another technique that I've seen is to capture the stack trace to a string on
> >the server and then serialize the string. There was some code I found to do
> >that (it actually broke the stacktrace up into classes) but I can't find it
> >atm via google.
> >
> I was thinking about this some more. I have a suggested solution, but
> it is a bit "hacky".. :-/
>
> Server side:
> 1) serialize the Throwable to a byte array.
> 2) capture the output of printStackTrace() including line feeds into
> another byte array.
> 3) replace the original message of the Throwable with the entire stack
> trace including message.
> 4) send the modified serialized Throwable off to the client.
>
> Client side:
> 1) Deserialize the patched Throwable into a new Throwable instance.
> 2) call fillInStackTrace on the Throwable.
That will be hard as AltRMI supports transport of any exception. Surely to replace the
getMessage() some custom extension of the problem exception is needed.
If the client wants to do instanceof on the exception, then a general replacement exception will
not be the same thing.
> Now, when you call printStackTrace, you will see the stack trace on the
> server followed
> by the stacktrace on the client. This would give all the information
> needed.
>
> Problem is that when you call getMessage on the client, you will get a
> message which includes
> the server-side stack trace. Question is this worth it to make the
> stack trace useful?
I have doubts as to suitability.
What about a debug mode which does transport the stack trace for each exception and joural it
to the console on the client side. Maybe also to logkit on the server side...
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Alrrmi: ExceptionReply - lack of a stack trace.
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Peter Royal wrote:
>On Sunday 28 April 2002 12:43 pm, Leif Mortenson wrote:
>
>
>>The reason that it was so difficult to track down was that in the
>>process of sending the NPE back
>>to the client via an ExceptionReply, the stack trace is lost. This
>>
>>
>
>I believe this is a general problem when serializing exceptions, the
>stacktrace is transient.
>
>
>
>>As there is no way to encode the original stack trace, would it be
>>possible to add some code on either
>>end to display these stack traces in the debug channel of a logger?
>>
>>
>
>Actually JDK 1.4 fixes this for RMI, which means it should be possible for
>altrmi.
>
>My current solution is to do a manual version of what you describe on the
>server side, but making in automagic in altrmi would be excellent.
>
>
>
>>Any other ideas on how to make this work more cleanly?
>>
>>
>
>Another technique that I've seen is to capture the stack trace to a string on
>the server and then serialize the string. There was some code I found to do
>that (it actually broke the stacktrace up into classes) but I can't find it
>atm via google.
>
I was thinking about this some more. I have a suggested solution, but
it is a bit "hacky".. :-/
Server side:
1) serialize the Throwable to a byte array.
2) capture the output of printStackTrace() including line feeds into
another byte array.
3) replace the original message of the Throwable with the entire stack
trace including message.
4) send the modified serialized Throwable off to the client.
Client side:
1) Deserialize the patched Throwable into a new Throwable instance.
2) call fillInStackTrace on the Throwable.
Now, when you call printStackTrace, you will see the stack trace on the
server followed
by the stacktrace on the client. This would give all the information
needed.
Problem is that when you call getMessage on the client, you will get a
message which includes
the server-side stack trace. Question is this worth it to make the
stack trace useful?
Thoughts?
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Alrrmi: ExceptionReply - lack of a stack trace.
Posted by Peter Royal <pr...@apache.org>.
On Sunday 28 April 2002 12:43 pm, Leif Mortenson wrote:
> The reason that it was so difficult to track down was that in the
> process of sending the NPE back
> to the client via an ExceptionReply, the stack trace is lost. This
I believe this is a general problem when serializing exceptions, the
stacktrace is transient.
> As there is no way to encode the original stack trace, would it be
> possible to add some code on either
> end to display these stack traces in the debug channel of a logger?
Actually JDK 1.4 fixes this for RMI, which means it should be possible for
altrmi.
My current solution is to do a manual version of what you describe on the
server side, but making in automagic in altrmi would be excellent.
> Any other ideas on how to make this work more cleanly?
Another technique that I've seen is to capture the stack trace to a string on
the server and then serialize the string. There was some code I found to do
that (it actually broke the stacktrace up into classes) but I can't find it
atm via google.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>