incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darren Middleman" <dmiddle...@gmail.com>
Subject Re: Why is GIOPConnection unconditionally dumping a stack trace for system exceptions
Date Mon, 20 Nov 2006 19:53:06 GMT
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:rickmcg@gmail.com]
> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message