Attachment: Added: bpm_orchestration1.tar

Attachment: Added: server.log.gz

Trying a diff approach to configuring this...

http://www.jboss.org/community/docs/DOC-12535

The second (the recommended approach) for integration does not work as the deployment fails with the given exception

2009-03-25 04:54:36,573 DEBUG [org.jboss.soa.esb.listeners.message.MessageAwareListener] Courier Exception
org.jboss.soa.esb.couriers.CourierException: Unable to create Message Consumer
        at org.jboss.internal.soa.esb.couriers.JmsCourier.pickupPayload(JmsCourier.java:419)
        at org.jboss.internal.soa.esb.couriers.JmsCourier.pickup(JmsCourier.java:399)
        at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.pickup(TwoWayCourierImpl.java:228)
        at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.pickup(TwoWayCourierImpl.java:204)
        at org.jboss.soa.esb.listeners.message.MessageAwareListener.waitForEventAndProcess(MessageAwareListener.java:294)
        at org.jboss.soa.esb.listeners.message.MessageAwareListener.doRun(MessageAwareListener.java:250)
        at org.jboss.soa.esb.listeners.lifecycle.AbstractThreadedManagedLifecycle.run(AbstractThreadedManagedLifecycle.java:115)
        at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.soa.esb.couriers.CourierServiceBindException: Failed to get JMS Session from pool.
        at org.jboss.internal.soa.esb.couriers.JmsCourier.getJmsSession(JmsCourier.java:162)
        at org.jboss.internal.soa.esb.couriers.JmsCourier.createMessageConsumer(JmsCourier.java:497)
        at org.jboss.internal.soa.esb.couriers.JmsCourier.pickupPayload(JmsCourier.java:411)
        ... 7 more
Caused by: javax.jms.JMSException: MQJCA1018:Only one session per connection allowed.
        at com.ibm.mq.connector.services.JCAExceptionBuilder.buildException(JCAExceptionBuilder.java:113)
        at com.ibm.mq.connector.services.JCAExceptionBuilder.buildException(JCAExceptionBuilder.java:78)
        at com.ibm.mq.connector.outbound.ConnectionWrapper.createSession(ConnectionWrapper.java:96)
        at org.jboss.internal.soa.esb.rosetta.pooling.JmsConnectionPool$1.call(JmsConnectionPool.java:172)
        at org.jboss.internal.soa.esb.rosetta.pooling.JmsConnectionPool$1.call(JmsConnectionPool.java:165)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
        at java.util.concurrent.FutureTask.run(FutureTask.java:123)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        ... 1 more
Thus if the older approach does not work on CP and the new one does not work too we cannot integrate SOA-P with WSMQ at all now

Attachment: Added: queue-service.xml

Attachment: Added: bpmo1-wsmq-second-approach.tar

Attachment: Added: wsmq-jms-ds.xml

I was involved with a WMQ related support request some time back: https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=245535&gid=1369&view_type=lifo50

It was a bit of a pain in the head to sort out, but we eventually got it working for them.  As part of that, we had to write some WMQ specific code.  I bundled all of this in a quickstart, which is attached here and on the case (helloworld_wmq.zip).

Here were the comments I added, with the attachment, to the case (see Event posted 01-27-2009 10:05pm GMT by tfennell):

--------------------------------------------------------------------------------------------------------------------------------

Hi guys.

Here's another "installement" on this.  It contains the JCA inflow changes.  Everything in this QS is now using WMQ.

Before building, please make sure the follow jars are in the lib folder:
   1. dhbcore.jar
   2. com.ibm.mqjms.jar
   3. com.ibm.mq.jar

Run "ant jarwrapper".  It creates a jar containing the wrapper code.  You need to copy this into the server lib (e.g. server/default/lib) and restart the server.

This QS needs a few queues to be confgured on WMW: "WMQGATEWAY", "WMQESBAWARE" and "ACTION_REQUEST_2".

Hope it helps.

T. 

Attachment: Added: helloworld_wmq.zip

Thanks Tm - That's interesting - the wiki page here: 
http://www.jboss.org/community/docs/DOC-12535 

Explicitly said to remove these jars from the server/lib dir - to avoid class collisions...

   1. dhbcore.jar
   2. com.ibm.mqjms.jar
   3. com.ibm.mq.jar 

Right, but before that, and related to it, it said "If migrating from an existing IBM WebSphere MQ installation on JBoss" ;)

I think that comment is specific to those using the JCA adapter only... I think in our cause, we were also using WMQ through the JMS API (via the JMSRouter).  So yes... you may not need them if you're using WMQ via JCA only.

I've added this as a "known issue" to the release notes and referred people to http://www.jboss.org/community/docs/DOC-13455 as per the last comment

Guys... did we try the quickstart I attached?

I don't exactly remember why, but I know I had to add those jars to the server/lib.  I think they were required there si as to use the JMSRouter (non-JCA).  So as I said above, you may not need them *if you're using WMQ via JCA only*.  Otherwise, I think they are needed.

I second what Kev says there... what I provided there was just a quick fix to get the current codebase working with WMQ for that customer.

I think that in order to support WMQ properly, we really need to go back over what I did there and break out a list of formal tasks re handling this properly, in a released version of the ESB.  I had to do quite a bit of messing about to get it working.  There's probably more than just the WMQInitialContextFactory.  One or two issues I discovered, at the time, have since been fixed in the codebase, but there may be others in there that we need to loop back on.

Link: Added: This issue depends SOA-1261

Link: Added: This issue depends SOA-1262

The issue you are seeing is a consequence of an assumption made in JMSEpr, that the destination name is the full path embedded within the URI.

The destination being taken from that URI is, therefore, SYSTEM.DEF.SVRCONN/queue/pt_bpmo1_start_esb rather than queue/pt_bpmo1_start_esb.

I will add this to the list of tasks needing to be done for MQ integration.

Link: Added: This issue related SOA-1268

Files referenced in https://jira.jboss.org/jira/browse/SOA-1247?focusedCommentId=12460157#action_12460157

Attachment: Added: April1_SOA-1247.tar

The bug we are currently seeing is the setting of maxMessages based on the thread count.

The reason this used to work was because of a bug in the app server codebase which has since been fixed, setting maxMessages used to set maxSession :(

The app server bug is JBPAPP-1045.

We need to change our mappers to use maxSession instead of maxMessages.

Link: Added: This issue depends JBESB-2510

JBESB-2510 covers the fix for this release.

Link: Added: This issue depends JBPAPP-1045

Verified fixed in 4.3 CP01 CR6 - the quickstart now deploys - identically - with 4.3 GA and 4.3 CP01

In 4.3 CP01 CR6

Verified fixed in 4.3 CP01 CR6

Setting new "Affects Testing, Regression, Blocks Testing Fields"

Setting new "Affects Testing, Regression, Blocks Testing Fields"

Blocked Tests: Added: Testing with IBM MQ
Affects Testing?: Added: [Regression?, Blocks Testing?]

Re-closing after setting new "Affects Testing, Regression, Blocks Testing Fields"

Edited to match changes in 'affects testing' fields  (? character removed from field names for easier querying)

Affects Testing: Removed: [Blocks Testing?, Regression?] Added: [Regression, Blocks Testing]