|
[
Permlink
| « Hide
]
Andrew Perepelytsya added a comment - 22/Apr/08 02:28 PM
Angelo, first, you have to apply the receiver both to message.receiver and transacted.message.receiver. Then try again. Next, I'd suggest having 2 connectors for separate send and receive. This error is one of those bizarre wmq things that do not happen elsewhere (just try googling around for MQJMS1013 - it reportedly failed even for wmq sample apps...). Hard to tell more without a stacktrace, what endpoint does it fail at exactly?
Thanks Andrew.
I tried configuring the message.receiver as well, but it didn't change the behavior. Here's the trace: ******************************************************************************** Looks like it's failing at the outbound endpoint for the transaction. Sorry, I forgot to post the case link initially in this record. You can find more info there as well... Also, is there anything special i need to do if I configure another connector for "send", besides exclude the serviceOverride?
Don't exclude serviceOverrides, but for each endpoint ensure a connector attribute is specified (should be different).
I got a different error when using separate connectors for send and receive endpoints:
******************************************************************************** ******************************************************************************** Have you declared TX attributes on every endpoint? This includes outbound. Also please try with 1.4.4-SNAPSHOT.
I tried declaring "ALWAYS_JOIN" on my outbound endpoint, etc, but wound up with the following error:
******************************************************************************** ******************************************************************************** Unfortunately, this is a client issue, and they're using 1.4.3 in production. So, I am focused on that version for now. If there's a fix for this in benecia, we may have to backport it. Thanks again for helping. I really appreciate it. Andrew,
I've confirmed that the original config I attached (single connector, transaction on inbound endpoint) does, in fact, work with 1.4.4-SNAPSHOT. I see the messages going through the queues. WMQ version is 6.0. Unfortunately, the only pre-configured version of websphere MQ I've used is on my laptop. I believe Eugene installed one at 172.16.10.146 as well today, but I'm not sure if it's externally accessible. The settings are all default, and here are some queues you can use to test: mule.input Dived into the issue again, here are my observations:
In case of MultiConsumerJmsMessageReceiver there are multiple receiving sessions, and each session is guaranteed to be used by a single thread, read my comments here: If there's a need to provide a workaround for WMQ, it has to be scoped differently, as the changes can have wide-spread effect. I'm inclined to close this issue then. This ticket can be closed. As of 1.4.4, this can be corrected with the following service overrides:
serviceOverrides= Closing as per Angelo's comment
Reopen as per Kevin's and Angelo's request
Angelo, with Mule 1.4.4 upgrade effort, we are encountering this problem... Using two different connectors for sends and receives seems to bypass this issue, however, we then see that once the message has been received/sent successfully, the connector goes offline, so any subsequent messages remain idle on the queue. There are no errors in the logs either. Hassan,
In 1.4.4, you should no longer have to define multiple connectors. This was only necessary prior to the fix. In our tests, the original reported error no longer appeared (with the service overrides). Are you seeing something different? If so, please let us know, and post your config files if possible. Cheers, Angelo Angelo,
We are getting the same error : 2008-07-08 10:06:21,080 ERROR [vmProfileConnector.receiver.2] [] Failed to dispatch to async audit service. Cause: MQJMS1013: operation invalid whilst session is using asynchronous delivery The connector used (vmProfileConnector) for send and receive: As stated in my last comment, if we use two different connectors for send and receive then we don't see this issue, however, the connector silently dies after the first message is processed through it. BusTransactionCompliantJmsMessageReceiver is a wrapper for JmsMessageReceiver that provides us with the customized ability to bind our own Transactions - this is w.r.t support issue: http://na1.salesforce.com/sserv/casedetailview.jsp?id=500300000059zJl I'll attach the BusTransactionCompliantJmsMessageReceiver source on this jira. Note I have used ** at various places here and on the attached source to hide company specific info. This however, goes away if we use 2 connectors Hassan,
I did some additional testing this morning, and confirmed this is not an issue in our receiver (I used MultiConsumerJmsMessageReceiver, which is recommended). I was able to pull transacted messages off one queue, and place them in two separate queues via an outbound router, and no errors were encountered. I was not able to do this previously (prior to 1.4.4) using the same MultiConsumerJmsMessageReceiver. I always encountered the "operation invalid whilst session is using asynchronous delivery". This particular defect record ( Can you clarify the purpose of this custom receiver, and how it differs from the functionality offered in MultiConsumerJmsMessageReceiver? Have you confirmed that the flow you were attempting to achieve with this custom receiver can't be achieved with MultiConsumerJmsMessageReceiver? If you need assistance customizing our code to meet your needs, I would recommend discussing a possible engagement with our consulting team. They have extensive expertise with customizations of all the aspects of the ESB product (connectors, components, etc.). I'll discuss this with Ross and others here internally, Unfortunately, I can't attach files to a closed defect record, but I've pasted my simple test configuration for this issue below, which uses our standard receiver: <?xml version="1.0" encoding="UTF-8"?> <mule-environment-properties> <container-context className="org.mule.extras.spring.SpringContainerContext"> <connector name="SystemStreamConnector" className="org.mule.providers.stream.SystemStreamConnector"> <connector name="mqConnector" className="org.mule.providers.jms.websphere.WebsphereJmsConnector"> <container-property name="connectionFactory" reference="devQpidJmsConnectionFactory" required="true"/> </properties> <property name="frequency" value="5000"/> <model name="bus-instance"> <mule-descriptor name="BridgeUMO" implementation="org.mule.components.simple.BridgeComponent"> <inbound-router> <mule-descriptor name="GetUMO" implementation="org.mule.components.simple.BridgeComponent"> </inbound-router> <outbound-router> <pooling-profile exhaustedAction="WAIT" maxActive="50" maxIdle="50" maxWait="-1" initialisationPolicy="INITIALISE_ALL" /> </mule-descriptor> </model> Angelo, re your question: "Can you clarify the purpose of this custom receiver, and how it differs from the functionality offered in MultiConsumerJmsMessageReceiver? Have you confirmed that the flow you were attempting to achieve with this custom receiver can't be achieved with MultiConsumerJmsMessageReceiver? " a: BusTransactionCompliantJmsMessageReceiver currently extends org.mule.providers.jms.JmsMessageReceiver, however, once we have the doThreading issue resolved (as per case 00001483) we will I have forwarded you the code for BusTransactionCompliantJmsMessageReceiver as I could not attach it to the jira. BusTransactionCompliantJmsMessageReceiver delegates everything to the parent Mule classes and has only one small bespoke functionality: "if (tx instanceof JmsTransaction || tx instanceof BusTransaction)" Note: the only change (addition) is '|| tx instanceof BusTransaction', to allow our transaction class to also bind. One option is that we can defer this testing now and re-test once the patch for o/s issues arrive. However, we will still get the transaction binding issue due to the api changes in 1.4.4, as reported on case # 00001618 (see more details). As a fallback we would have to use a custom functionality like BusTransactionCompliantJmsMessageReceiver!! In 1.4.4 JmsMessageReceiver.JmsWorker (subclass) binds the incoming JMS transactions with an explicit check on the org.mule.providers.jms.JmsTransaction instances. This is problematic for us as we wrap JmsTransaction with our own custom class. JmsMessageReceiver.JmsWorker.bindTransaction method: protected void bindTransaction(UMOTransaction tx) throws TransactionException else .... Also would be good if you can discuss any alternative approach to do this as ideally we would not be keen on maintaining our own Mule extension i.e. BusTransactionCompliantJmsMessageReceiver, with your Engineers.
Hassan,
Thank you for the additional information. We do plan to fix the issue with doThreading in the upcoming patch, and at that point you should definitely be using the MultiConsumerJmsMessageReceiver (or at least extending that class). With regards to your question about alternative approaches, I've logged case 1642 to track this. I am inquiring with our engineers. I suspect it's not possible out of the box, but will see what comes back. If necessary, I will file an enhancement request to add more flexibility to receivers in future versions, so other transaction classes can be supported. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Blocker
Error: javax.jms.JMSException: MQJMS1013: operation invalid whilst session is using asynchronous delivery 
The closest related mention of async delivery is on page 60 of the jms 1.1 (pdf) spec, in the note on the page: