You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by THMayr <Th...@adesso.de> on 2016/03/11 11:58:56 UTC

Message not redirected to DLQ when exception thrown by MDB

Hi,

I deployed a MDB on WildFly 10.0.0. An external ActiveMQ server is
configured in WildFly with the ActiveMQ resource adapter.

When the method /onMessage()/ of the MDB method throws a runtime exception,
the message is not redirected to the DLQ. This works only, when container
managed transaction handling is used, a transaction is required, and I set
the transaction to be roll-backed by the container when the exception occurs
(MessageDrivenContext.setRollbackOnly()). In this case no exception is
thrown to the container.

When I do the same in WebLogic it works!

I cannot use container managed transactions in my MDB. So is there a way to
redirect the message to the DLQ when processing fails?

Thomas



--
View this message in context: http://activemq.2283324.n4.nabble.com/Message-not-redirected-to-DLQ-when-exception-thrown-by-MDB-tp4709187.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message not redirected to DLQ when exception thrown by MDB

Posted by THMayr <Th...@adesso.de>.
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 message is not
redirected to the DLQ.

Regards Thomas



--
View this message in context: http://activemq.2283324.n4.nabble.com/Message-not-redirected-to-DLQ-when-exception-thrown-by-MDB-tp4709187p4709554.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message not redirected to DLQ when exception thrown by MDB

Posted by Tim Bain <tb...@alumni.duke.edu>.
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 void de.adesso.tma.test.ejb.TestMessageBean.onMessage(javax.jms.Message)
of bean: TestMessageBeanLow is not allowed
        at
org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:134

Is that expected?

Tim
On Mar 16, 2016 8:28 AM, "THMayr" <Th...@adesso.de> wrote:

> 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
> resource adapter is involved and with WebLogic the connection is made by
> the
> ActiveMQ JNDI connection factory.
>
> I have no idea how to turn on logging or tracing. But what I can see on the
> WildFliy console is, that WildFly throws an exception and afterwards the
> ActiveMQSession throws an exception caused by the first one. In this case I
> configured the MDB so, that the container is not allowed to invoke the
> method /onMessage()/:
>
> 08:31:53,279 ERROR [org.jboss.as.ejb3.invocation] (default-threads - 7)
> WFLYEJB0034: EJB Invocation failed on component TestMessageBeanLow for
> method public void de.adesso.tma.test.ejb.
> ic void de.adesso.tma.test.ejb.TestMessageBean.onMessage(javax.jms.Message)
> of bean: TestMessageBeanLow is not allowed
>         at
>
> org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:134)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$5$1.processInvocation(MessageDrivenComponentDescription.java:239)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>         at
>
> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
>         at
>
> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>         at
>
> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at
> org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
>         at
>
> org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at
>
> org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
>         at
> de.adesso.tma.test.ejb.TestMessageBean$$$view10.onMessage(Unknown
> Source)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>         at java.lang.reflect.Method.invoke(Unknown Source)
>         at
>
> org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:139)
>         at
>
> org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
>         at
> de.adesso.tma.test.ejb.TestMessageBean$$$endpoint5.onMessage(Unknown
> Source)
>         at
>
> org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:123)
>         at
>
> org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:64)
>         at
> org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:1041)
>         at
> org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:169)
>         at
> org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
>         at
>
> org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
>         at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)
>         at
> org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
>         at
> org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)
>         at java.lang.Thread.run(Unknown Source)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>
> 08:31:53,284 ERROR [org.apache.activemq.ActiveMQSession] (default-threads -
> 7) error dispatching message: : javax.ejb.EJBAccessException: WFLYEJB0364:
> Invocation on method: public void
>         at
>
> org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:134)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$5$1.processInvocation(MessageDrivenComponentDescription.java:239)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>         at
>
> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
>         at
>
> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
>         at
>
> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at
> org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
>         at
>
> org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
>         at
>
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
>         at
>
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at
>
> org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
>         at
> de.adesso.tma.test.ejb.TestMessageBean$$$view10.onMessage(Unknown
> Source)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>         at java.lang.reflect.Method.invoke(Unknown Source)
>         at
>
> org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:139)
>         at
>
> org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
>         at
> de.adesso.tma.test.ejb.TestMessageBean$$$endpoint5.onMessage(Unknown
> Source)
>         at
>
> org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:123)
>         at
>
> org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:64)
>         at
> org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:1041)
>         at
> org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:169)
>         at
> org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
>         at
>
> org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
>         at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)
>         at
> org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
>         at
> org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)
>         at java.lang.Thread.run(Unknown Source)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Message-not-redirected-to-DLQ-when-exception-thrown-by-MDB-tp4709187p4709451.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: Message not redirected to DLQ when exception thrown by MDB

