JBossDeveloper

Andy,

Thanks for the offer to take a look at this. I suspect that you are right - that it is a config problem.

I have attached the following artifacts:

- drawer-manager.ear - this is the EJB

- Common.zip - this is the source of the method called from the EJB to publish a message to a topic (look for TopicPublisher.java)

- deploy.zip - this is the hornetq.sar and hornetq-ra.rar

- MessageManager.zip - this is the standalone HornetQ server

- webster.zip - this is the native Windows exe to invoke the EJB

Instructions:

1. Machine A: (OS doesn't matter)

     A. Copy and unzip MessageManager.zip to a temp directory

     B. Change to the bin dir under the temp dir

     C. Run either run.bat or run.sh to start the standalone HornetQ server using 231.7.7.7:9876 as the discovery

2. Machine B: (must be a Win machine)

     A. Make a copy of JBoss's default-with-hornet deployment and call it, say, default-with-hornetq-client

     B. Setup this deployment's deploy dir:

          i. Delete ROOT.war (so the deployment of drawer-manager.ear does not complain about ctxPath=/)

          ii. copy drawer-manager.ear

          iii. and unzip deploy.zip

     C. Start JBoss (run.bat -c default-with-hornetq-client)

     D. At this point you will notice netty repeatedly logging its version header in system.log every 3 secs

     E. Invoke the EJB:

          i. unzip webster.zip to a temp dir

          ii. execute webster (webster -host localhost -login)

          iii. this will hand waiting for the response from JBoss, however, the EJB is hung on its call to topicConnection.createTopicSession at line 45 in TopicPublisher.java

     F. At this point you will notice netty repeatedly logging its version header in system.log twice every 3 secs.

Please let me know if you have any problems reproducing. And THANK YOU for taking a look at this.

Cheers,

Bill

PROBLEM SOLVED!!!

I had to remove:

      <config-property>
         <description>The transport type</description>
         <config-property-name>ConnectorClassName</config-property-name>
         <config-property-type>java.lang.String</config-property-type>
         <config-property-value>org.hornetq.integration.transports.netty.NettyConnectorFactory</config-property-value>
      </config-property>

from ra.xml.

The code in HornetQResourceAdapter.java around line 1381 only uses the discovery address if the connectorClassName is null.

I have attached a zip of my hornetq.sar and hornet-ra.rar for others who may encounter this same issue.

Thanks Andy, Clebert & Tim for all your help over the past week or two. Much appreciated!

Cheers,

Bill

Clebert & Tim,

From a user's POV, I don't really think this is a bug. I like Tim's suggestion that a warning from the code when it detects that a connector AND discovery are BOTH defined would be helpful. Most helpful, however would be a blurb in the manual or an example (or both) to show how this should be configured. Don't get me wrong, I enjoyed wandering around in the really nicely written and commented code that is HornetQ (seriously!). But saving another user the week that it took me to grock the HornetQ codebase and debug down to the point where my mis-configuration was causing the problem would be a really good thing. I tried to do my part to this end by posting my final working zipped configuration on this thread.

Cheers,

Bill