-
15. Re: Federation support, clustering, fail over, etc.
This comment was posted by Nathan Phelps on jboss-group mailing list. I'm reposting it here to facilitate discussion.
> Nathan, you didn't pay attention to my presentation at
> the jug did you? DP allows us to transform a typed
> signature into a detyped 'invoke' and then we can
> string together some behavior. Replicating
> failover logic, using detyped invoker etc. I expect
> your effort to yield an interesting one way invoker
> that we are missing today.
I paid attention, I promise! However, I didn't understand the breath of what you folks were talking about when you said "dynamic client proxies." When someone says "client proxy" to me, I think "oh, they dynamically create the RMI stubs..." What you guys are talking about goes to a completely different level that I obviously don't quite grasp yet...
I'm just going to have to stop thinking like and "ordinary" Java developer, take the red pill, and starting thinking like the rest of you guys who obviously took yours a while ago! -
16. Re: Federation support, clustering, fail over, etc.
This comment was posted by Bill Burke on jboss-group mailing list. I'm reposting it here to facilitate discussion.
Don't panic. If Marc has faith in you, I have faith in you.
Bill -
17. Re: Federation support, clustering, fail over, etc.
We can learn something here by looking at what's done by current strong MOM/JMS software. MQSeries for instance has queue managers that are essentially JMS servers or the implementation of one. They also have a concept of MQ clusters where two or more queue managers can join in a cluster. At least one or preferrably two queue managers in a cluster are called "Repository" queue managers and they have channels (connections) to all other queue managers. These channels are necessory because repository queue managers have to keep what queues/topics are defined on what queue managers.
If a queue is shared in cluster, that means that a client can connect to any server in that cluster and send a message to that queue and it will get to that queue via channels (connections) to the repository queue managers. You can also have the same queue defined on two different queue manager servers and share them both in the queue. In that way when a message is sent to that queue, by default it is round robined, first goes to one instance and the second message will then go to the second instance and hence load balancing is achieved.
Failover is a completely different problem. No-durable messages can be lost. They are non-persistent afterall for a reason. Persistent or durable messages have to be moved over to an alternate server. They only way of doing this without using native clustering facilities like Windows Advanced server with a shared disk array is to keep messages at a shared point like in a database where even if the OS goes down of one JMS server, the other JMS servers can access those messages from the central message store and take over. This however, makes things quite slow. Software like MQSeries provides failover with native support like Windows Advanced server clustering support or other clustering support. I would leave failover as a secondary objective and concentrate on speed and scalability first.
Sincerely,
Abid