Problems sending JMS messages inside JMS-transacted UMO

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Won't Fix or Usage Issue
  • Affects Version/s: 1.4.3
  • Fix Version/s: None
  • Component/s: Transport: JMS
  • Labels:
    None
  • Environment:

    Windows Vista
    JDK 1.6
    ActiveMQ

  • User impact:
    High
  • Similar Issues:
    None

Description

  • Set up simple ActiveMQ server on your machine.
  • Run ActiveMQ and JConsole for inspecting message flow.
  • Start with the "hello" example for 1.4.3.
  • Add project dependencies for client module and jms transport.
  • Replace Greeter.java with attached version.
  • Replace hello-config.xml with attached version.
  • Edit the <global-endpoints> section to set one of the "StatusSetter..." endpoints to just "StatusSetter".
  • Run a test for each of the endpoints in turn.

Results:

VM - This endpoint produces the effect I am hoping for. As the GreeterUMO is executing, % done status prints on the screen. Of course, this does not allow GreeterUMO to execute remotely.

JMSTran - This endpoint shows no status until the end. This is expected, since the status setting endpoint is using the same JMS connector as the greeter UMO. The status messages should be transacted with the greeter message. Unfortunately, this case also blows up at the end, showing 2 problems, I think, with the current implementation:

  • NPE - the current message is stored in a ThreadLocal, and the JMS dispatch code is overwriting that value, eventually killing the outbound router.
  • Transacted message chain is broken - I was a little surprised to find that the outbound router happens after the transaction on the inbound endpoint is closed. I was expecting the message to jms://chitchat.requests to be transacted with the one from jms://greet.requests. I may just be missing some transaction configuration?

JMSOffTran - This is where I started, trying to send status (outside the JMS transaction) to a remote UI while handling a transacted JMS request. This one fails with Mule refusing to send the JMS message because it cannot be transacted with the current message... exactly what I am hoping for, I believe.

If it is, in fact, possible to send in-process status with JMS in some other way, and I am just going about this the hard way, please let me know.

  1. Java Source File
    Greeter.java
    02/Jan/08 03:01 PM
    2 kB
    Brendan MacLean
  2. Java Source File
    Greeter2.java
    29/Jan/08 05:32 AM
    2 kB
    Andrey Shaposhnikov
  3. XML File
    hello-config.xml
    02/Jan/08 02:59 PM
    11 kB
    Brendan MacLean
  4. XML File
    hello-config-jms.xml
    25/Jan/08 10:01 AM
    12 kB
    Brendan MacLean

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brendan MacLean added a comment -

Attach mule config file

Show
Brendan MacLean added a comment - Attach mule config file
Hide
Permalink
Brendan MacLean added a comment -

Modified Greeter source

Show
Brendan MacLean added a comment - Modified Greeter source
Hide
Permalink
Andrew Perepelytsya added a comment -

Please retest with Mule 1.4.4 snapshot. Also, AMQ5 had problems, ensure you are using 4.1.x

Show
Andrew Perepelytsya added a comment - Please retest with Mule 1.4.4 snapshot. Also, AMQ5 had problems, ensure you are using 4.1.x
Hide
Permalink
Brendan MacLean added a comment -

I am using ActiveMQ 4.1.1. No noticeable change using 1.4.4-SNAPSHOT.

I should note that my original instructions are missing one step. You need to comment out the "StatusSetter" global-endpoint on the "StatusReporter" when not using the "StatusSetterVM" version. Otherwise, it will complain in start-up that you have two listeners on the same address "jms://status.queue".

Show
Brendan MacLean added a comment - I am using ActiveMQ 4.1.1. No noticeable change using 1.4.4-SNAPSHOT. I should note that my original instructions are missing one step. You need to comment out the "StatusSetter" global-endpoint on the "StatusReporter" when not using the "StatusSetterVM" version. Otherwise, it will complain in start-up that you have two listeners on the same address "jms://status.queue".
Hide
Permalink
Brendan MacLean added a comment -

Could I get a status update? Have you been able to reproduce on your end?

