Cedric Beust wrote:
>
> > From: Evan Ireland [mailto:[EMAIL PROTECTED]]
>
> > > - for all active instances listening to a Topic, how many should receive
> the
> > > message?
> >
> > One.
>
> Then how does JMS tell a replicated listener from a regular listener?
It doesn't have to. It is just the same as with shared access to
queues by ordinary JMS clients using listeners. If two clients
simultaneously receive from the same queue, they should not both
get the same message. The MDB case is no different.
> Because based on what you're saying, JMS will magically know what listeners
> should be ignored because they're redundant instances in the cluster.
No. JMS shouldn't deliver the same message twice (or at least if
a message is delivered twice in unusual circumstances the JMSRedelivered
flag should be correctly set).
> > 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.
>
> Not duplicates. The same message, but delivered to all listeners of that
> Topic.
Remember we're talking about a single MDB. Whether you call it
'duplicates' or consider it as undesirable 'redelivery' doesn't
change the fact that it is not the expected behaviour.
> > 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.
>
> That's not the problem. The problem is that once an MDB has started its
> session and is listening to a Topic, it is a JMSListener just like everybody
> else, even if it was deployed as part of a clustering strategy.
An MDB is not an ordinary JMS client. If your MDB has a topic subscription,
the MDB implementation should take care of this. Separate MDBs can subscribe
to the same topic, but a single MDB that is deployed on multiple machines
in a cluster should not receive the 'same' message on multiple nodes (at
least that is not the 'expected' behaviour for MDB). It could be argued that
this kind of multiple delivery is actually useful in some cases, but that
kind of configuration would be proprietary and vendor-specific.
I think that you are assuming that an MDB implementation has to use the
standard JMS interfaces (e.g. connection, session, or the 'application
server' JMS interfaces). It turns out that there is no such requirement,
which is a good thing, as those interfaces were not designed adequately
for load balancing, high availability and scability (thread pooling).
MDB is hard to implement in a clustered environment. I believe that you may
be confusing the implementation issues with the expected behaviour (which by
the way makes no reference to clustering). When a vendor supports clustering,
they should do it in such a way that the expected MDB behaviour is preserved
(i.e. each message is delivered once in 'normal' operation - redelivery being
appropriate in failure recovery situations).
Having said all of that, I expect that we will see some poor implementations
of clustering with MDB.
By the way, I do think this ia a great discussion thread! Let's hope that we
can get a wider discussion going.
________________________________________________________________________________
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".
