[maximilien]

I don't know well topics but what i have understand about them is that messages published before a subscriber (durable or not) creation is never distributed to them, so as we create subscribers dynamically and messages for it can be present before the creation i doubt it's an option for us, is it ?

Sorry for the newbie question ;-)

[andreas_back]

Hello Maximilien,

you could also have a quick look at "Topics vs. Queues" at the following page

     http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jms/design_best_practices.html#1061024

to see if the suggested workaround is feasible for your application.

Best regards,

Andreas

[andreas_back]

Hello Tim,

your posting last week

> Ok, I am looking at this case today.

> ...

> Using a topic should workaround this issue, while I fix it.

left us with high expectations since the point of time when we have to deliver the application is coming closer and our management feels that it has to make a decision.

The best solution would be if we could incorporate a bugfix.

QueueImpl seems to be a central class and from my point of view several other classes are involved in this problem, so an unguided attempt to change the code could have unforseen consequences.

Therefore a rough estimation when a fix might be available in the trunk for testing would be highly appreciated!

Meanwhile, yes, we the start to reimplement the application to use and maintain serveral queues.

Best regards,

Andreas

[andreas_back]

Hello!

While reengineering the serveral moduls of the application to seperate the one queue into different new ones we have found selectors that are used by servlets to pick a special message from the queue:

"ZDSJobId IS NOT NULL AND ZDSJobId='"+jobId+"' AND ZDSDestination IS NOT NULL AND ZDSDestination='DecentralClient'

One idea is to substitute each generated selector by a dynamically generated queue. In the extranet it is unlikely that we have  more than 50 parallel requests to  the servlets and therefore the number of queues would be limited.

Is it a senseful approach to dynamically create a queue before sending the message to the servlet and then to destroy the queue after reading it to eliminate the selectors or shall we design another solution?

By the way, the management has mentioned the point that the system is planned to go live at the beginnig of September and has instructed my to ask if it is realistic that a fix to https://jira.jboss.org/browse/HORNETQ-469 might be available within this timeframe.

With best regards,

Andreas

[andreas_back]

Hello Tim,

yes, the management has decided that we stay with HornetQ unter JBoss!

One central point has been that ActiveMQ when used under JBoss has a reported exception with XA, see https://issues.apache.org/activemq/browse/AMQ-2670. There is a fix for in in ActiveMQ 5.4.0 but this version is not released yet.

And this implies that under the JBoss plattform the HornetQ competitor is extremly weak regarding to quality and obviously also user base in a central messaging enterprise feature.

With best regards,

Andreas

[maximilien]

Hi,

In  our side we were forced to go back on jboss messaging for our production application.

It's a bit slower than hornetq but no messages are trapped. Hope the problem will be solved quickly.

Maximilien

[andreas_back]

Hello Maximilien,

you are lucky. To meet the service level agreements our application needs prefetchsize = 0. And HornetQ provides this by setting the consumer-window-size=0 and therefore is clearly better than JBoss Messaging in this aspect.

After removing the filters in relevant parts we did some testing and 1 1/2 weeks of workload of the productive system have been processed by the migrated system using HornetQ and no messages stayed locked in the queues.

Therefore we are sligthly more optimistic with HornetQ than before.

Thank you for your test case that reproduced the bug!

With best regards,

Andreas

[timfox]

This issue should be fixed in TRUNK now, if you would like to try it out.

[andreas_back]

Hello Tim,

yes, the reproducing example of Maximilien and the MessageHandler version of it are now running against the TRUNK!

Thank you very much!

With best regards,

Andreas

[maximilien]

Hi,

Thanks for the fix, it seems to work for me.

Because this kind of bug is highly dependent of messages/consumers order it's not so easy to affirm that the problem is solved but from now it seems to be good.

Thank you again Tim and good luck Andreas for your project ;-)

Maximilien

[andreas_back]

Hello Maximilien,

thank you for your wishes.

Yes, it is always good to have options. Now we have a version of the application

*     where all selectors on queues have been substituted by different queues and in one case by deleting a message via JMSQueueControl.removeMessages()

*     and on the other hand the original version of the code that will run with 2.2 RC1+.

With best regards,

Andreas

[maximilien]

Have you noticed performance differences between the two options ?

Is it better using one queue with multiple filters or multiple queues without filters ?

Maximilien

[andreas_back]

Hello Maximilien,

the application has slow consumers so we did not see a notable difference in the overall performance.

But selectors have to be evaluated and this consumes time.

With best regards,

Andreas

[timfox]

andreas_back wrote:

Hello Maximilien,

thank you for your wishes.

Yes, it is always good to have options. Now we have a version of the application

*     where all selectors on queues have been substituted by different queues and in one case by deleting a message via JMSQueueControl.removeMessages()

This is the same as having a topic with multiple durable subscriptions with different selectors. HornetQ will treat them the same.