how to implement RDBMS persistence?

[mazz]

The JON/RHQ team is currently porting the JON Server from JBossAS 4.2.3 to AS7 (currently working with the latest 7.1.1.Final release). We just found out that it is no longer possible to persist JMS messages to a RDBMS backing store, as was possible in the older app servers. For background, see HORNETQ-887 and the forum thread that discusses this. Suffice it to say, JON used this feature and as of right now the requirement still exists such that we continue to need this feature.

My question is - how hard would it be to implement the RDBMS backing store to AS7's JMS subsystem as mentioned in that forum thread where Clebert says "Finally: It would be possible to write a DBStorageManager.. .however I don't think we want to maintain it.  We may consider if someone finds a real reason besides I want it."?

I assume by that comment that HornetQ is meant to be pluggable in this area, correct? What are the issues to be worked around? How difficult would it be to do this and how long would this effort take if someone in the community offered to do it (considering that community member doesn't know the internals of HornetQ :-)

[ataylor]

Yes it is pluggable but we don't think there is a use case for implementing one. we don't want to maintain it and we wouldnt want it to become the defacto standard persistence engine.

Can you eaplain how and why JON needs the messaging subsytem to be a DB?

[mazz]

To be clear, right now I'm not asking that HornetQ team maintain it or become the defacto standard, which is why I mentioned "community" in my original post.

Here is the use-case.

Today, JON Servers are not required to have any connectivity between each other. For example, it is allowed that firewalls separate the JON Servers from one another, or, its possible that there is a single JON Server in each of your N datacenters, where each JON Server doesn't have connectivity to all other JON Servers in all other data centers. All that is required is that all JON Servers have connectivity to the RDBMS backing store.

Now, a JON Server can send a message in which any other JON Server can pick up that message. Which ever JON Server has the cycles, will pick off the message from the queue and process it. This allows for a bit of load balancing to occur naturally in the JON environment.

This worked fine while running in JBossAS 4.2.3 using the old JBossMQ JMS system. We are porting the JON Server to AS7 (7.1.1.Final specifically) and have found out we will no longer have this capability using the AS7 JMS subsystem.

[EDIT: I would like to note that our usage requires a low-volume of messages - we are not looking to send thousands or even just hundreds of messages per minute - it really is a low volume of messages that are part of our use case]

[ataylor]

To be clear, right now I'm not asking that HornetQ team maintain it or become the defacto standard, which is why I mentioned "community" in my original post.

Once it is available(i.e. in product), even if implemented by the commuity we will have to maintain it.

Today, JON Servers are not required to have any connectivity between each other. For example, it is allowed that firewalls separate the JON Servers from one another, or, its possible that there is a single JON Server in each of your N datacenters, where each JON Server doesn't have connectivity to all other JON Servers in all other data centers. All that is required is that all JON Servers have connectivity to the RDBMS backing store.

ok, fine so far.

Now, a JON Server can send a message in which any other JON Server can pick up that message. Which ever JON Server has the cycles, will pick off the message from the queue and process it. This allows for a bit of load balancing to occur naturally in the JON environment.

This worked fine while running in JBossAS 4.2.3 using the old JBossMQ JMS system. We are porting the JON Server to AS7 (7.1.1.Final specifically) and have found out we will no longer have this capability using the AS7 JMS subsystem.

ok, i have to assume here that JbossMQ load balances by each instance of a queue loading in messages from the database as it needs them (altho i may be wrong here). If this is the case even if we implemented a DB you still wouldnt get this same functionlity, HornetQ load balances by forming a cluster and (re)distributing messages around the different consumers across the whole cluster and using backup servers to deal with server failuire. Even if we did implemented DB persistance it would just be a list of journal records in the database which would be tied to the node (or backup) that wrote them, you would still need to cluster your nodes for server side load balancing.