Understanding JBoss Messaging and SPOF (Single Point of Fail

[seattle.golfer]

Hi All,

I've been away from JBoss for about 4+ years (working in Weblogic), and am finally coming back home.

I'm trying to get a better handle on JBoss Messaging's clustering capabilities. They way I read the documentation/installation guide, you still need to have a shared database instance. From the 1.4B1 docs, "For a clustered installation it is mandatory that a shared database is available to all nodes in the cluster."

Which (to me) appears to be Single Point of Failure (SPOF). I realize the database itself could be clustered, but still..

Also, additional reading, such as this statement from Tim's (old) blog post (http://blogs.jboss.com/blog/tfox/?permalink=State_of_the_art_clustering_with_JBoss_Messaging.txt) states : "But there's another way we can increase the "durability" of a message without storing it to disk at all, and that's by replicating it in memory between different nodes. If the cluster is well constructed with good hardware, UPS etc then we can reach sufficiently levels of durability for many applications.". This is exactly what I'm after.

So, which is it? Can I cluster a topic without a shared database or not? How about with a local database on each node in the cluster?

That being said, here's the problem I'm trying to solve.. A distributed topic that lives on N nodes. There are a few producers that live on each Node. There are also M consumers that don't care if the topic is clustered or not. Additionally, I don't want a SPOF, nor do I want to mess with a central database with clustering enabled.

Am I chasing a unicorn here? Is this even possible?

[timfox]

"seattle.golfer" wrote:

I've been away from JBoss for about 4+ years (working in Weblogic), and am finally coming back home.

Glad to hear it! :)

I'm trying to get a better handle on JBoss Messaging's clustering capabilities. They way I read the documentation/installation guide, you still need to have a shared database instance. From the 1.4B1 docs, "For a clustered installation it is mandatory that a shared database is available to all nodes in the cluster."

Which (to me) appears to be Single Point of Failure (SPOF). I realize the database itself could be clustered, but still..

Yes, JBoss Messaging 1.x uses a shared database for persistence. If it's not clustered that could provide a SPOF.

JBossMessaging 2.0, which is what we are currently at work on has major improvements in the area of persistence.

We will support:

1) Shared JDBC database - like in 1.x
2) Unshared JDBC database per node (already working in TRUNK)
3) Unshared file based journal per node

For HA we will also support replication between nodes for a "shared nothing" approach.

Also we'll support failover via a shared file sytem (e.g., GFS over a SAN) in the case one is available.

Lots of other great new things in JBM 2.0 including a brand new super fast NIO transport using Apache MINA. (Trustin Lee the author of MINA is now a JBoss employee), and many other features.

Also see JIRA for JBM 2.0 tasks and provisional timescales. We should have a GA released towards the end of the year.

There is also a little bit more info on the jboss labs JBM project page.

JBM 2.0 is the subject of my talk at JBoss World in a couple of weeks. Why don't you come along and find out more?

[timfox]

File based persistence is already done in TRUNK too

[seattle.golfer]

"timfox" wrote:


JBossMessaging 2.0, which is what we are currently at work on has major improvements in the area of persistence.

We will support:

1) Shared JDBC database - like in 1.x
2) Unshared JDBC database per node (already working in TRUNK)
3) Unshared file based journal per node

For HA we will also support replication between nodes for a "shared nothing" approach.

Also we'll support failover via a shared file sytem (e.g., GFS over a SAN) in the case one is available.

Lots of other great new things in JBM 2.0 including a brand new super fast NIO transport using Apache MINA. (Trustin Lee the author of MINA is now a JBoss employee), and many other features.

Awesome! That sounds like an exhaustive feature set! Now the obvious questions.. any chance some of these features can/will be backported to 1.4.x? Also, in your opinion, is what's in source stable enough to start building a solution? i.e do you think the interfaces and such are pretty well fleshed out at this point?

Also see JIRA for JBM 2.0 tasks and provisional timescales. We should have a GA released towards the end of the year.

There is also a little bit more info on the jboss labs JBM project page.

I spent some time browsing JIRA, but can't seem to find the 2.0 provisional timescale. Any chance you can post a link?

JBM 2.0 is the subject of my talk at JBoss World in a couple of weeks. Why don't you come along and find out more?

I just started a new job this week, and doubt I've earned enough creed to justify a trip out so soon. :) Perhaps next year.

Tim, I really appreciate you taking the time to respond. It's good to see the community alive & well post acquisition.

thanks,
Deepak

[timfox]

"seattle.golfer" wrote:
any chance some of these features can/will be backported to 1.4.x?

This is very unlikely - we don't really have the resources for that and it would involve deep changes.

Also, in your opinion, is what's in source stable enough to start building a solution? i.e do you think the interfaces and such are pretty well fleshed out at this point?

Right now, we are deep into development so nothing is ready to use at this point.
We'll be putting out an alpha end of Q1 as per JIRA

I spent some time browsing JIRA, but can't seem to find the 2.0 provisional timescale. Any chance you can post a link?

The dates are printed after the release names on the roadmap:
http://jira.jboss.org/jira/secure/BrowseProject.jspa?id=12310061&subset=-1

Tim, I really appreciate you taking the time to respond. It's good to see the community alive & well post acquisition.

You're welcome :)