Cedric Beust wrote:
>
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Monson-Haefel
>
> > This depends a lot on how your vendor handles clustering of MDBs. The
> > specification you quoted is referring to the two different deployments
> > (enterprise beans) that subscribe to the same destination. With queues,
> > messages are only consumed once. So if you send a message to a
> > queue, only one of the MDB deployments will be able to get it; the message
> won't
> > be available for other MDBs.
>
> Actually, this issue is even more subtle (subtler?) than this. It
> definitely depends on how your vendor distributes JMS. The finest grain you
> can have is the case where the JMS "core" and its destinations can all live
> on different nodes of the cluster. For example, the JMS service is on
> machine A, destination "queue0" is on machine B and destination "topic1" is
> on machine C.
>
> Now, you can further complicate the picture by throwing failure recovery
> into it. This can be addressed in two ways:
>
> - only deploy one instance of the destination and handle failure and
> recovery through smart stubs (and automatic redeployment of the failed
> destination on a different node)
> - deploy several instances of the destinations in the cluster but have only
> one active and all the others dormant
You missed an option - you can have all of them simultaneously active.
> And now the final step: how many redundant MDB's are deployed in a cluster?
> If your MDB is clustered, you expect one instance of it to be present on
> each node of the cluster.
>
> The questions are:
>
> - should all these instances be active? (i.e. connection opened, session
> active and listeners installed)
That is up to the vendor to determine.
> - for all active instances listening to a Queue, how many should receive the
> message?
One.
> - for all active instances listening to a Topic, how many should receive the
> message?
One.
> Phew. I didn't think that just laying out the basic problem would take up
> that much space. As you can guess, answering all these questions can be
> quite lengthy, and once again, it all boils down to the choices your vendor
> made, since basically all the behaviors described above are compliant with
> the JMS and EJB specifications.
I don't believe that duplicate processing of messages sent to MDBs
is a legitimate behaviour. Please show me where in the EJB 2.0 spec
that it says this behaviour is permitted.
What it boils down to is: does your cluster present a "single system image"
in respect of the expected JMS/EJB/MDB behaviour. If not, you should probably
lobby your vendor for a better implementation.
> --
> Cedric
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
--
________________________________________________________________________________
Evan Ireland Sybase EAServer Engineering [EMAIL PROTECTED]
Wellington, New Zealand +64 4 934-5856
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
