Getting NullPointerException from HornetQConnectionFactory.finalize

[petal1]

Hello,

Whilst running JBoss6.0.0.Final (which I believe is bundled with version 2.1.2.Final of HornetQ), I ran into this exception when trying to bind a temporary queue:

javax.naming.NamingException: Failed to serialize object:HornetQTemporaryQueue[f0d724cc-dbc1-431c-8fcc-c43e7574a7d1], org.hornetq.jms.client.HornetQSession

and having read this post, it sounded like I was running into the bug mentioned:

https://community.jboss.org/message/575913

so I upgraded one of ny nodes to JBoss 6.1.0 (which is bundled with HornetQ 2.2.5.Final). Apart from getting nothing in boot.log (not even created) or server.log (created but empty) - very frusrating, I am getting the following exception:

java.lang.NullPointerException

        at org.hornetq.jms.client.HornetQConnectionFactory.finalize(HornetQConnectionFactory.java:725)

Having looked at the source code I can see that serverLocator must be null. Could someone please tell me what the issue is?

The only difference I could see in the HornetQ configuration files between the versions was in deploy/hornetq-jms.xml, which in the newer version had <xa>true</xa> in each connection-factory definition. Clutching at straws, I tried removing that, but it made no difference.

The only thing I can think of is that the error is the result of a JNDI lookup of a Queue on one of my other nodes that is still running JBoss6.0.0.Final and there is some sort of compatibility issue?

Thanks for any help.

[ataylor]

can you provied more information about what you are doing to create each exception

[petal1]

Hi,

I wrote a simple test program to illustrate the issue that prompted my move to JBoss 6.1.0:

001  InitialContext context = new InitialContext();

002  QueueConnectionFactory          factory = (QueueConnectionFactory)context.lookup("ConnectionFactory");

003  QueueConnection          connection = factory.createQueueConnection();

004  QueueSessionm_session = connection.createQueueSession(true, 0);

005  Queue queue = session.createTemporaryQueue();

006  context.bind("queue/myTestQueue", queue);

Line 006 throws this:

          javax.naming.NamingException: Failed to serialize object:HornetQTemporaryQueue[3894ac6b-4326-4323-8460-192f9bd13da8], org.hornetq.jms.client.HornetQSession

        at org.hornetq.jms.referenceable.SerializableObjectRefAddr.<init>(SerializableObjectRefAddr.java:63)

        at org.hornetq.jms.client.HornetQDestination.getReference(HornetQDestination.java:254)

        at org.jnp.interfaces.NamingContext.bind(NamingContext.java:634)

        at org.jnp.interfaces.NamingContext.bind(NamingContext.java:613)

        at javax.naming.InitialContext.bind(InitialContext.java:400)

        at HornetQTest2.bindToReceiver(HornetQTest2.java:54)

        at HornetQTest2.runTest1(HornetQTest2.java:29)

        at HornetQTest2.main(HornetQTest2.java:77)

This error does not occur on JBoss 6.1.0.Final.

But on JBoss 6.1.0 I get other errors, one of which is the one I posted. The full stack trace is this:

          java.lang.NullPointerException

          at org.hornetq.jms.client.HornetQConnectionFactory.finalize(HornetQConnectionFactory.java:725)

          at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)

          at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)

          at java.lang.ref.Finalizer.access$100(Finalizer.java:14)

          at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)

This error appears over and over again. None of our classes are on the stack trace. It is not easy for me to determine what is causing this error. I cannot easliy recompile and deploy our code with debug diagnostic lines, but I will try my best to write a test that reproduces the error. However, given the stacktrace, I was hoping that someone would be able to offer guidance as to what the likely cause of the error is?

Thanks,

Paul

[petal1]

I wrote a simple test program and was able to reproduce the finalize error. As I suspected it was resolved when ensuring the JMS client was using the same version of the HornetQ jars as were deployed in JBoss.