I am trying plan for how to get around this. Any chance of a fix? Or should I be planning on another solution? (e.g. posting my own JMS message, or using another transport with Mule)

Thanks.

Show
Brendan MacLean added a comment - Could I get a status update? Have you been able to reproduce on your end? I am trying plan for how to get around this. Any chance of a fix? Or should I be planning on another solution? (e.g. posting my own JMS message, or using another transport with Mule) Thanks.
Hide
Permalink
Anatoli Kuzmin added a comment -

1. NPE was reproduced
java.lang.NullPointerException
at org.mule.routing.outbound.OutboundRouterCollection.route(OutboundRouterCollection.java:59)
session.getComponent() is null
2. Transaction is as design. You should to use the separate component to begin new jms transaction
Greeting -> vm -> jms

Show
Anatoli Kuzmin added a comment - 1. NPE was reproduced java.lang.NullPointerException at org.mule.routing.outbound.OutboundRouterCollection.route(OutboundRouterCollection.java:59) session.getComponent() is null 2. Transaction is as design. You should to use the separate component to begin new jms transaction Greeting -> vm -> jms
Hide
Permalink
Brendan MacLean added a comment -

Okay, I oversimplified in an attempt to use a single config file.

I will attach a new config file that attempts, again, to achieve the desired result, but now gets the exception:

org.mule.transaction.IllegalTransactionStateException: Only a single resource ca
n be bound to this type of transaction
at org.mule.transaction.AbstractSingleResourceTransaction.bindResource(A
bstractSingleResourceTransaction.java:130)

If you have a working solution that uses 2 JMS queues (1 inbound, handling the message, and on outbound for the status) please post the config.

Show
Brendan MacLean added a comment - Okay, I oversimplified in an attempt to use a single config file. I will attach a new config file that attempts, again, to achieve the desired result, but now gets the exception: org.mule.transaction.IllegalTransactionStateException: Only a single resource ca n be bound to this type of transaction at org.mule.transaction.AbstractSingleResourceTransaction.bindResource(A bstractSingleResourceTransaction.java:130) If you have a working solution that uses 2 JMS queues (1 inbound, handling the message, and on outbound for the status) please post the config.
Hide
Permalink
Brendan MacLean added a comment -

More complex configuration file necessary for showing JMS issues.

Show
Brendan MacLean added a comment - More complex configuration file necessary for showing JMS issues.
Hide
Permalink
Anatoli Kuzmin added a comment -

Configuration allows to control transaction only on 3 points - inbound endpoint, outbound-router and outbound-endpoint
When you begin a transaction on endpoint, your component will executed within the transaction

There are 3 solutions
1. There is a need to divide the complex descriptor into 2 parts (your configuration with vm)
------
2. get connection and create non transactional session using Jms (ActiveMQ) API
3. commit inbound transaction using Mule API

I think that only the first solution is pretty

2. Unfortunately, ALWAYS_BEGIN action have been implemented last week
see org.mule.test.integration.providers.jms.functional.JmsSingleTransactionAlwaysBeginConfigurationTestCase
or JmsSingleTransactionBeginOrJoinAndAlwaysBeginTestCase

Show
Anatoli Kuzmin added a comment - Configuration allows to control transaction only on 3 points - inbound endpoint, outbound-router and outbound-endpoint When you begin a transaction on endpoint, your component will executed within the transaction There are 3 solutions 1. There is a need to divide the complex descriptor into 2 parts (your configuration with vm) ------ 2. get connection and create non transactional session using Jms (ActiveMQ) API 3. commit inbound transaction using Mule API I think that only the first solution is pretty 2. Unfortunately, ALWAYS_BEGIN action have been implemented last week see org.mule.test.integration.providers.jms.functional.JmsSingleTransactionAlwaysBeginConfigurationTestCase or JmsSingleTransactionBeginOrJoinAndAlwaysBeginTestCase
Hide
Permalink
Brendan MacLean added a comment -

I understand #2 and #3. #3 will not achieve the desired result, and, yes, #2 is a little messy, and I had hoped to avoid, but if it is all I can get working, I suppose I can wrap it in a method call (calling transformers, and posting to JMS directly, ick) that hopefully I can replace one day with a MuleClient call to a named endpoint.

