[timfox]

If you could produce just a simple, single, self contained JUNit test or java main class that does something like:

1) Send some messages with filters

2) Consume them

Then we can inspect whether there is anything left in memory at the end.

Honestly, we're not trying to be awkward here, it's just we have such limited resources, and we have to deal with a lot of enquiries and issue reports and simply don't have the time to import/learn X number of tools.

If there is really an issue here (and I don't doubt there might be), it should be simple to reproduce in a basic test case

[ebuddy]

Hi Tim,

I have found the problem, it was in my configuration after all! The following configuration was causing the issue:

<queue name="eBuddy.events">

            <address>eBuddy.events</address>

            <durable>false</durable>

        </queue>

        <queue name="eBuddy.events.SECURITY.login.success">

            <address>eBuddy.events</address>

            <filter string="type = 'SECURITY' AND success = true"/>

            <durable>false</durable>

        </queue>

        <queue name="eBuddy.events.SECURITY.login.failure">

            <address>eBuddy.events</address>

            <filter string="type = 'SECURITY' AND success = false"/>

            <durable>false</durable>

        </queue>

        <queue name="eBuddy.events.TEST">

            <address>eBuddy.events</address>

            <filter string="type = 'TEST'"/>

            <durable>false</durable>

        </queue>

I was acking the three other queue but obviously not the eBuddy.events queue since I only use that for writing. Maybe I should have used a divert for this? Anyway, I am glad the issue is out of the way so we can move forward with HornetQ. In the process I got to know more of the internals of HornetQ so that's also great. We are currently using HornetQ only for a small part of our system but I am evaluating it to make it a central component in our architecture here at eBuddy, that's why it was important for me to know that the filters work. Ultimately we are aiming to do 250K messages per second in peak time (we are currently processing about 30K per second at peak, not using MOM)

Thanks for the quick replies!

Kind regards

Joost

[timfox]

Glad to hear it

BTW... if you want the highest throughput using 2.1.0, there are some new settings - take a look at the performance section in the user manual.

2.1.0 Also comes pre-configured with a new ThroughputConnectionFactory which has these settings set