activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Hoffstätte (JIRA) <>
Subject [jira] Commented: (AMQ-528) 4.0 M4 NullPointerException while shutting down
Date Tue, 11 Jul 2006 15:10:51 GMT
    [ ] 

Holger Hoffstätte commented on AMQ-528:

I did not originally experience this bug and don't have a fix for it - I just got curious
what might be causing the NPE inside the backport. However if you read my mail exchange with
Dawid it seems to me that the problem is a GC race on shutdown between the deallocated timer
and the Executor that has not yet been shut down properly. Obviously it is difficult to devise
a "simple" test case & patch for a GC race, however it seems obvious from the stack trace
that there's a still-running Executor somewhere that tries to use the freed counter. This
is a typical problem with the badly designed VM shutdownHook mechanism which does not allow
for dependenies or hook ordering. (admittedly this is a difficult problem)
So long story short, no I don't know what to do. You can try to run the "main" AMQ shutdown
hook with a higher priority but that is not what I would call reliable.

> 4.0 M4 NullPointerException while shutting down
> -----------------------------------------------
>          Key: AMQ-528
>          URL:
>      Project: ActiveMQ
>         Type: Bug

>     Versions: 4.0
>  Environment: RedHat Linux Enterprise Server 3, Tomcat 5.5.15, MySQL 5.0.18 for Linux
>     Reporter: Leon Hu
>     Priority: Critical
>      Fix For: 4.1, 4.0.2

> Setup: 
> 3 networked brokers, B1, B2, and B3, on 3 servers, connected using multicast discovery.
>  <broker useJmx="false" brokerName="B1"> 
>  <persistenceAdapter> 
>         <journaledJDBC journalLogFiles="5" dataDirectory="foo" dataSource="#mysql-ds"/>

>  </persistenceAdapter> 
>  <transportConnectors> 
>  <transportConnector uri="tcp://localhost:61616" discoveryUri="multicast://default"/>

>  </transportConnectors> 
>  <networkConnectors> 
>  <networkConnector uri="multicast://default"/> 
>  </networkConnectors> 
>  </broker> 
>  <bean id="mysql-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">

>            <property name="driverClassName" value="com.mysql.jdbc.Driver"/> 
>            <property name="url" value="jdbc:mysql://localhost/activemq?relaxAutoCommit=true"/>

>                  <property name="username" value="activemqUser"/> 
>                  <property name="password" value="activemqPwd"/> 
>                  <property name="poolPreparedStatements" value="true"/> 
>  </bean> 
> Similar for B2 and B3. 
> Two queues: Q1 and Q2. 
> Two producers, one for each queue, both producers connected to B1. 
> One Q1 cosumer connected to B1, another Q1 consumer on B2. 
> One Q2 consumer connected to B2, another Q2 consumer connected to B3. 
> Steps: 
> Start the brokers and start sending messages to the queue. 
> After a while, stop the brokers (Sequence does not matter) 
> See the errors in catalina.out of the Tomcat that has a broker with both producers and
consumers connected 
> The problems:
> 1. 
> Exception in thread "ActiveMQ Scheduler" java.lang.NullPointerException
>          at$SunPerfProvider.nanoTime(
>          at
>          at
>          at$ScheduledFutureTask.getDelay(
>  Exception in thread "ActiveMQ Scheduler" Exception in thread "ActiveMQ Scheduler" Exception
in thread "ActiveMQ Scheduler"      at
>          at
>          at$
>          at
>  java.lang.NullPointerException
>          at$SunPerfProvider.nanoTime(
>  Exception in thread "ActiveMQ Scheduler" Exception in thread "ActiveMQ Scheduler" Exception
in thread "ActiveMQ Scheduler"      at
>          at
>          at$ScheduledFutureTask.getDelay(
>          at
>          at
>  Exception in thread "ActiveMQ Scheduler" Exception in thread "ActiveMQ Scheduler"  
>          at
> 2. The same exception is logged to the log file (in my case catalina.out) for hundreds
of times, resulting a log file exceeding 150 MB in 2 minutes. 

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message