I am still not getting #1. Are you saying new code I don't have yet allows my latest configuration to work? Or do I still need to change that configuration? Or?

Show
Brendan MacLean added a comment - I understand #2 and #3. #3 will not achieve the desired result, and, yes, #2 is a little messy, and I had hoped to avoid, but if it is all I can get working, I suppose I can wrap it in a method call (calling transformers, and posting to JMS directly, ick) that hopefully I can replace one day with a MuleClient call to a named endpoint. I am still not getting #1. Are you saying new code I don't have yet allows my latest configuration to work? Or do I still need to change that configuration? Or?
Hide
Permalink
Anatoli Kuzmin added a comment - 
<mule-descriptor name="StatusSetter" implementation="org.mule.components.simple.EchoComponent">
            <inbound-router>
                <global-endpoint name="StatusSetterVM"/>
            </inbound-router>
            <outbound-router>
                <router className="org.mule.routing.outbound.OutboundPassThroughRouter">
                    <endpoint address="jms://status.queue" transformers="ObjectToJMSMessage"
                            connector="jmsConnectorStatus">
                        <transaction action="ALWAYS_BEGIN" factory="org.mule.providers.jms.JmsTransactionFactory" />
                    </endpoint>
                </router>
            </outbound-router>
        </mule-descriptor>

This configuration will be enough.

Show
Anatoli Kuzmin added a comment - 
<mule-descriptor name="StatusSetter" implementation="org.mule.components.simple.EchoComponent">
            <inbound-router>
                <global-endpoint name="StatusSetterVM"/>
            </inbound-router>
            <outbound-router>
                <router className="org.mule.routing.outbound.OutboundPassThroughRouter">
                    <endpoint address="jms://status.queue" transformers="ObjectToJMSMessage"
                            connector="jmsConnectorStatus">
                        <transaction action="ALWAYS_BEGIN" factory="org.mule.providers.jms.JmsTransactionFactory" />
                    </endpoint>
                </router>
            </outbound-router>
        </mule-descriptor>
This configuration will be enough.
Hide
Permalink
Anatoli Kuzmin added a comment -

Ups,
I forgot the receiveMessagesInTransaction property

Show
Anatoli Kuzmin added a comment - Ups, I forgot the receiveMessagesInTransaction property
Hide
Permalink
Brendan MacLean added a comment -

Please post a config.xml file which produces the desired results. The snippet you posted exactly matches what I posted in hello-config-jms.xml (or am I missing something?) As I said in the bug report, this configuration produces an IllegalTransactionStateException.

And I don't get the reference to "receiveMessagesInTransaction". This name does not appear anywhere in the Mule config DTD as far as I can tell.

I would love not to have to hardcode a JMS post to the desired message queue, but I am not seeing how this is avoidable with the current Mule implementation.

Show
Brendan MacLean added a comment - Please post a config.xml file which produces the desired results. The snippet you posted exactly matches what I posted in hello-config-jms.xml (or am I missing something?) As I said in the bug report, this configuration produces an IllegalTransactionStateException. And I don't get the reference to "receiveMessagesInTransaction". This name does not appear anywhere in the Mule config DTD as far as I can tell. I would love not to have to hardcode a JMS post to the desired message queue, but I am not seeing how this is avoidable with the current Mule implementation.
Hide
Permalink
Andrey Shaposhnikov added a comment -

You should use UMOEventContext instead of MuleClient if you want send/dispatch messages on the inside of UMOComponent. See Greeter2.java.

Show
Andrey Shaposhnikov added a comment - You should use UMOEventContext instead of MuleClient if you want send/dispatch messages on the inside of UMOComponent. See Greeter2.java.
Hide
Permalink
Brendan MacLean added a comment -

I think I am pretty patient, but I'd sure appreciate it if someone would try a suggestion before proposing it, and give me one has actually been seen work. The posted file was missing imports, so I am guessing it wasn't actually ever compiled.

