You're welcome. Some of these bugs are hard to find unless you're deep in
the trenches.
So It looks like in AutoConfig.java, it sets clientId to the deploymentId
by default (which is where it's getting the classname from).
As a workaround, I set this sysprop:
openejb.deploymentId.format = {host}/{appId}/{ejbJarId}/{ejbName}
and changed the hostname in each of the tomcat server.xml to be the
hostname of the box. Whahala, unique subscription IDs and broadcast
messages are working now. We'll use this workaround for now, but I'll code
up a long term solution.
On Wed, Sep 11, 2019 at 10:45 AM Jonathan Gallimore <
[email protected]> wrote:
> That is super interesting - thanks for the write up. I'm not aware of
> anything in the spec about the client id - that sounds like something
> specific to our implementation. @Richard Monson-Haefel - any thoughts on
> that?
>
> Jon
>
> On Wed, Sep 11, 2019 at 4:39 PM Jonathan S. Fisher <[email protected]>
> wrote:
>
> > So we found an interesting bug in TomEE when clustering multiple
> > instances. We use MDBs and Topics to keep caches loosely coherent in our
> > cluster and reduce the number of trips to the database. If you run the
> same
> > MDB on multiple TomEE instances listening on the same topic, you would
> > expect that every TomEE instance gets a copy of a message sent to the
> > topic.
> >
> > Currently this isn't happening, the Topic will behave like a Queue: the
> > message will only be sent to one of the instances.
> >
> > It looks like this stems from the way TomEE is generating clientIds for
> > MDBs when it's not specified explicitly. JMS Requires all listeners on a
> > topic have a unique client id. TomEE uses the MDB classname as the
> > clientId, leading to a name collision.
> >
> > I'm unaware of a requirement in the spec that says what clientId to use
> on
> > MDBs has to be the java classname but I've been wrong before.
> >
> > I plan on fixing this by having tomee prepend the connection id to the
> > client id, or prepend a random UUID.
> >
> > cheers,
> > --
> > Jonathan | [email protected]
> > Pessimists, see a jar as half empty. Optimists, in contrast, see it as
> half
> > full.
> > Engineers, of course, understand the glass is twice as big as it needs to
> > be.
> >
>
--
Jonathan | [email protected]
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
full.
Engineers, of course, understand the glass is twice as big as it needs to
be.
