Hello Rick,
From the look of the stack trace in your email, I think what is happening is
that the client which is making the call to the Sun Nameservice is simply reacting to an exception that it is receiving over the wire. It looks as if the reply that your client received upon making a request to the Sun Nameservice contained a NO_PERMISSION system exception (this is why the stack trace shows that it is
unmarshalling a system exception). This means that the actual exception itself is being generated on the Sun Nameservice side of things and is being passed back to your Geronimo client. Without know what the client is doing or what is happening on the Nameservice side of things, I not really sure what could be causing the NO_PERMISSION exception. Cheers, Darren
-----Original Message----- From: Rick McGuire [mailto:[EMAIL PROTECTED] Sent: Monday, November 20, 2006 1:38 PM To: yoko-dev@incubator.apache.org Subject: Re: Why is GIOPConnection unconditionally dumping a stack trace for system exceptions Ok, I've been chasing after this one since Friday, and I've finally figured out part of the problem. I'm getting exceptions throw by the ORB that are giving me a stack trace from another thread. For problem determination purposes, this is almost worthless. I've been working for 4 days trying to narrow this down. These exceptions really should be giving the thread stack of the triggering event, not the short, disconnected stack for the thread handling the request. Does anybody know where this exception is getting rethrown so I can trigger my own stack trace from that point? Rick Rick McGuire wrote: > When running in Geronimo, I see a lot of stack traces showing up like > this: > > org.omg.CORBA.NO_PERMISSION: vmcid: 0x0 minor code: 0x0 completed: No > at org.apache.yoko.orb.OB.Util.unmarshalSystemException(Util.java
:120)
> at org.apache.yoko.orb.OB.GIOPConnection.processReply(
GIOPConnection.java:549)
> at org.apache.yoko.orb.OB.GIOPConnection.processMessage(
GIOPConnection.java:357)
> at org.apache.yoko.orb.OB.GIOPConnectionThreaded.execReceive(
GIOPConnectionThreaded.java:465)
> at org.apache.yoko.orb.OB.GIOPConnectionThreaded$ReceiverThread.run(
GIOPConnectionThreaded.java:63)
> > This is not particularly useful, given it's occurring in a thread > context that doesn't give any clues as to the source of origin, and it > seems fairly impolite for the yoko code to be printing this out in > this fashion. > > That aside, this particular problem is driving me nuts. The code in > question is trying to access a Sun NameService to perform an object > lookeup, and I'm seeing this constantly. Can anybody suggest anything > I might do to narrow down the root cause of this problem? > > Rick