Not surprisingly, the suggestion doesn't work. When I debug into the failure I end up with a RuntimException with the message "Could not bind session to current transaction." Sounds pretty familiar.

We are going in day 26 for this bug...

Show
Brendan MacLean added a comment - I think I am pretty patient, but I'd sure appreciate it if someone would try a suggestion before proposing it, and give me one has actually been seen work. The posted file was missing imports, so I am guessing it wasn't actually ever compiled. Not surprisingly, the suggestion doesn't work. When I debug into the failure I end up with a RuntimException with the message "Could not bind session to current transaction." Sounds pretty familiar. We are going in day 26 for this bug...
Hide
Permalink
Andrew Perepelytsya added a comment -

You didn't mention you upgraded, the changes are in the trunk, just using the config isn't enough, you'll need the snapshot version with fixes.

Show
Andrew Perepelytsya added a comment - You didn't mention you upgraded, the changes are in the trunk, just using the config isn't enough, you'll need the snapshot version with fixes.
Hide
Permalink
Brendan MacLean added a comment -

Okay. Sorry. No fix was mentioned, so I thought this was just a work-around. Indeed, my snapshot is weeks old. I'll try the latest, thanks.

Show
Brendan MacLean added a comment - Okay. Sorry. No fix was mentioned, so I thought this was just a work-around. Indeed, my snapshot is weeks old. I'll try the latest, thanks.
Hide
Permalink
Anatoli Kuzmin added a comment -

"You should use UMOEventContext instead of MuleClient" is fixed only NPE
Please, Could you post Build-Revision?

Show
Anatoli Kuzmin added a comment - "You should use UMOEventContext instead of MuleClient" is fixed only NPE Please, Could you post Build-Revision?
Hide
Permalink
Brendan MacLean added a comment -

Okay, I ask the same simple courtesy in return. Next iteration, please tell me the build on which you have seen your suggestion work, and please paste the console output that shows the status correctly printed, as happens with my initial VM-only example.

With Mule version: 1.4.4-SNAPSHOT Build: 10648, and the suggested change to UMOEventContext:

If I step through the message dispatch, I end up at

dispatch():175, AbstractMessageDispatcher {org.mule.providers}

With the exception:

e = {java.lang.RuntimeException@4260}"java.lang.RuntimeException: Could not bind session to current transaction"

I get the following exception in the console for every status post.

Caused by: org.mule.umo.provider.DispatchException: Failed to route event via en
dpoint: MuleEndpoint{endpointUri=jms://status.queue, connector=ActiveMqJmsConnec
tor{this=59fb21, started=true, initialised=true, name='jmsConnectorStatus', disp osed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedRec eivers=true, connected=true, supportedProtocols=[jms], serviceOverrides=null}, t
ransformer=ObjectToJMSMessage{this=e41bc3, name='ObjectToJMSMessage', ignoreBadI nput=false, returnClass=interface javax.jms.TextMessage, sourceTypes=[]}, name='
StatusSetter', type='sender', properties={}, transactionConfig=Transaction{facto ry=null, action=NONE, timeout=30000}, filter=null, deleteUnacceptedMessages=fals
e, initialised=true, securityFilter=null, synchronous=null, initialState=started
, createConnector=0, remoteSync=false, remoteSyncTimeout=10000, endpointEncoding
=null}. Message payload is of type: String
at org.mule.providers.AbstractMessageDispatcher.dispatch(AbstractMessage
Dispatcher.java:176)
at org.mule.providers.AbstractConnector.dispatch(AbstractConnector.java:
1583)
at org.mule.impl.ImmutableMuleEndpoint.dispatch(ImmutableMuleEndpoint.ja
va:924)
at org.mule.impl.MuleSession.dispatchEvent(MuleSession.java:259)
... 35 more
Caused by: java.lang.RuntimeException: Could not bind session to current transac
tion
at org.mule.providers.jms.JmsConnector.getSession(JmsConnector.java:487)

at org.mule.providers.jms.JmsConnector.getSession(JmsConnector.java:449)

