4 Replies Latest reply on Jan 30, 2007 12:41 AM by byorn

    JBoss JMS vs. Home-grown scaling solution... Which is better

    jhilgedick

      All,

      I could really use some help on the following question - I need to figure out if JMS in a clustered environment is really the solution to my problem...

      I have an application that is deployed to a number of servers in a jboss cluster. I also have a bunch of clients that are writing to a jms queue in the cluster - they are writing (producing) these messages very quickly. My understanding is that in a jboss cluster, the queue isn't really replicated (available) across all servers in the cluster - which means that every client (producer) gets its jms "message" piped to a *single* server in the cluster. Is that correct?

      My understanding is that if the "designated" jms server goes down, another node in the cluster will "take its place". Is that correct? If this is correct it means that as I scale up the number of clients (producers), they are all going to be trying to communicate with the one *single* designated jms node. Is that correct?

      It seems to me I'd be better off by creating a servlet in my application that is replicated across all nodes in the cluster - and this servlet puts the messages into a db table (directly or through hibernate, etc). This is what JBoss JMS does under the covers *anyway*, isn't it? It's how JBoss makes the messages persistent, right?

      Then I could have another servlet deployed on *another* cluster of servers. These servlets would "poll" the db where the messages were written (by the nodes in another cluster), attempt to mark them as "consumed" in the db and return them to the caller (consumer) if they are the one that "got the message". I realize that polling isn't the greatest solution in the world - but we can always add more nodes to the "read" cluster and space the polling...

      Wouldn't something like this scale better than JBoss JMS clustering? Why not? It seems like JBoss's JMS solution is great for failover - but that it just doesn't scale...

      Please show me the error of my ways...

      Thanks very much!

      -john

        • 1. Re: JBoss JMS vs. Home-grown scaling solution... Which is be
          genman

          Assuming you have a single DB, you're making the center of the "hub" the DB. It becomes the same architecture.

          Remember, the first rule of optimization: Don't do it. The second is: Don't do it yet.

          • 2. Re: JBoss JMS vs. Home-grown scaling solution... Which is be
            jhilgedick


            Quoting Genmen: "Assuming you have a single DB, you're making the center of the "hub" the DB. It becomes the same architecture."

            I agree with you on this - it is moving the bottleneck to the DB but... all this talk about creating complex scalable applications by using an architecture that allows you to throw more machines into different parts of the cluster... it isn't ALL hogwash (maybe you think it is?)... Let's *assume* that I can set up a number of synchronized dbs (I'm not a db expert), isn't my argument still valid? Won't a homegrown solution for inserting records into a db through a servlet pool on multiple machines out-perform most (if not all) JMS implementations?

            • 3. Re: JBoss JMS vs. Home-grown scaling solution... Which is be
              genman

              In terms of performance, many JMS implementations don't use relational DBs but use local storage. Some do "buddy replication" over the network, and require no disks for "persistence". These probably would out-perform your solution.

              Anyway, by the time you finished your custom solution, it's likely JBoss Messaging 1.2 with full clustering would be out.

              • 4. Re: JBoss JMS vs. Home-grown scaling solution... Which is be
                byorn

                Yeah No point reinventing the wheel also.