-
1. Re: how to implement RDBMS persistence?
ataylor Sep 24, 2012 12:29 PM (in response to mazz)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?
-
2. Re: how to implement RDBMS persistence?
mazz Sep 24, 2012 12:52 PM (in response to 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.
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]
-
3. Re: how to implement RDBMS persistence?
ataylor Sep 24, 2012 1:13 PM (in response to 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.
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.