You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Timothy Bish (Created) (JIRA)" <ji...@apache.org> on 2012/01/20 17:33:39 UTC
[jira] [Created] (AMQ-3672) NPE exception when querying a starting
broker use JMX program
NPE exception when querying a starting broker use JMX program
--------------------------------------------------------------
Key: AMQ-3672
URL: https://issues.apache.org/jira/browse/AMQ-3672
Project: ActiveMQ
Issue Type: Bug
Components: JMX
Affects Versions: 5.5.1
Reporter: Timothy Bish
Assignee: Timothy Bish
Priority: Trivial
Fix For: 5.6.0
Hi,
This occurs in the latest release, SP-20. Essentially if your broker is slow starting up, e.g. you force a rebuild of the index file by deleting db.data & db.redo on a large kahadb and you try to obtain the list of queues on the broker, e.g. mbean.getQueues(), you'll get a NPE exception:
{noformat}
java.lang.NullPointerException
at org.apache.activemq.broker.jmx.BrokerView.getQueues(BrokerView.java:189)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:65)
at com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:216)
at javax.management.StandardMBean.getAttribute(StandardMBean.java:358)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:666)
at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1404)
at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360)
at javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:600)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
{noformat}
Looks like the BrokerService initially creates the BrokerView with a null ManagedRegionBroker and then later fills this in once the BrokerSerice start is completed. When the index is being recovered this process is delayed and you have the chance to get access to the BrokerView while it still doesn't have its ManagedRegionBroker instance set.
This affects a slave as well as a normal broker that requires a long time to start up the store. The BrokerView class should be checking the broker reference to see if its not set and throw an IllegalStateException indicating that the broker is not yet started.
There are also cases where a NullPointerException from the removeConnector methods that should be checked and a NoSuchElementException in those cases
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-3672) NPE exception when querying a starting
broker use JMX program
Posted by "Timothy Bish (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish resolved AMQ-3672.
-------------------------------
Resolution: Fixed
Fix applied in trunk along with a test case
> NPE exception when querying a starting broker use JMX program
> --------------------------------------------------------------
>
> Key: AMQ-3672
> URL: https://issues.apache.org/jira/browse/AMQ-3672
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMX
> Affects Versions: 5.5.1
> Reporter: Timothy Bish
> Assignee: Timothy Bish
> Priority: Trivial
> Fix For: 5.6.0
>
>
> Hi,
> This occurs in the latest release, SP-20. Essentially if your broker is slow starting up, e.g. you force a rebuild of the index file by deleting db.data & db.redo on a large kahadb and you try to obtain the list of queues on the broker, e.g. mbean.getQueues(), you'll get a NPE exception:
> {noformat}
> java.lang.NullPointerException
> at org.apache.activemq.broker.jmx.BrokerView.getQueues(BrokerView.java:189)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
> at com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:65)
> at com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:216)
> at javax.management.StandardMBean.getAttribute(StandardMBean.java:358)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:666)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638)
> at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1404)
> at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
> at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
> at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360)
> at javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:600)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> {noformat}
> Looks like the BrokerService initially creates the BrokerView with a null ManagedRegionBroker and then later fills this in once the BrokerSerice start is completed. When the index is being recovered this process is delayed and you have the chance to get access to the BrokerView while it still doesn't have its ManagedRegionBroker instance set.
> This affects a slave as well as a normal broker that requires a long time to start up the store. The BrokerView class should be checking the broker reference to see if its not set and throw an IllegalStateException indicating that the broker is not yet started.
> There are also cases where a NullPointerException from the removeConnector methods that should be checked and a NoSuchElementException in those cases
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira