1 Reply Latest reply on Jul 17, 2011 4:50 PM by jim stafford

    ScheduledDeliveryHandlerImpl.java:119 NPE during unsubscribe()

    jim stafford Newbie

      I am encountering an unwanted exception while trying to cleanup after a test with hornetq 2.2.5. It occurs when trying to remove a durable subscription that may or may not exist prior to the test running.

       

      It looks like the server implementation needs to remove an internal queue for the durable. I get a NullPointerException in a place where I don't know how it ever works. However, it only started occuring once I began changing the message redelivery times.

       

      The client receives a generic JMSException when this occurs with an embedded cause "HornetQException[errorCode=0 message=null]"

       

      If you look at HornetQServerImpl.destroyQueue, line 1101  you will see a call tohttp://anonsvn.jboss.org/repos/hornetq/tags/HornetQ_2_2_5_Final/src/main/org/hornetq/core/server/impl/http://anonsvn.jboss.org/repos/hornetq/tags/HornetQ_2_2_5_Final/src/main/org/hornetq/core/server/impl/QueueImpl.javaQueueImpl.deleteAllQueueReferences()

       

      1061    public void destroyQueue(final SimpleString queueName, final ServerSession session) throws Exception

      1062    {

      ...

      1101       queue.deleteAllReferences();

       

      deleteAllQueueReferences passes a null (final) Filter to deleteMatchingReferences, which passes the null to ScheduleDeliveryHandlerImpl.cancel()

       

      919    public int deleteAllReferences() throws Exception

      920    {

      921       return deleteMatchingReferences(null);

      922    }

      923

      924    public synchronized int deleteMatchingReferences(final Filter filter) throws Exception

      925    {

      ...

      948          List<MessageReference> cancelled = scheduledDeliveryHandler.cancel(filter);

       

       

      ScheduleDeliveryHandlerImpl.cancel() uses the filter without first testing for null. I am getting a NullPointerException on line 119.

       

      108    public List<MessageReference> cancel(final Filter filter)

      109    {

      110       List<MessageReference> refs = new ArrayList<MessageReference>();

      111

      112       synchronized (scheduledReferences)

      113       {

      114          Iterator<MessageReference> iter = scheduledReferences.iterator();

      115

      116          while (iter.hasNext())

      117          {

      118             MessageReference ref = iter.next();

      119             if (filter.match(ref.getMessage()))

       

        • 1. Re: ScheduledDeliveryHandlerImpl.java:119 NPE during unsubscribe()
          jim stafford Newbie

          After looking at this further, increasing the redelivery times had a lot to do with it. -- I believe with low redelivery times (default is 0ms) there is less chance for scheduledReferences to exist. With a high redelivery time (I was using 15000ms) I was consistently falling into the while() block and the filter match check.

           

          Too early to tell, but adding "filter==null ||" to ScheduleDeliveryHandlerImpl and using a high redelivery time seems to be working for my "shutdown during activity" test case. I was having issues where messages in-flight during a server shutdown commonly ended up in the DLQ (because EJB was shutting down) rather than back in the input destination. I am trying to keep the redelivery logic from getting to the failed state for the server shutdown case.

           

          One undesirable issue I found with using higher redelivery times is that returning, polling clients do not always have messages immediately available. It seems that the break in communication between polling intervals takes the server down the redelivery delay path. I think I would be happiest if I could find a means to shutdown message delivery and still allow message sends before/during EJB shutdown.