[ataylor]

and for outbound connections it uses the CF defined in jms-ds.xml (or any other *-ds for that matter)

[jmihalich1]

  <made some edits below>

  OK, I see the hookup now.  The invoker-proxy-binding called message-driven-bean, which I have annotated in my MDB code, links to the hornetq resource adapter.

  Also, if I need to publish messages from within the MDB, which I do (outbound), the jms-ds.xml file also has the JmsXA connection factory defined, which hooks up with my MDB transaction.

  The connection factories defined in hornetq-jms.xml are only for normal producers/consumers that are not linking through the resource adapter.

  Joe

[clebert.suconic]

Correct!

[clebert.suconic]

If you don't need strict ordering (after redelivery), you would have a better throughput on keeping the cache on the client.

It won't be proabably that of a big deal with MDBs since MDBs are slow anyway (as you need a single TX/sync on the DB and TX manager or whatever for each message received), and you will be using inVM calls so network latency wouldn't really apply here.

but keep this on your mind.. don't use consumerWindowSize=0 if you don't need to. Ordering will be respected with consumerWindowSize>0 as long as you don't have redeliveries.

[jmihalich1]

  Thanks for the help guys.  I got through all my performance tests now.

  Thanks,

  Joe

[jimmy.hui]

Sorry to hijack this thread, but is there a way to configure hornetQ to have strict ordering on rolled back messages?

For example, Send MSG1, MSG2, MSG3. MSG1 will rollback and due to a redelivery delay of 5 seconds, the MDB does not consume any messages until those 5 seconds have past and then retries MSG1?

So the result would be something like: MSG1, 5seconds, MSG1, 5seconds etc. We require strict ordering of messages even on failures.

I can achieve this by setting the consumerWindowSize annotation on the MDB and setting it to 0 and setting maxSessions to 1 so only 1 consumer is present and setting maxPoolSize to 1 but i have to set the redelivery delay to 0 to force a strict order in message processing.

We could work with this but it obviously causes a lot of thrashing on the cpu, trying to process the same message that will probably continually roll back. So is there a way to set up a redelivery delay while also enforcing strict ordering?

Cheers,

Jimmy

[clebert.suconic]

There's a feature request for this already:

https://jira.jboss.org/browse/HORNETQ-424

[clebert.suconic]

Why don't you add your voting on it?