[
https://issues.apache.org/jira/browse/OPENEJB-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15232438#comment-15232438
]
Romain Manni-Bucau commented on OPENEJB-2127:
---------------------------------------------
Hi Jacek,
it is due cause the listener (MDB) starts in the resource adapter pool
(ActiveMQ behavior). I guess it should get fixed in ActiveMQ itself cause of
org.apache.activemq.ra.ActiveMQEndpointWorker#ActiveMQEndpointWorker (the Work
instance created there).
A "polling" strategy (but a bit fragile) can be to check logs with a custom
appender releasing a latch for instance on
org.apache.activemq.ra.ActiveMQEndpointWorker slf4j logger:
{code}
if (connecting.compareAndSet(true, false)) {
if (LOG.isInfoEnabled()) {
LOG.info("Successfully established connection
to broker [" + adapter.getInfo().getServerUrl() + "]");
}
} else {
LOG.error("Could not release connection lock");
}
{code}
Once these loggers are called there is at least one consumer.
That said ActiveMQ could have a "synchronous" start option easily from their
resource adapter code.
> Jms consumers registered after test is started
> ----------------------------------------------
>
> Key: OPENEJB-2127
> URL: https://issues.apache.org/jira/browse/OPENEJB-2127
> Project: OpenEJB
> Issue Type: Bug
> Components: tests
> Reporter: Jacek Obarymski
>
> Hi,
> W use OpenEJB for integration testing (with use of the ApplicationComposer
> JUnit runner).
> We've observed that sometimes JMS consumers are registered after the test is
> started.
> If the app under test, listens on a JMS topic, then the message is
> effectively lost (the app never receives it) and the test fails. This happens
> occasionally on slower machines.
> This is because the test is started before the app is fully deployed with all
> JMS consumers registered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
