JBoss message persistence ...

[pasalic.zaharije]

Hi,

Is there any way to configure message persistence so that messages will not goes directly to DB, but to go trough in-memory buffer, and only if that buffer overflows, it will goes to DB? Our system use ORACLE db for persistence, but every message will goes to DB than it will be read (even if we use message bean to read message). Is there any configuration so that we can reroute messages to in-memory buffer, and if that buffer is full, than we can use persistence?

Note, we MUST use JBOSS 4.2.2 (and we are currently using JBossMessaging-1.4.0SP3).

Thanks.

[clebert.suconic]

We page Messages to the DB when they reach certain parameters (even NonPersistentMessages):

http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.2.GA/html/configuration.html#conf.destination.queue.attributes.paging


But if a message is set to *persistent*, it means it aways goes to the Database. If you don't want the message on the DB, and if you could eventually loose messages in case of a failure just use NonPersistentMessages.

[amar.trnka]

Hi Clebert,

Is there any option in JBoss to save non persistent messages to database while JBoss is shutting down but in the order that messages were sent do the queue ?

For example I've set FullSize destination paging parameters on 1000 and the queue is empty and stopped. I send 3000 messages to the queue. First 1000 messages are in the queue (memory), and remaining 2000 are in DB. When I shutdown JBoss I manage to save these 1000 messages to DB by resending them to queue as persistent messages. The trick is they are saved into the database after 3000th message. Out of order saving messages is not an option.

I need help if anything can be done to resolve this problem, or I need confirmation that JBoss can't save messages to the DB in order they are initially received.

[clebert.suconic]

That doesn't guarantee durability on your persistent messages.


What if someone pull of the energy plug, kill -9 or a VM Crash?


Shutdown is actually the safest of all of these events.


It's simple.. or you can afford loosing messages, on which case you simply use NonPersistentMessages, or you can't.. on which case you *need* to persist them on the DB.