Posted by THMayr <Th...@adesso.de>.
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
resource adapter is involved and with WebLogic the connection is made by the
ActiveMQ JNDI connection factory.

I have no idea how to turn on logging or tracing. But what I can see on the
WildFliy console is, that WildFly throws an exception and afterwards the
ActiveMQSession throws an exception caused by the first one. In this case I
configured the MDB so, that the container is not allowed to invoke the
method /onMessage()/:

08:31:53,279 ERROR [org.jboss.as.ejb3.invocation] (default-threads - 7)
WFLYEJB0034: EJB Invocation failed on component TestMessageBeanLow for
method public void de.adesso.tma.test.ejb.
ic void de.adesso.tma.test.ejb.TestMessageBean.onMessage(javax.jms.Message)
of bean: TestMessageBeanLow is not allowed
        at
org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:134)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$5$1.processInvocation(MessageDrivenComponentDescription.java:239)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
        at
org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
        at
org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
        at
org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at
org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
        at
org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at
org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
        at de.adesso.tma.test.ejb.TestMessageBean$$$view10.onMessage(Unknown
Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at
org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:139)
        at
org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
        at
de.adesso.tma.test.ejb.TestMessageBean$$$endpoint5.onMessage(Unknown Source)
        at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:123)
        at
org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:64)
        at
org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:1041)
        at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:169)
        at
org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
        at
org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
        at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)
        at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
        at
org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)
        at java.lang.Thread.run(Unknown Source)
        at org.jboss.threads.JBossThread.run(JBossThread.java:320)

08:31:53,284 ERROR [org.apache.activemq.ActiveMQSession] (default-threads -
7) error dispatching message: : javax.ejb.EJBAccessException: WFLYEJB0364:
Invocation on method: public void
        at
org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:134)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$5$1.processInvocation(MessageDrivenComponentDescription.java:239)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
        at
org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
        at
org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
        at
org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at
org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
        at
org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
        at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
        at
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at
org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
        at de.adesso.tma.test.ejb.TestMessageBean$$$view10.onMessage(Unknown
Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at
org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:139)
        at
org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
        at
de.adesso.tma.test.ejb.TestMessageBean$$$endpoint5.onMessage(Unknown Source)
        at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:123)
        at
org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:64)
        at
org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:1041)
        at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:169)
        at
org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
        at
org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
        at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)
        at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
        at
org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)
        at java.lang.Thread.run(Unknown Source)
        at org.jboss.threads.JBossThread.run(JBossThread.java:320)



--
View this message in context: http://activemq.2283324.n4.nabble.com/Message-not-redirected-to-DLQ-when-exception-thrown-by-MDB-tp4709187p4709451.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message not redirected to DLQ when exception thrown by MDB

Posted by artnaseef <ar...@artnaseef.com>.
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 :...
* ... Transaction Rollback, txid: ...

TRACE level logging may provide even more insight.

DEBUG logging on org.apache.activemq.broker.TransactionBroker on the broker
itself may also provide more insight.

Hope this helps.



--
View this message in context: http://activemq.2283324.n4.nabble.com/Message-not-redirected-to-DLQ-when-exception-thrown-by-MDB-tp4709187p4709308.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message not redirected to DLQ when exception thrown by MDB

Posted by THMayr <Th...@adesso.de>.
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
/javax.transaction.UserTransaction/ to begin, commit or rollback
transactions. And here the section with the bean and container
responsibilities:

/If a message-driven bean instance starts a transaction in a message
listener method or interceptor method, it must commit the transaction before
the message listener method (or all its interceptor methods) returns. The
container must detect the case in which a transaction was started, but not
completed, in a message listener method or interceptor method for the
message listener method, and handle it as follows:
- Log this as an application error to alert the System Administrator.
- Roll back the started transaction.
- Discard the instance of the message-driven bean./

