Re: JERI thread names

Both great points -- I have revised my code accordingly (I originally
avoided getClientHostString() since it calls InetAddress.toString()
which I thought could be costly due to DNS resolution, but looking at
the InetAddress source this isn't the case...).

Thanks again, Bob, for pointing me in the right direction.

On 10/15/07, Thomas Vinod Johnson <[email protected]> wrote:
> Geoffrey Arnold wrote:
> > FYI, I was able to achieve my goal by implementing a custom
> > InvocationLayerFactory with a custom InvocationDispatcher.  Here's the
> > code:
> >
> >
> >     public class BasicILFactoryWithInvocationDispatcherThreadName
> > extends BasicILFactory {
> >
> >         // constructors removed for clarity
> >
> >         protected InvocationDispatcher
> > createInvocationDispatcher(Collection methods, Remote remote,
> > ServerCapabilities serverCapabilities) throws ExportException {
> >             return new
> > BasicInvocationDispatcherWithThreadNaming(methods, serverCapabilities,
> > getServerConstraints(), getPermissionClass(), getClassLoader());
> >         }
> >
> >         private static class BasicInvocationDispatcherWithThreadNaming
> > extends BasicInvocationDispatcher {
> >
> >             public
> > BasicInvocationDispatcherWithThreadNaming(Collection collection,
> > ServerCapabilities serverCapabilities, MethodConstraints
> > methodConstraints, Class aClass, ClassLoader classLoader) throws
> > ExportException {
> >                 super(collection, serverCapabilities,
> > methodConstraints, aClass, classLoader);
> >             }
> >
> >             protected Object invoke(Remote remote, Method method,
> > Object[] objects, Collection collection) throws Throwable {
> >                 String newThreadName = String.format("[%s][%s.%s]",
> > Util.getClientHost().getHostAddress(),
> > remote.getClass().getSimpleName(), method.getName());
> >
> >                 String oldThreadName = Thread.currentThread().getName();
> >                 Thread.currentThread().setName(newThreadName);
> >
> >                 try {
> >                     return super.invoke(remote, method, objects, collection);
> >                 }
> >                 finally {
> >                     Thread.currentThread().setName(oldThreadName);
> >                 }
> >             }
> >
> >         }
> >
> >     }
> >
> >
> >
> It could be useful purely from a familiarity point of view to retain the
> original name information too, say by appending this information to
> oldThreadName (also in theory Util.getClientHost could return null,
> maybe you want to use getClientHostString)
> > Hope this helps,
> > Geoff.
> >
> > On 10/12/07, Geoffrey Arnold <[email protected]> wrote:
> >
> >> Hey Bob,
> >>
> >> I believe that I can override
> >> BasicILFactory.createInvocationDispatcher() to return a custom
> >> subclass of BasicInvocationDispatcher which overrides the dispatch()
> >> method to use Util.getClientHost() to set the current thread name
> >> before invoking the method.  Does this sound right?
> >>
> >> Geoff.
> >>
> >> On 10/11/07, Geoffrey Arnold <[email protected]> wrote:
> >>
> >>> Thanks Bob and Gregg.
> >>>
> >>> Bob, I wasn't aware of the output available from
> >>> BasicInvocationDispatcher log levels, however even that doesn't get me
> >>> what I need.  My issue is exactly what Gregg mentioned, namely the
> >>> ability to associate logging for the entire context of a given remote
> >>> invocation with an IP address, not just the remote method.
> >>>
> >>> Geoff.
> >>>
> >>> On 10/11/07, Gregg Wonderly <[email protected]> wrote:
> >>>
> >>>> Bob Scheifler wrote:
> >>>>
> >>>>> Geoffrey Arnold wrote:
> >>>>>
> >>>>>
> >>>>>> It would be useful for logging/debugging purposes if the name of the
> >>>>>> JERI mux request dispatch thread (@see
> >>>>>> com.sun.jini.jeri.internal.mux.MuxServer) included some information
> >>>>>> about the caller (we would specifically be interested in the IP
> >>>>>> address of the caller).
> >>>>>>
> >>>>> Could you describe what analysis problems you're trying to aid?
> >>>>> I take it that the client host logged at FINEST for inbound calls
> >>>>> by BasicInvocationDispatcher is not sufficient?
> >>>>>
> >>>> When trying to debug transactions that are hung and other things visible in
> >>>> stack traces, it nice to be able to see threads named with host addresses or
> >>>> other direct indicators so that you can assure yourself of which thread is
> >>>> associated with which activity.
> >>>>
> >>>> Gregg Wonderly
> >>>>
> >>>> --------------------------------------------------------------------------
> >>>> Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
> >>>> Community Web Site:  http://jini.org
> >>>> jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
> >>>> Unsubscribing:       email "signoff JINI-USERS"  to [email protected]
> >>>>
> >>>>
> >
> > --------------------------------------------------------------------------
> > Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
> > Community Web Site:  http://jini.org
> > jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
> > Unsubscribing:       email "signoff JINI-USERS"  to [email protected]
> >
>
>

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]