Sorry again. My test had transient failures, as the durable
subscription was not always created before the message was actually
sent, so it was sometimes failing. So I can confirm it works for
cacheLevels of 1, 2 or 3 ...
On Fri, Jul 11, 2008 at 10:13 AM, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> Well, actually, it only works with CACHE_CONSUMER (cacheLevel="3").
>
> On Fri, Jul 11, 2008 at 10:09 AM, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
>> If you add cacheLevel="x", where x = 1, 2 or 3 (CACHE_CONNECTION,
>> CACHE_SESSION or CACHE_CONSUMER) it should work fine.
>> The reason is that the default cache value if CACHE_NONE, which leads
>> to not using a shared connection, and it seems that in such case, the
>> clientId is not set by the spring jms listener for some reason.
>>
>> On Fri, Jul 11, 2008 at 7:27 AM, sandeep reddy <[EMAIL PROTECTED]> wrote:
>>>
>>> Hi Servicemix-guys,
>>>
>>> This seems to be probable bug for new jms:consumer endpoint (for
>>> durable subscription):
>>>
>>> We are using new jms:consumer endpoints in our application for
>>> publish-subscribe using topic. As we are having multiple subscribers we are
>>> specifying unique clientID as part of endpoint configuration. We did some
>>> troubleshooting on our end to identify where could be the actual problem.
>>> Following are the steps we did:
>>> 1) Modified the source code for ActiveMQ to have debug statements in the
>>> setClientID(newClientID) method and updated the jar file in ServiceMix with
>>> custom built version.
>>> 2) On ServiceMix start we see the logs being printed by JMSFlow class
>>> which directly talks to ActiveMQ.
>>> 3) The same logs are not printed during initialization of our
>>> jms-consumer SU. This means that the setClientID() method is never invoked
>>> for ActiveMQ connection. Difference between jms-consumer endpoint
>>> (JmsConsumerEndpoint) implementation and JMSFlow is that the
>>> JmsConsumerEndpoint class is using Spring to interact with ActiveMQ.
>>> 4) We have also browsed through the Spring code and everything seems to
>>> be fine. There is method prepareSharedConnection(Connection connection) in
>>> AbstractJmsListeningContainer class. This method actually sets the clientID
>>> to ActiveMQ connection object.
>>>
>>> code: protected void prepareSharedConnection(Connection connection)
>>> throws JMSException {
>>>
>>> String clientId = getClientId();
>>> if (clientId != null) {
>>> connection.setClientID(clientId);
>>> }
>>> }
>>>
>>>
>>> jms:consumer configuration:
>>>
>>> jms:consumer service="up:DirectorConsumerService"
>>> endpoint="directorConsumerEndpoint"
>>> targetService="up:DirectorConsumerService"
>>> pubSubDomain="true"
>>> clientId="Director"
>>> subscriptionDurable="true"
>>> destinationName="updateUserProfileTopic"
>>> connectionFactory="#connectionFactory"
>>> messageSelector="userPrincipals LIKE
>>> '%sandeep2%'"/>
>>>
>>> 5) So, this method should execute before executing
>>> org.apache.activemq.ActiveMQConnection.checkClientIDWasManuallySpecified().
>>> And we noticed that preparedSharedConnection is not invoked.
>>>
>>> 6) And that leads to throwing JMSException:
>>>
>>> javax.jms.JMSException: You cannot create a durable subscriber without
>>> specifying a unique clientID on a Connection
>>> at
>>> org.apache.activemq.ActiveMQConnection.checkClientIDWasManuallySpecified(ActiveMQConnection.java:1142)
>>> at
>>> org.apache.activemq.ActiveMQSession.createDurableSubscriber(ActiveMQSession.java:1066)
>>> at
>>> org.springframework.jms.listener.AbstractPollingMessageListenerContainer.createConsumer(AbstractPollingMessageListenerContainer.java:429)
>>> at
>>> org.springframework.jms.listener.AbstractPollingMessageListenerContainer.createListenerConsumer(AbstractPollingMessageListenerContainer.java:216)
>>> at
>>> org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:297)
>>> at
>>> org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:254)
>>> at
>>> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:871)
>>> at
>>> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:811)
>>> at java.lang.Thread.run(Thread.java:595)
>>>
>>> Above findings seem to point to bug in JmsConsumerEndpoint. Please review
>>> it.
>>> We need to use new jms-endpoint as we require "messageSelector" which is not
>>> possible with jms:endpoint (old).
>>>
>>> Please help.
>>>
>>> Sandeep
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Probable-BUG-for-new-jms-endpoints-tp18396993p18396993.html
>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
