Re: JERI thread names

Thomas Vinod Johnson <[email protected]>
Newsgroups gmane.comp.java.sun.jini
Message-ID <[email protected]>
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]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.