«

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

theRat wrote:

> 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...

I don't know anything much about JMS or the JBoss implementation, but it seems
odd to me that unordered (but otherwise reliable) message delivery shouldn't be
available as an option. If totally reliable ordering of messages is not
required, then I see no need for such centralised queue handling. Maybe
there's an option you can find to weaken the guarantees provided by JBoss, and
thus allow more replication ?

If not, then one approach would be to have several (a fixed number) of
independent JMS queues (each with failover, etc), and for clients to select a
queue for each message on a more-or-less arbitrary basis. (Randomly, perhaps).

-- chris

theRat wrote:
> 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?

????

JMS is an API.

JBoss MQ and JBoss Messaging are two products.

> 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...

You want scalability ?

Then one thing is for sure: you can forget about *polling* the
database !

Arne