JBossDeveloper

no the name and address should be different, HornetQQueue("abo", "aboFezAdmPre", true, null)

HornetQQueue("abo", "aboFezAdmLive", false, null):

javax.jms.InvalidDestinationException: Queue abo does not exist

        at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:312)

        at org.hornetq.core.client.impl.ClientSessionImpl.internalCreateConsumer(ClientSessionImpl.java:1800)

        at org.hornetq.core.client.impl.ClientSessionImpl.createConsumer(ClientSessionImpl.java:478)

        at org.hornetq.core.client.impl.ClientSessionImpl.createConsumer(ClientSessionImpl.java:444)

        at org.hornetq.core.client.impl.DelegatingSession.createConsumer(DelegatingSession.java:189)

        at org.hornetq.jms.client.HornetQSession.createConsumer(HornetQSession.java:537)

        at org.hornetq.jms.client.HornetQSession.createConsumer(HornetQSession.java:383)

        at org.hornetq.jms.client.HornetQSession.createConsumer(HornetQSession.java:358)

        at org.hornetq.ra.HornetQRASession.createConsumer(HornetQRASession.java:1081)

        at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.createConsumer(AbstractPollingMessageListenerContainer.java:501)

        at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.createListenerConsumer(AbstractPollingMessageListenerContainer.java:223)

        at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:307)

        at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:243)

        at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1058)

        at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1050)

        at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:947)

        at java.lang.Thread.run(Thread.java:662)

Caused by: HornetQException[errorCode=100 message=Queue abo does not exist]

        ... 17 more

HornetQQueue("abo", "aboFezAdmLive", true, null):

javax.jms.JMSException: Can not create consumer for temporary destination HornetQQueue[aboFezAdmLive] from another JMS connection

        at org.hornetq.jms.client.HornetQSession.createConsumer(HornetQSession.java:379)

        at org.hornetq.jms.client.HornetQSession.createConsumer(HornetQSession.java:358)

        at org.hornetq.ra.HornetQRASession.createConsumer(HornetQRASession.java:1081)

looks like spring/core and jms arent mixing well, spring is using the adress not the queuename for some reason, any ideas, also it should be HornetQQueue("abo", "aboFezAdmPre", false, null) as its not temporary

But the exception comes directly from HornetQ - Spring uses the name as created in the resolver code:

HornetQQueue("abo", "aboFezAdmLive", false, null);

I do not get this...

Tomorrow I will try to remove the binding query check. When I changed the "response.exists" boolean to true, the listener could be started successfully...

Hi Andy

Let me share our experiences so far. We have got a running scenario know - usimg JMS on both ends the producer and consumer. The producer sends to a core address and the consumer consumes from a core queue! The hornetq Destination is created case you proposed using the address and The specific queue Name. This should work (in theory)  but it does Not.

In HornetQSession the consumer is created by calling dest.getSimpleAddress(). So the queue name is not taken. When changing this to new SimpleString(dest.getName()) the listener is created!

From our point of view this seems to be a bug. The queue name must be used there because it should listen to a queue mapped to an address.

What do you think?

Thanks for supporting!!!

Marek

Hi HornetQ Devs,

in order to quickly determine whether we hit an implementation bug or whether our current understanding of HornetQ concepts and implementations is still not correct, I'd like to summarize our findings based on what Marek already wrote. Please correct, if something is wrong!

• each HornetQ core queue has exactly one address
• the same address can be used/bound to multiple queues
• using the core API one has to produce using an address, but consume using the queue name
  • org.hornetq.api.core.client.ClientSession#createProducer(SimpleString address)
  • org.hornetq.api.core.client.ClientSession#createConsumer(SimpleString queueName)
• according to our understanding the JMS client API/Impl is meant to work on top of the core API/Impl and should use the above interfaces according to the core interface semantics/description
• HornetQSession implements javax.jms.Session and as such offers the following signatures
  • createProducer(Destination destination)
  • createConsumer(Destination destination)
• it should properly delegate to the underlying Core API/Impl (the wrapped org.hornetq.api.core.client.ClientSession)
• looking at the producer side everything is as expected
  • the core client producer is created using the destination's address
  • ClientProducer producer = session.createProducer(jbd == null ? null : jbd.getSimpleAddress());
• looking at the consumer side we found the following weird:
  • First point is the binding query, which is a lookup using the address. As one address may be used for multiple queue (names) we would expect not only response.isExists() to be checked, but rather whether dest.getName() is in the list of queue names of the binding query response object (getQueueNames()).
  • Second and more important point is that we would expect any call to ClientSession#createConsumer(SimpleString queueName) passing the queue name and not the address, but currently it reads like:
    • consumer = session.createConsumer(dest.getSimpleAddress(), coreFilterString, false);
  • whereas we would expect it to read as:
    • consumer = session.createConsumer(new SimpleString(dest.getName()), coreFilterString, false);

Is this a bug? Maybe this problem was not unveiled as with JMS there is normally a 1:1 relation between queue name and queue address (not taking the automatically prepended address prefix "jms.queue" into account).

In our use case we intentionally avoid the prefix (using a custom Spring DestinationResolver implementation as suggested by Andy) in order to be able to "unlock" the HQ core feature of sending a message copy to multiple queue destinations. We produce messages using a JMSTemplate and receive messages using a Spring DMLC.

Without the above fix either the binding query OR the actual consumer creation fails. If we correctly create the queue object instance with the shared address and the specific queue name, the consumer creation fails (as the address is used instead of the name) and if we "fake" the address to be the same as the name than of course the binding query fails as their is no address corresponding to the queue name.

Could the above fix have any negative side effect? Shall we raise a JIRA?

Thanks,

   Eric

I have created https://issues.jboss.org/browse/HORNETQ-1079 to track this. Hope this is ok for you.

Marek

thanks we will investigate and report back

ok, i understand what the issue is and agree we should change it, I will need to run th etest suite to make sure it doesn't break anything.

In the mean time, could i ask you to clone our github repo, build the master branch after applying your fix  and test it in your environment

Hi Andy,

thanks for your quick reply! I downloaded a zip from the github's hornetq master branch, installed maven 3.0.4, used a separate Maven settings file pointing to a fresh repo, run clean install. All tests are passing. I then applied the discussed change and rerun clean install. Normal unit tests are still passing:

[INFO] HornetQ JMS Client ................................ SUCCESS [1.460s]

Are there any specific maven profiles I should activate for additional test coverage?

Meanwhile Marek uploaded a patched jms client binary to our internal Maven repository so that we can run a couple of system integration tests as well. It is a change in a very central place on a common code path, so we understand that this needs to be carefully tested. We will keep you updated regarding the results of our system integration tests we will run tomorrow.

Thanks,

  Eric

Sorry, one answer was nicely provided in the root directories' README.md: So I will quickly rerun with -Phudson-tests

we currently have a few failures in the master branch so don't worry to much about that

Hmm, at least all builds finished successful. ;-)

It took quite some time, but this were the results:

[INFO] HornetQ Unit Tests ................................ SUCCESS [1:11.860s]

[INFO] HornetQ JMS Tests ................................. SUCCESS [1:52.179s]

[INFO] HornetQ Integration Tests ......................... SUCCESS [59:07.058s]

Looking at individual test results there are quite a few errors in JMS and Integration tests (as you expected), but at least unit tests finished 100% successful.

Finally the integration test (using an embedded 2.2.16.Final HornetQ instance) also passes successfully now.