at org.mule.providers.jms.JmsMessageDispatcher.dispatchMessage(JmsMessag
eDispatcher.java:126)
at org.mule.providers.jms.JmsMessageDispatcher.doDispatch(JmsMessageDisp
atcher.java:64)
at org.mule.providers.AbstractMessageDispatcher.dispatch(AbstractMessage
Dispatcher.java:155)
... 38 more
Caused by: org.mule.transaction.IllegalTransactionStateException: Jms session sh
ould be transacted
at org.mule.providers.jms.JmsTransaction.bindResource(JmsTransaction.jav
a:45)
at org.mule.providers.jms.JmsConnector.getSession(JmsConnector.java:483)

... 42 more

Show
Brendan MacLean added a comment - Okay, I ask the same simple courtesy in return. Next iteration, please tell me the build on which you have seen your suggestion work, and please paste the console output that shows the status correctly printed, as happens with my initial VM-only example. With Mule version: 1.4.4-SNAPSHOT Build: 10648, and the suggested change to UMOEventContext: If I step through the message dispatch, I end up at dispatch():175, AbstractMessageDispatcher {org.mule.providers} With the exception: e = {java.lang.RuntimeException@4260}"java.lang.RuntimeException: Could not bind session to current transaction" I get the following exception in the console for every status post. Caused by: org.mule.umo.provider.DispatchException: Failed to route event via en dpoint: MuleEndpoint{endpointUri=jms://status.queue, connector=ActiveMqJmsConnec tor{this=59fb21, started=true, initialised=true, name='jmsConnectorStatus', disp osed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedRec eivers=true, connected=true, supportedProtocols=[jms], serviceOverrides=null}, t ransformer=ObjectToJMSMessage{this=e41bc3, name='ObjectToJMSMessage', ignoreBadI nput=false, returnClass=interface javax.jms.TextMessage, sourceTypes=[]}, name=' StatusSetter', type='sender', properties={}, transactionConfig=Transaction{facto ry=null, action=NONE, timeout=30000}, filter=null, deleteUnacceptedMessages=fals e, initialised=true, securityFilter=null, synchronous=null, initialState=started , createConnector=0, remoteSync=false, remoteSyncTimeout=10000, endpointEncoding =null}. Message payload is of type: String at org.mule.providers.AbstractMessageDispatcher.dispatch(AbstractMessage Dispatcher.java:176) at org.mule.providers.AbstractConnector.dispatch(AbstractConnector.java: 1583) at org.mule.impl.ImmutableMuleEndpoint.dispatch(ImmutableMuleEndpoint.ja va:924) at org.mule.impl.MuleSession.dispatchEvent(MuleSession.java:259) ... 35 more Caused by: java.lang.RuntimeException: Could not bind session to current transac tion at org.mule.providers.jms.JmsConnector.getSession(JmsConnector.java:487) at org.mule.providers.jms.JmsConnector.getSession(JmsConnector.java:449) at org.mule.providers.jms.JmsMessageDispatcher.dispatchMessage(JmsMessag eDispatcher.java:126) at org.mule.providers.jms.JmsMessageDispatcher.doDispatch(JmsMessageDisp atcher.java:64) at org.mule.providers.AbstractMessageDispatcher.dispatch(AbstractMessage Dispatcher.java:155) ... 38 more Caused by: org.mule.transaction.IllegalTransactionStateException: Jms session sh ould be transacted at org.mule.providers.jms.JmsTransaction.bindResource(JmsTransaction.jav a:45) at org.mule.providers.jms.JmsConnector.getSession(JmsConnector.java:483) ... 42 more
Hide
Permalink
Andrew Perepelytsya added a comment -

There are a number of issues with the configs, the most important one being that jms and vm transactions are being mixed. This is not possible, unless XA is used - that's what IllegalTransactionStateException says.

Show
Andrew Perepelytsya added a comment - There are a number of issues with the configs, the most important one being that jms and vm transactions are being mixed. This is not possible, unless XA is used - that's what IllegalTransactionStateException says.

People

  • Assignee:
    Andrew Perepelytsya
    Reporter:
    Brendan MacLean
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: