Traceable message queue persistence?

[tmarks]

I am still relatively new to JBoss; have been looking for a 'traceable persistence' mechanism that proves a message

got onto a queue and was processed.

To be more specific, I want to see (In the database) the messages that came into the ESB queue.

I am aware of the JBoss Messaging persistence (provided by the application jboss-messaging.sar) and the ESB  'Message Store' mechanism.

How does JBoss Messaging persistence work? Does it apply to ESB queues?

Using either mechanism, will I be able to see messages in the database after they are processed? (or are they auto-deleted?)

Any help/insight/suggestions appreciated.

System: jboss-eap-4.3, Jboss ESB 4.8

[ryanhos]

1.)  Proving that a message got onto a queue:  If producer.send() returns, it's on the queue.  That's part of the client contract of JMS.  If you really need fine-grained auditing of queue deliveries, the ESB has an interceptor that logs all ESB-aware queue send and receive events.  This interceptor could be extended to create a persistent log of message activity.  Check jbossesb-properties.xml for how to configure and enable the trace interceptor.

2.)  JBMessaging persistence is only to support the framework, not for your application to do auditing on.  Messages are deleted after successful processing.  It is not considered a public part of the API and may change between versions w/out warning or consideration from the JBM developers.  (Okay, so that's a dumb statement, as it seems that JBM development has ceased, in favor of HornetQ.)

3.)  The JBMessaging persistence mechanism applies to all administratively defined queues on a system, including those of the ESB.  The ESB doesn't do any super-special integration with JMS.  It's just a normal client.  It puts it's JMS messages on one leg at a time, just like the rest of us.  (Does JBM persistence apply to temp queues, anyone?)

4.)  Use the ESB's message store if you really want to store messages.  The ESB does not delete these messages after processing.  However, you'll need to pull them out and deserialize them just to get any useful information about them.  This is likely to be a performance issue and a bad idea in general.

5.)  Why not just perform your auditing on the result of your message processing?  If each message processes an invoice, why not just count how many processed invoices are in the DB in a given time window?  If there's no persistent result of processing the message, why are you doing it in the first place?  And, if there really is no persistent result at the moment, but it's imperative that your company be able to track the activity, then perhaps you should audit-log into a persistent store that does not require 3rd party libraries to use.  Eventually someone from another dept will want to read your data and you'll have to sheepishly explain tha they must use the JBoss ESB libraries to deserialize the messages and pick through them one at a time.  And they'll be thrilled to have to recompile their audit-log-reader when you upgrade to JBoss ESB 4.9 and the message serialization scheme changes (I don't know that it does, but it is a foreseeable consequence).

[tmarks]

Ryan -

Thanks for sharing this useful information with a relative newbie.

1) I was not aware of the Interceptor. Will definitely investigate. (wonder if its similar to the 'EchoRouter' action?)

2) Roger that.

3) I have not come across the term 'temp queues'.

Are these queues that are defined within an applications jboss-esb.xml file?

4) Since my original posting, I changed the JBoss datastore from Hypersonic to Oracle.

After testing the 'Message Store' mechanism against Oracle, I agree that it will not be agood option.

I will create custom actions to write transactions to a custom table, which will help with traceability/auditing.

5) Roger that.