Sorry if you've said this already (it rings a bell but I couldn't find it
when I scanned this thread), but why is the AuthorizationInterceptor saying
that your onMessage() method is disallowed?
EJB Invocation failed on component TestMessageBeanLow for
method public void de.adesso.tma.test.ejb.
ic
Well, it's not my job to figure out who is responsibe for this error, as long
as it is not my fault. I have to evaluate products for my customer.
Consider also there is another difference between the WildFly/ActiveMQ and
WebLogic/ActiveMQ configuration. In the Wildfly configuration, the ActiveMQ
r
Hi Tim,
in this case it is expected, because I wanted to provoke an exception, which
is thrown by the container and not by the MDB code. I just wanted to see if
the message is redirected in this case to the DLQ. But the effect is the
same as when the exception is thown by /onMessage()/. The messag
OK, since this works in one container (WebLogic) and not another (WildFly) -
my suspicion is with the container handling of the exception.
Turning up the logging on org.apache.activemq.ActiveMQSession to DEBUG on
the JMS client should cause the following to get logged:
* ... Transaction Commit :.
To answer this question you may read chapter "13.6.1 Bean-Managed Transaction
Demarcation" of the specification "Enterprise JavaBeans 3.1, Final Release,
November 5, 2009".
Message driven beans with bean-managed transaction demarcation are not
called with an active transaction. The MDB may use the
Agreed - the critical thing here is to figure out what's happening with the
rollback and/or message state and get it fixed.
Actually, while trying to track down semantics of EJB and JTA, I opened the
API docs for createSession() here:
https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html
One add on:
I think, rolling back the user transaction cannot work here, because the
user transaction has not been started by the container. So the container
doesn't recognize this rollback. So the only way to tell the container, that
the message cannot be processed is by throwing an exception.
Hello artnaseef,
you understand it correctly, the messages are only redirected, when I use
container managed transactions and I set the transaction to be roll-backed
calling the method /MessageDrivenContext.setRollbackOnly()/.
When I use bean managed transactions, the transaction is roll-backed c
Do I understand correctly - messages go into the DLQ when "container managed
transaction handling is used" and do not do so when the same is not used?
If so, what is managing the transactions? Is it possible that the
transactions just never rollback after the MDB throws an exception? In
other wo
I've never used MDBs, but I would expect DUPS_OK_ACKNOWLEDGE mode to use
CLIENT_ACKNOWLEDGE mode under the covers. You could test that by setting a
breakpoint in your MDB's body (before whatever throws the exception) and
checking that the dequeue count doesn't increase until you resume.
You could
One more add on:
Also the EJB 3.1 specification is a bit unclear how to handle message
acknowledge with bean managed transactions:
/*5.4.15 Message Acknowledgment for JMS Message-Driven Beans*
JMS message-driven beans should not attempt to use the JMS API for message
acknowledgment. Message ackno
Hello Tim,
thanks for your answer! Well, the other possibility is the acknowledge mode
/Dups-ok-acknowledge/. I tried this without success. I also tried to
rollback the user transaction in the MDB instead of throwing an exception
with both acknowledge modes. I don't get any redeliveries, nor are t
What acknowledgement mode are you using? If it's AUTO_ACK, I'd expect that
you've already acknowledged the message when the exception is thrown, which
would make this expected behavior, but I'd expect you could use a different
ack mode to get the behavior you want.
On Mar 11, 2016 7:27 AM, "THMayr
13 matches
Mail list logo