And this is exactly what I do. So there is not active JTA transaction when
the method /onMessage()/ is entered. I start a transaction, commit the
transaction and in case of an exception I rollback the transaction before
the method is left.

Regards Thomas



--
View this message in context: http://activemq.2283324.n4.nabble.com/Message-not-redirected-to-DLQ-when-exception-thrown-by-MDB-tp4709187p4709287.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message not redirected to DLQ when exception thrown by MDB

Posted by artnaseef <ar...@artnaseef.com>.
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#createSession-boolean-int-

The semantics with EJB are very interesting - this is a configuration I've
never personally used nor looked into before.  Notice especially the
heading, "In the Java EE web or EJB container, when there is no active JTA
transaction in progress".  And before that, "In a Java EE web or EJB
container, when there is an active JTA transaction in progress".

Can you confirm whether a JTA transaction is "in-progress"?





--
View this message in context: http://activemq.2283324.n4.nabble.com/Message-not-redirected-to-DLQ-when-exception-thrown-by-MDB-tp4709187p4709261.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message not redirected to DLQ when exception thrown by MDB

Posted by THMayr <Th...@adesso.de>.
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.



--
View this message in context: http://activemq.2283324.n4.nabble.com/Message-not-redirected-to-DLQ-when-exception-thrown-by-MDB-tp4709187p4709252.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message not redirected to DLQ when exception thrown by MDB

Posted by THMayr <Th...@adesso.de>.
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 calling
the method /UserTransaction.rollback()./ The user transaction is retrieved
by the method /MessageDrivenContext.getUserTransaction()/. But in this case,
the message is not redirected to the DLQ.

The messages are also not redirected, when an exeption is thrown by
/onMessage()/ (without rollback), independent on the transaction mode. When
I do the same on WebLogic, the container seems to roll back the transaction
in this case, and the messages are redirected to the DLQ.

I could live with the fact, that I have to rollback the transaction in the
bean code when bean managed transactions are used and an exception occurs.
But this doesn't work with WildFly nor with WebLogic.

I hope it is clear now.

Thomas



--
View this message in context: http://activemq.2283324.n4.nabble.com/Message-not-redirected-to-DLQ-when-exception-thrown-by-MDB-tp4709187p4709250.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message not redirected to DLQ when exception thrown by MDB

Posted by artnaseef <ar...@artnaseef.com>.
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 words - could the transactions be lingering, or actually committing?

Bottom line here - there needs to be a rollback on the transaction, when XA
or JMS transactions are active, in order for the message to get routed to
the DLQ.

I believe there is some logging (either debug level or trace level) that
will show enough detail on the client to track this down further.



--
View this message in context: http://activemq.2283324.n4.nabble.com/Message-not-redirected-to-DLQ-when-exception-thrown-by-MDB-tp4709187p4709239.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message not redirected to DLQ when exception thrown by MDB

Posted by THMayr <Th...@adesso.de>.
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 the
messages redirected to the DLQ.

The JMS specification says the following:

/AUTO_ACKNOWLEDGE
With this acknowledgment mode, the session automatically acknowledges a
client's receipt of a message either when the session has successfully
returned from a call to receive or when the message listener the session has
called to process the message successfully returns./

This may be interpreted as if the container may acknowledge the message,
when it has received the message from the broker but before /onMessage()/ of
the MDB has been called. In this case I understand the behaviour. But then
there is no difference to the acknowledge mode /Dups-ok-acknowledge/. The
only mode, which may be helpful is /CLIENT_ACKNOWLEDGE/, but this is not
valid for MDB's.

Regards Thomas



--
View this message in context: http://activemq.2283324.n4.nabble.com/Message-not-redirected-to-DLQ-when-exception-thrown-by-MDB-tp4709187p4709204.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message not redirected to DLQ when exception thrown by MDB

Posted by Tim Bain <tb...@alumni.duke.edu>.
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 also grab the source of the message adapter and attach it to your
debugger, and you can step out (up the stack) to see if we're eating the
exception.  If we're eating it, file a bug in JIRA; if not, then maybe it's
something in Wildfly.

