[jboss-jira] [JBoss JIRA] Commented: (JBAS-5233) Logging synchronous cluster wide RPC calls as DEBUG, thoughts?

[Galder Zamarreno (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBAS-5233?page=comments#action_12420068 ] 
            
Galder Zamarreno commented on JBAS-5233:
----------------------------------------

When implementing this, make sure that any potential code for JBAS-5647 
does not log "expected" non-received responses at DEBUG.

> Logging synchronous cluster wide RPC calls as DEBUG, thoughts?
> --------------------------------------------------------------
>
>                 Key: JBAS-5233
>                 URL: http://jira.jboss.com/jira/browse/JBAS-5233
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> This is not really a bug but was not sure what category to put it under.
> When you do a synchronous (GET_ALL) cluster wide RPC call and you
> wanna find out which node might not have replied in time (1 min by default),
> this is logged at TRACE level in HAPartitionImpl:
>       if (excludeSelf)
>       {
>          if( trace )
>          {
>             log.trace("callMethodOnCluster(true), objName="+objName
>                +", methodName="+methodName+", members="+jgotherMembers);
>          }
>          rsp = this.callRemoteMethods(this.jgotherMembers, m, GroupRequest.GET_ALL, methodTimeout);
>       }
>       else
>       {
>          if( trace )
>          {
>             log.trace("callMethodOnCluster(false), objName="+objName
>                +", methodName="+methodName+", members="+members);
>          }
>          rsp = this.callRemoteMethods(null, m, GroupRequest.GET_ALL, methodTimeout);
>       }
>       if (rsp != null)
>       {
>          for (int i = 0; i < rsp.size(); i++)
>          {
>             Object item = rsp.elementAt(i);
>             if (item instanceof Rsp)
>             {
>                Rsp response = (Rsp) item;
>                // Only include received responses
>                boolean wasReceived = response.wasReceived();
>                if( wasReceived == true )
>                {
>                   item = response.getValue();
>                   if (!(item instanceof NoHandlerForRPC))
>                      rtn.add(item);
>                }
>                else if( trace )
>                   log.trace("Ignoring non-received response: "+response);
>             }
>             else
>             {
>                if (!(item instanceof NoHandlerForRPC))
>                   rtn.add(item);
>                else if( trace )
>                   log.trace("Ignoring NoHandlerForRPC");
>             }
>          }
>       }
> If you ask someone to enable TRACE for HAPartitionImpl (the logger 
> category would be org.jboss.ha.framework.server.HAPartition), there's the 
> secondary effect of any HAJNDI lookups that do not find a binding locally 
> printing a noisy stacktrace that can be ignored:
> [org.jboss.ha.framework.interfaces.HAPartition.partition-devl] Handle: HAJNDI.lookupLocally
> 2008-02-13 16:51:05,684 TRACE [org.jboss.ha.framework.interfaces.HAPartition.partition-devl] rpc call threw exception
> javax.naming.NameNotFoundException: hug not bound
> at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
> at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
> at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
> at org.jnp.server.NamingServer.lookup(NamingServer.java:267)
> at org.jnp.server.NamingServer.lookup(NamingServer.java:270)
> at org.jboss.ha.jndi.TreeHead.lookupLocally(TreeHead.java:296)
> at sun.reflect.GeneratedMethodAccessor453.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
> at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:1015)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
> at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
> at java.lang.Thread.run(Thread.java:595)
> So, my suggestion is, what about we log as DEBUG rather than TRACE messages in HAPartitionImpl:
> public ArrayList callMethodOnCluster(String objName, String methodName,
>        Object[] args, Class[] types, boolean excludeSelf, long methodTimeout) throws Exception

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira