JBossDeveloper

Tim Fox wrote:

 

And HQ also supports shared file system failover same as ActiveMQ which does not require copying. No difference from ActiveMQ

So what would you suggest for the situation when there is no shared filesystem? ActiveMQ can use MySQL cluster with http://activemq.apache.org/jdbc-master-slave.html in this case (I know that it is slow, but it works)...

Leos Bitto wrote:

 

Tim Fox wrote:

 

And HQ also supports shared file system failover same as ActiveMQ which does not require copying. No difference from ActiveMQ

 

So what would you suggest for the situation when there is no shared filesystem? ActiveMQ can use MySQL cluster with http://activemq.apache.org/jdbc-master-slave.html in this case (I know that it is slow, but it works)...

We don't support JDBC? Why? Like you say because it is very slow. If there's a big demand for it, we can consider implementing it. But as yet, I haven't seem much (if any) demand, apart from this thread.

One of the design decisions of HQ is to avoid a single point of bottleneck like a database. One of the big criticisms of JBoss Messaging was that it used a database for persistence.

It goes to show, you're damned if you do, and you're damned if you don't.

On balance I think most people are happy we don't use a Db any more. But of course, you'll always still find a minority who are unhappy whatever you do

I'd rather work on satisfying customer requirements without a db. Like I say, encapsulate the issues in a JIRA and we'll deal with them.

Tim Fox wrote:

 

Leos Bitto wrote:

 

 

So what would you suggest for the situation when there is no shared filesystem? ActiveMQ can use MySQL cluster with http://activemq.apache.org/jdbc-master-slave.html in this case (I know that it is slow, but it works)...

We don't support JDBC? Why? Like you say because it is very slow. If there's a big demand for it, we can consider implementing it. But as yet, I haven't seem much (if any) demand, apart from this thread.

 

One of the design decisions of HQ is to avoid a single point of bottleneck like a database. One of the big criticisms of JBoss Messaging was that it used a database for persistence.

 

It goes to show, you're damned if you do, and you're damned if you don't.

 

On balance I think most people are happy we don't use a Db any more. But of course, you'll always still find a minority who are unhappy whatever you do

 

I'd rather work on satisfying customer requirements without a db. Like I say, encapsulate the issues in a JIRA and we'll deal with them.

It seems that you misunderstood my message - I do believe that it would be nice if there would be a simple solution for low-end messaging clusters (without shared filesystems), much more simple than using a clustered database. I think that most people use the clustered databases as a hack, simply because that is the only available solution of this situation. Maybe that the possibility to resynchronize a failed messaging server node back to the cluster without the outage of the remaining node could be good enough - so let's see how that gets implemented before filing another JIRA issues...

Leos Bitto wrote:

It seems that you misunderstood my message - I do believe that it would be nice if there would be a simple solution for low-end messaging clusters (without shared filesystems), much more simple than using a clustered database.

That's exactly what HornetQ is supposed to be providing. What am I missing here?

Issues like resync a live node to a backup (which as I noted before, ActiveMQ does _not_ provide) are known issues, already have JIRA issues, and are on the roadmap.

Is there anything other than that, you think is lacking? If we agree on this then JIRAs can be created...

When the support for automatic resync of live node to backup node in failover scenario can be expected?