Tim
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 acknowledgment is automatically handled by the
container. If the message-driven bean uses container-managed transaction
demarcation, message acknowledgment is handled automatically as a part of
the transaction commit. If bean-managed transaction demarcation is used, the
message receipt cannot be part of the bean-managed transaction, and, in this
case, the receipt is acknowledged by the container. If bean-managed
transaction demarcation is used, the Bean Provider can indicate whether JMS
AUTO_ACKNOWLEDGE semantics or DUPS_OK_ACKNOWLEDGE semantics should apply by
using the
activationConfig element of the MessageDriven annotation or by using the
activation-config-property deployment descriptor element. The property name
used to specify the acknowledgment mode is acknowledgeMode. If the
acknowledgeMode property is not specified, JMS AUTO_ACKNOWLEDGE semantics
are assumed. The value of the acknowledgeMode property must be either
Auto-acknowledge or Dups-ok-acknowledge for a JMS message-driven bean./

The specification seems to be differently interpreted. As I said already,
WebLogic handes it so, that when an exception occurs in the MDB messages are
resent to the bean and at last redirected to the DLQ. It doesn't matter if I
use ActiveMQ or the WebLogic internal JMS system. Interestingly, the message
is not redelivered or redirected, when I roll-back the user transaction.

I wonder if this has something to do with the ActiveMQ resource adapter,
which is involved with WildFly but not with WebLogic. Or it is a WildFly
issue.

In any case IMHO acknowledging a message, when processing fails is not very
useful.

Thomas





--
View this message in context:
http://activemq.2283324.n4.nabble.com/Message-not-redirected-to-DLQ-when-exception-thrown-by-MDB-tp4709187p4709206.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message not redirected to DLQ when exception thrown by MDB

Posted by THMayr <Th...@adesso.de>.
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 acknowledgment is automatically handled by the
container. If the message-driven bean uses container-managed transaction
demarcation, message acknowledgment is handled automatically as a part of
the transaction commit. If bean-managed transaction demarcation is used, the
message receipt cannot be part of the bean-managed transaction, and, in this
case, the receipt is acknowledged by the container. If bean-managed
transaction demarcation is used, the Bean Provider can indicate whether JMS
AUTO_ACKNOWLEDGE semantics or DUPS_OK_ACKNOWLEDGE semantics should apply by
using the
activationConfig element of the MessageDriven annotation or by using the
activation-config-property deployment descriptor element. The property name
used to specify the acknowledgment mode is acknowledgeMode. If the
acknowledgeMode property is not specified, JMS AUTO_ACKNOWLEDGE semantics
are assumed. The value of the acknowledgeMode property must be either
Auto-acknowledge or Dups-ok-acknowledge for a JMS message-driven bean./

The specification seems to be differently interpreted. As I said already,
WebLogic handes it so, that when an exception occurs in the MDB messages are
resent to the bean and at last redirected to the DLQ. It doesn't matter if I
use ActiveMQ or the WebLogic internal JMS system. Interestingly, the message
is not redelivered or redirected, when I roll-back the user transaction. 

I wonder if this has something to do with the ActiveMQ resource adapter,
which is involved with WildFly but not with WebLogic. Or it is a WildFly
issue.

In any case IMHO acknowledging a message, when processing fails is not very
useful.

Thomas





--
View this message in context: http://activemq.2283324.n4.nabble.com/Message-not-redirected-to-DLQ-when-exception-thrown-by-MDB-tp4709187p4709206.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Message not redirected to DLQ when exception thrown by MDB

Posted by Tim Bain <tb...@alumni.duke.edu>.
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" <Th...@adesso.de> wrote:

> Hi,
>
> I deployed a MDB on WildFly 10.0.0. An external ActiveMQ server is
> configured in WildFly with the ActiveMQ resource adapter.
>
> When the method /onMessage()/ of the MDB method throws a runtime exception,
> the message is not redirected to the DLQ. This works only, when container
> managed transaction handling is used, a transaction is required, and I set
> the transaction to be roll-backed by the container when the exception
> occurs
> (MessageDrivenContext.setRollbackOnly()). In this case no exception is
> thrown to the container.
>
> When I do the same in WebLogic it works!
>
> I cannot use container managed transactions in my MDB. So is there a way to
> redirect the message to the DLQ when processing fails?
>
> Thomas
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Message-not-redirected-to-DLQ-when-exception-thrown-by-MDB-tp4709187.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>