RE: JMSJCA, CAPS 6.2, WebSphere MQ 7
|
|
Frank Kieviet
|
Hi sysprv,
I would hope that IBM would provide complete backwards compatibility, so you could copy the WMQ jars (com.ibm.mqjms.jar, com.ibm.mq.jar, com.ibm.mqetclient.jar and dhbcore.jar if I remember correctly) into the lib directory, and try to use a wmq://xxxx connection URL. If that works, at least we know how to programmatically create the "naked" factories. Next we can figure out how to bind them into JNDI. Before we go there, would using the wmq:// URL work for you? Or is it something particular you hope to get out of the JNDI? If so, could you elaborate on that a little bit? Frank > -----Original Message----- > From: ioj [mailto:[hidden email]] > Sent: Monday, November 02, 2009 10:31 > To: [hidden email] > Cc: [hidden email]; [hidden email] > Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > > Hi! > > Yes, that's exactly what I tried to do; our developers are chummy with > STCMS and GF MQ; but for some applications we in ops would rather use > WMQ. Hence this. And we need WMQ >= 7.0.1 (multi-instance queue managers). > > > Our company's merely an IBM customer; the other way I know of to get WMQ > is the 90 day trial :) > I'll check with IBM on this; perhaps Sun already has some partnership or > agreement with IBM? > > > Yep, I'm in contact with Jason, and bug him from time to time. > > > I have access to test systems with WMQ and GF (CAPS only, not OpenESB) > running on RHEL and AIX. And time too. > > > No problem with moving to OpenESB-users; I just considered this to be > very JMSJCA-specific. > > > Apart from explicit WMQ7 support (which would be very nice, as WMQ has > become much more JMS-like since v6), how would one go about setting up > naked factories? > > > > /sysprv > > > Frank Kieviet wrote: > > Hi sysprv, > > > > From what you're describing it looks like you're deploying the IBM RAR > into > > GlassFish, then bind its connection factories into JNDI, and then use > JMSJCA > > to look them up. > > > > If that's the case, the issue with that is that the RAR has a lot of > > functionality to start/stop transactions, participate in connection > pooling > > etc. To the application, the RAR exposes only application connection > > factories. In practical terms, these are non-XA connection factories. In > > other words, the factories that the RAR exposes to the application are > > wrappers around the "naked" connection factories, and these wrappers add > a > > lot of functionality. > > > > What JMSJCA needs are the "naked" connection factories. What I mean with > > that are the factories that provide a direct line of communication > between > > the calling code and the JMS server, of course all using the JMS api. > > > > So, to make it work with JNDI, you would have to instantiate the WMQ > "naked" > > factories, bind them into JNDI (e.g. a file provider if WMQ 7 did not > any > > new facilities such as a built-in JNDI server), and use those in JMSJCA. > > > > We're looking into adding explicit support for WMQ7. First issue we ran > into > > is how to get a copy of WMQ7. Do you know by any chance? > > > > BTW, are you in contact with Jason Baragry? > > > > One more thing: would you mind if we move this discussion to the OpenESB > > users list? > > > > Frank > > > > Frank Kieviet > > Senior Staff Engineer, SOA/BI > > Sun Microsystems, Monrovia, CA > > Tel +1 626 471 6322 > > Blog: http://frankkieviet.blogspot.com/ > > > > > > > >> -----Original Message----- > >> From: ioj [mailto:[hidden email]] > >> Sent: Monday, November 02, 2009 08:44 > >> To: [hidden email] > >> Subject: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >> > >> Hi Frank :) > >> > >> Configured a JMSJCA-driven JCD in jndi:// mode to connect to a > WebSphere > >> MQ 7 queue; Getting this error: > >> > >> [#|2009-11-02T17:09:55.496+0100|INFO|sun- > >> > appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=18;_Threa > >> dName=httpWorkerThread-4848-4;dpJMSJCATest_1_0_0;|LDR5010: > >> All ejb(s) of [dpJMSJCATest_1_0_0] loaded successfully!|#] > >> > >> [#|2009-11-02T17:09:55.498+0100|WARNING|sun- > >> > appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=25;_ThreadName=JMSJC > >> A > >> connect;Context=TestProjects | > >> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=07fb37e9-63b3- > 4015- > >> a035-dcc50c47ac93;|JMSJCA-E016: > >> [serial-QueueReceiver(QJMSJCATEST){TestProjects | > >> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message > >> delivery initiation failed (attempt #1); will retry in 1 seconds. The > >> error was: com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl > >> cannot be cast to javax.jms.XAQueueConnectionFactory > >> java.lang.ClassCastException: > >> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl cannot be cast > >> to javax.jms.XAQueueConnectionFactory > >> at > >> > com.stc.jmsjca.jndi.RAJNDIObjectFactory.createConnectionFactory(RAJNDIObje > >> ctFactory.java:208) > >> at com.stc.jmsjca.core.SerialDelivery.start(SerialDelivery.java:74) > >> at com.stc.jmsjca.core.Activation.asyncStart(Activation.java:552) > >> at com.stc.jmsjca.core.Activation.access$000(Activation.java:81) > >> at com.stc.jmsjca.core.Activation$1.run(Activation.java:347) > >> at java.lang.Thread.run(Thread.java:619) > >> |#] > >> > >> > >> > >> Details: > >> > >> I've installed and configured the WMQ 7 RA from IBM in GlassFish > >> Enterprise v2.1 Patch 02. The IVT (installation verification test) app > >> from IBM runs fine and passes all tests. > >> > >> Next, I have the simplest message driven JCD you can think of: it reads > >> a TextMessage using JMSJCA and writes the Text to the server.log. Works > >> fine with GlassFish MQ. > >> > >> Then I have a connector connection pool of type QueueConnectionFactory, > >> using the IBM RA, configured for XA (Transaction Support: > XATransaction) > >> > >> When I configure JMSJCA (inside GF, with the Env overrides in CAPS 6.x) > >> with: > >> > >> Connection URL: jndi:// > >> JMSJCA.NoXA=false > >> JMSJCA.QueueCF=jms/wmq/xa/qcf > >> > >> and enable the JCD, I get the message above. > >> > >> I've made sure that the MQ transaction support jar is available to the > >> appserver etc. etc. (the IVT passes all tests incl. transactions - > >> though it's much simpler than a JCD with JMSJCA +) > >> > >> What's going wrong here, and how can it be fixed? > >> > >> > >> Thanks in advance! > >> /sysprv > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [hidden email] > >> For additional commands, e-mail: [hidden email] > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [hidden email] > > For additional commands, e-mail: [hidden email] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
sysprv
|
Hi Frank, Yes, as expected, with wmq:// the JCD can connect to the queue manager without any problems. The multi-instance queue manager feature (new in v7.0.1) is important to us; at first glance that means using MQConnectionFactory.setClientReconnectHosts(); Can JMSJCA set properties it does not know about? I'll investigate this more tomorrow. Apart from that, I expected better performance; just an uneducated guess. Now I'm interested in these "naked" factories just for the sake of knowing :) /sysprv Frank Kieviet wrote: > Hi sysprv, > > I would hope that IBM would provide complete backwards compatibility, so you > could copy the WMQ jars (com.ibm.mqjms.jar, com.ibm.mq.jar, > com.ibm.mqetclient.jar and dhbcore.jar if I remember correctly) into the lib > directory, and try to use a wmq://xxxx connection URL. If that works, at > least we know how to programmatically create the "naked" factories. Next we > can figure out how to bind them into JNDI. Before we go there, would using > the wmq:// URL work for you? Or is it something particular you hope to get > out of the JNDI? If so, could you elaborate on that a little bit? > > Frank > > >> -----Original Message----- >> From: ioj [mailto:[hidden email]] >> Sent: Monday, November 02, 2009 10:31 >> To: [hidden email] >> Cc: [hidden email]; [hidden email] >> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >> >> Hi! >> >> Yes, that's exactly what I tried to do; our developers are chummy with >> STCMS and GF MQ; but for some applications we in ops would rather use >> WMQ. Hence this. And we need WMQ >= 7.0.1 (multi-instance queue managers). >> >> >> Our company's merely an IBM customer; the other way I know of to get WMQ >> is the 90 day trial :) >> I'll check with IBM on this; perhaps Sun already has some partnership or >> agreement with IBM? >> >> >> Yep, I'm in contact with Jason, and bug him from time to time. >> >> >> I have access to test systems with WMQ and GF (CAPS only, not OpenESB) >> running on RHEL and AIX. And time too. >> >> >> No problem with moving to OpenESB-users; I just considered this to be >> very JMSJCA-specific. >> >> >> Apart from explicit WMQ7 support (which would be very nice, as WMQ has >> become much more JMS-like since v6), how would one go about setting up >> naked factories? >> >> >> >> /sysprv >> >> >> Frank Kieviet wrote: >>> Hi sysprv, >>> >>> From what you're describing it looks like you're deploying the IBM RAR >> into >>> GlassFish, then bind its connection factories into JNDI, and then use >> JMSJCA >>> to look them up. >>> >>> If that's the case, the issue with that is that the RAR has a lot of >>> functionality to start/stop transactions, participate in connection >> pooling >>> etc. To the application, the RAR exposes only application connection >>> factories. In practical terms, these are non-XA connection factories. In >>> other words, the factories that the RAR exposes to the application are >>> wrappers around the "naked" connection factories, and these wrappers add >> a >>> lot of functionality. >>> >>> What JMSJCA needs are the "naked" connection factories. What I mean with >>> that are the factories that provide a direct line of communication >> between >>> the calling code and the JMS server, of course all using the JMS api. >>> >>> So, to make it work with JNDI, you would have to instantiate the WMQ >> "naked" >>> factories, bind them into JNDI (e.g. a file provider if WMQ 7 did not >> any >>> new facilities such as a built-in JNDI server), and use those in JMSJCA. >>> >>> We're looking into adding explicit support for WMQ7. First issue we ran >> into >>> is how to get a copy of WMQ7. Do you know by any chance? >>> >>> BTW, are you in contact with Jason Baragry? >>> >>> One more thing: would you mind if we move this discussion to the OpenESB >>> users list? >>> >>> Frank >>> >>> Frank Kieviet >>> Senior Staff Engineer, SOA/BI >>> Sun Microsystems, Monrovia, CA >>> Tel +1 626 471 6322 >>> Blog: http://frankkieviet.blogspot.com/ >>> >>> >>> >>>> -----Original Message----- >>>> From: ioj [mailto:[hidden email]] >>>> Sent: Monday, November 02, 2009 08:44 >>>> To: [hidden email] >>>> Subject: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>> >>>> Hi Frank :) >>>> >>>> Configured a JMSJCA-driven JCD in jndi:// mode to connect to a >> WebSphere >>>> MQ 7 queue; Getting this error: >>>> >>>> [#|2009-11-02T17:09:55.496+0100|INFO|sun- >>>> >> appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=18;_Threa >>>> dName=httpWorkerThread-4848-4;dpJMSJCATest_1_0_0;|LDR5010: >>>> All ejb(s) of [dpJMSJCATest_1_0_0] loaded successfully!|#] >>>> >>>> [#|2009-11-02T17:09:55.498+0100|WARNING|sun- >>>> >> appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=25;_ThreadName=JMSJC >>>> A >>>> connect;Context=TestProjects | >>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=07fb37e9-63b3- >> 4015- >>>> a035-dcc50c47ac93;|JMSJCA-E016: >>>> [serial-QueueReceiver(QJMSJCATEST){TestProjects | >>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message >>>> delivery initiation failed (attempt #1); will retry in 1 seconds. The >>>> error was: com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl >>>> cannot be cast to javax.jms.XAQueueConnectionFactory >>>> java.lang.ClassCastException: >>>> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl cannot be cast >>>> to javax.jms.XAQueueConnectionFactory >>>> at >>>> >> com.stc.jmsjca.jndi.RAJNDIObjectFactory.createConnectionFactory(RAJNDIObje >>>> ctFactory.java:208) >>>> at com.stc.jmsjca.core.SerialDelivery.start(SerialDelivery.java:74) >>>> at com.stc.jmsjca.core.Activation.asyncStart(Activation.java:552) >>>> at com.stc.jmsjca.core.Activation.access$000(Activation.java:81) >>>> at com.stc.jmsjca.core.Activation$1.run(Activation.java:347) >>>> at java.lang.Thread.run(Thread.java:619) >>>> |#] >>>> >>>> >>>> >>>> Details: >>>> >>>> I've installed and configured the WMQ 7 RA from IBM in GlassFish >>>> Enterprise v2.1 Patch 02. The IVT (installation verification test) app >>>> from IBM runs fine and passes all tests. >>>> >>>> Next, I have the simplest message driven JCD you can think of: it reads >>>> a TextMessage using JMSJCA and writes the Text to the server.log. Works >>>> fine with GlassFish MQ. >>>> >>>> Then I have a connector connection pool of type QueueConnectionFactory, >>>> using the IBM RA, configured for XA (Transaction Support: >> XATransaction) >>>> When I configure JMSJCA (inside GF, with the Env overrides in CAPS 6.x) >>>> with: >>>> >>>> Connection URL: jndi:// >>>> JMSJCA.NoXA=false >>>> JMSJCA.QueueCF=jms/wmq/xa/qcf >>>> >>>> and enable the JCD, I get the message above. >>>> >>>> I've made sure that the MQ transaction support jar is available to the >>>> appserver etc. etc. (the IVT passes all tests incl. transactions - >>>> though it's much simpler than a JCD with JMSJCA +) >>>> >>>> What's going wrong here, and how can it be fixed? >>>> >>>> >>>> Thanks in advance! >>>> /sysprv >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [hidden email] >>>> For additional commands, e-mail: [hidden email] >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [hidden email] >>> For additional commands, e-mail: [hidden email] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
|
Frank Kieviet
|
Hi sysprv,
> The multi-instance queue manager feature (new in v7.0.1) is important to > us; at first glance that means using > MQConnectionFactory.setClientReconnectHosts(); > Can JMSJCA set properties it does not know about? I'll investigate this > more tomorrow. Recently we added a new feature to the WMQ support in JMSJCA that will allow you to set arbitrary properties on the factory. See http://wiki.open-esb.java.net/Wiki.jsp?page=JMSJCAReadme#section-JMSJCAReadm e-SupportForWebSphereMQMQSeries, where you'll find this: <Quote> The com.ibm.mq.jms.MQConnectionFactory has a large list of properties of type boolean, int, long, String, URL which can be set. The setter can be invoked by specifying a connection URL option named using the following convention: remove the 'set' prefix from the name of the setter method and prepend 'WMQ_', e.g. * setMessageRetention(int): WMQ_MessageRetention=1 * setSecurityExit(String): WMQ_SecurityExit=wmq.exits.MySecurityExit * setSparseSubscriptions(boolean): WMQ_SparseSubscriptions=true </Quote> > Now I'm interested in these "naked" factories just for the sake of > knowing :) You could write a small Java program that instantiates the factories, and then bind these factories into JNDI. The JNDI provider could a file provider so that you'll end up with a file that has a serialized connection factory in there. You can then tell JMSJCA to use this JNDI file provider to read the file, deserialize the factory, and as such obtain an instance of the factory. This small Java program that would initially instantiate the factories would simply call new com.ibm.mq.jms.MQConnectionFactory() and set some properties on this factory. BTW, if you're going down this road, also set JMSJCA.overrideissamerm=true to workaround an issue in GlassFish/WMQ where GlassFish tries to join an XA resource onto a suspended XA resource. Frank > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On > Behalf Of ioj > Sent: Monday, November 02, 2009 11:20 > To: [hidden email] > Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > > > Hi Frank, > > Yes, as expected, with wmq:// the JCD can connect to the queue manager > without any problems. > > > The multi-instance queue manager feature (new in v7.0.1) is important to > us; at first glance that means using > MQConnectionFactory.setClientReconnectHosts(); > Can JMSJCA set properties it does not know about? I'll investigate this > more tomorrow. > > > Apart from that, I expected better performance; just an uneducated guess. > > > Now I'm interested in these "naked" factories just for the sake of > knowing :) > > > /sysprv > > > Frank Kieviet wrote: > > Hi sysprv, > > > > I would hope that IBM would provide complete backwards compatibility, so > you > > could copy the WMQ jars (com.ibm.mqjms.jar, com.ibm.mq.jar, > > com.ibm.mqetclient.jar and dhbcore.jar if I remember correctly) into the > lib > > directory, and try to use a wmq://xxxx connection URL. If that works, at > > least we know how to programmatically create the "naked" factories. Next > we > > can figure out how to bind them into JNDI. Before we go there, would > using > > the wmq:// URL work for you? Or is it something particular you hope to > get > > out of the JNDI? If so, could you elaborate on that a little bit? > > > > Frank > > > > > >> -----Original Message----- > >> From: ioj [mailto:[hidden email]] > >> Sent: Monday, November 02, 2009 10:31 > >> To: [hidden email] > >> Cc: [hidden email]; [hidden email] > >> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >> > >> Hi! > >> > >> Yes, that's exactly what I tried to do; our developers are chummy with > >> STCMS and GF MQ; but for some applications we in ops would rather use > >> WMQ. Hence this. And we need WMQ >= 7.0.1 (multi-instance queue > managers). > >> > >> > >> Our company's merely an IBM customer; the other way I know of to get > WMQ > >> is the 90 day trial :) > >> I'll check with IBM on this; perhaps Sun already has some partnership > or > >> agreement with IBM? > >> > >> > >> Yep, I'm in contact with Jason, and bug him from time to time. > >> > >> > >> I have access to test systems with WMQ and GF (CAPS only, not OpenESB) > >> running on RHEL and AIX. And time too. > >> > >> > >> No problem with moving to OpenESB-users; I just considered this to be > >> very JMSJCA-specific. > >> > >> > >> Apart from explicit WMQ7 support (which would be very nice, as WMQ has > >> become much more JMS-like since v6), how would one go about setting up > >> naked factories? > >> > >> > >> > >> /sysprv > >> > >> > >> Frank Kieviet wrote: > >>> Hi sysprv, > >>> > >>> From what you're describing it looks like you're deploying the IBM RAR > >> into > >>> GlassFish, then bind its connection factories into JNDI, and then use > >> JMSJCA > >>> to look them up. > >>> > >>> If that's the case, the issue with that is that the RAR has a lot of > >>> functionality to start/stop transactions, participate in connection > >> pooling > >>> etc. To the application, the RAR exposes only application connection > >>> factories. In practical terms, these are non-XA connection factories. > In > >>> other words, the factories that the RAR exposes to the application are > >>> wrappers around the "naked" connection factories, and these wrappers > add > >> a > >>> lot of functionality. > >>> > >>> What JMSJCA needs are the "naked" connection factories. What I mean > with > >>> that are the factories that provide a direct line of communication > >> between > >>> the calling code and the JMS server, of course all using the JMS api. > >>> > >>> So, to make it work with JNDI, you would have to instantiate the WMQ > >> "naked" > >>> factories, bind them into JNDI (e.g. a file provider if WMQ 7 did not > >> any > >>> new facilities such as a built-in JNDI server), and use those in > JMSJCA. > >>> > >>> We're looking into adding explicit support for WMQ7. First issue we > ran > >> into > >>> is how to get a copy of WMQ7. Do you know by any chance? > >>> > >>> BTW, are you in contact with Jason Baragry? > >>> > >>> One more thing: would you mind if we move this discussion to the > OpenESB > >>> users list? > >>> > >>> Frank > >>> > >>> Frank Kieviet > >>> Senior Staff Engineer, SOA/BI > >>> Sun Microsystems, Monrovia, CA > >>> Tel +1 626 471 6322 > >>> Blog: http://frankkieviet.blogspot.com/ > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: ioj [mailto:[hidden email]] > >>>> Sent: Monday, November 02, 2009 08:44 > >>>> To: [hidden email] > >>>> Subject: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>> > >>>> Hi Frank :) > >>>> > >>>> Configured a JMSJCA-driven JCD in jndi:// mode to connect to a > >> WebSphere > >>>> MQ 7 queue; Getting this error: > >>>> > >>>> [#|2009-11-02T17:09:55.496+0100|INFO|sun- > >>>> > >> > appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=18;_Threa > >>>> dName=httpWorkerThread-4848-4;dpJMSJCATest_1_0_0;|LDR5010: > >>>> All ejb(s) of [dpJMSJCATest_1_0_0] loaded successfully!|#] > >>>> > >>>> [#|2009-11-02T17:09:55.498+0100|WARNING|sun- > >>>> > >> > appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=25;_ThreadName=JMSJC > >>>> A > >>>> connect;Context=TestProjects | > >>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=07fb37e9-63b3- > >> 4015- > >>>> a035-dcc50c47ac93;|JMSJCA-E016: > >>>> [serial-QueueReceiver(QJMSJCATEST){TestProjects | > >>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message > >>>> delivery initiation failed (attempt #1); will retry in 1 seconds. The > >>>> error was: com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl > >>>> cannot be cast to javax.jms.XAQueueConnectionFactory > >>>> java.lang.ClassCastException: > >>>> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl cannot be > cast > >>>> to javax.jms.XAQueueConnectionFactory > >>>> at > >>>> > >> > com.stc.jmsjca.jndi.RAJNDIObjectFactory.createConnectionFactory(RAJNDIObje > >>>> ctFactory.java:208) > >>>> at com.stc.jmsjca.core.SerialDelivery.start(SerialDelivery.java:74) > >>>> at com.stc.jmsjca.core.Activation.asyncStart(Activation.java:552) > >>>> at com.stc.jmsjca.core.Activation.access$000(Activation.java:81) > >>>> at com.stc.jmsjca.core.Activation$1.run(Activation.java:347) > >>>> at java.lang.Thread.run(Thread.java:619) > >>>> |#] > >>>> > >>>> > >>>> > >>>> Details: > >>>> > >>>> I've installed and configured the WMQ 7 RA from IBM in GlassFish > >>>> Enterprise v2.1 Patch 02. The IVT (installation verification test) > app > >>>> from IBM runs fine and passes all tests. > >>>> > >>>> Next, I have the simplest message driven JCD you can think of: it > reads > >>>> a TextMessage using JMSJCA and writes the Text to the server.log. > Works > >>>> fine with GlassFish MQ. > >>>> > >>>> Then I have a connector connection pool of type > QueueConnectionFactory, > >>>> using the IBM RA, configured for XA (Transaction Support: > >> XATransaction) > >>>> When I configure JMSJCA (inside GF, with the Env overrides in CAPS > 6.x) > >>>> with: > >>>> > >>>> Connection URL: jndi:// > >>>> JMSJCA.NoXA=false > >>>> JMSJCA.QueueCF=jms/wmq/xa/qcf > >>>> > >>>> and enable the JCD, I get the message above. > >>>> > >>>> I've made sure that the MQ transaction support jar is available to > the > >>>> appserver etc. etc. (the IVT passes all tests incl. transactions - > >>>> though it's much simpler than a JCD with JMSJCA +) > >>>> > >>>> What's going wrong here, and how can it be fixed? > >>>> > >>>> > >>>> Thanks in advance! > >>>> /sysprv > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [hidden email] > >>>> For additional commands, e-mail: [hidden email] > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [hidden email] > >>> For additional commands, e-mail: [hidden email] > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [hidden email] > >> For additional commands, e-mail: [hidden email] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [hidden email] > > For additional commands, e-mail: [hidden email] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
|
sysprv
|
Frank Kieviet wrote: > Hi sysprv, > >> The multi-instance queue manager feature (new in v7.0.1) is important to >> us; at first glance that means using >> MQConnectionFactory.setClientReconnectHosts(); >> Can JMSJCA set properties it does not know about? I'll investigate this >> more tomorrow. > > Recently we added a new feature to the WMQ support in JMSJCA that will allow > you to set arbitrary properties on the factory. See > http://wiki.open-esb.java.net/Wiki.jsp?page=JMSJCAReadme#section-JMSJCAReadm > e-SupportForWebSphereMQMQSeries, where you'll find this: > > <Quote> > The com.ibm.mq.jms.MQConnectionFactory has a large list of properties of > type boolean, int, long, String, URL which can be set. The setter can be > invoked by specifying a connection URL option named using the following > convention: remove the 'set' prefix from the name of the setter method and > prepend 'WMQ_', e.g. > > * setMessageRetention(int): WMQ_MessageRetention=1 > * setSecurityExit(String): WMQ_SecurityExit=wmq.exits.MySecurityExit > * setSparseSubscriptions(boolean): WMQ_SparseSubscriptions=true > </Quote> > Yes, I checked that page. Great :) >> Now I'm interested in these "naked" factories just for the sake of >> knowing :) > You could write a small Java program that instantiates the factories, and > then bind these factories into JNDI. The JNDI provider could a file provider > so that you'll end up with a file that has a serialized connection factory > in there. You can then tell JMSJCA to use this JNDI file provider to read > the file, deserialize the factory, and as such obtain an instance of the > factory. This small Java program that would initially instantiate the > factories would simply call new com.ibm.mq.jms.MQConnectionFactory() and set > some properties on this factory. > > BTW, if you're going down this road, also set JMSJCA.overrideissamerm=true > to workaround an issue in GlassFish/WMQ where GlassFish tries to join an XA > resource onto a suspended XA resource. > > Frank > A little tool called JMSAdmin comes with WMQ that seems to do just this; I'll try this tomorrow with a RefFSContext. Thank you very much for your help. Now it's clear where I went astray. I'll get back to you and Jason if I hear any good news about acquiring WMQ. /sysprv > > >> -----Original Message----- >> From: [hidden email] >> [mailto:[hidden email]] On >> Behalf Of ioj >> Sent: Monday, November 02, 2009 11:20 >> To: [hidden email] >> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >> >> >> Hi Frank, >> >> Yes, as expected, with wmq:// the JCD can connect to the queue manager >> without any problems. >> >> >> The multi-instance queue manager feature (new in v7.0.1) is important to >> us; at first glance that means using >> MQConnectionFactory.setClientReconnectHosts(); >> Can JMSJCA set properties it does not know about? I'll investigate this >> more tomorrow. >> >> >> Apart from that, I expected better performance; just an uneducated guess. >> >> >> Now I'm interested in these "naked" factories just for the sake of >> knowing :) >> >> >> /sysprv >> >> >> Frank Kieviet wrote: >>> Hi sysprv, >>> >>> I would hope that IBM would provide complete backwards compatibility, so >> you >>> could copy the WMQ jars (com.ibm.mqjms.jar, com.ibm.mq.jar, >>> com.ibm.mqetclient.jar and dhbcore.jar if I remember correctly) into the >> lib >>> directory, and try to use a wmq://xxxx connection URL. If that works, at >>> least we know how to programmatically create the "naked" factories. Next >> we >>> can figure out how to bind them into JNDI. Before we go there, would >> using >>> the wmq:// URL work for you? Or is it something particular you hope to >> get >>> out of the JNDI? If so, could you elaborate on that a little bit? >>> >>> Frank >>> >>> >>>> -----Original Message----- >>>> From: ioj [mailto:[hidden email]] >>>> Sent: Monday, November 02, 2009 10:31 >>>> To: [hidden email] >>>> Cc: [hidden email]; [hidden email] >>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>> >>>> Hi! >>>> >>>> Yes, that's exactly what I tried to do; our developers are chummy with >>>> STCMS and GF MQ; but for some applications we in ops would rather use >>>> WMQ. Hence this. And we need WMQ >= 7.0.1 (multi-instance queue >> managers). >>>> >>>> Our company's merely an IBM customer; the other way I know of to get >> WMQ >>>> is the 90 day trial :) >>>> I'll check with IBM on this; perhaps Sun already has some partnership >> or >>>> agreement with IBM? >>>> >>>> >>>> Yep, I'm in contact with Jason, and bug him from time to time. >>>> >>>> >>>> I have access to test systems with WMQ and GF (CAPS only, not OpenESB) >>>> running on RHEL and AIX. And time too. >>>> >>>> >>>> No problem with moving to OpenESB-users; I just considered this to be >>>> very JMSJCA-specific. >>>> >>>> >>>> Apart from explicit WMQ7 support (which would be very nice, as WMQ has >>>> become much more JMS-like since v6), how would one go about setting up >>>> naked factories? >>>> >>>> >>>> >>>> /sysprv >>>> >>>> >>>> Frank Kieviet wrote: >>>>> Hi sysprv, >>>>> >>>>> From what you're describing it looks like you're deploying the IBM RAR >>>> into >>>>> GlassFish, then bind its connection factories into JNDI, and then use >>>> JMSJCA >>>>> to look them up. >>>>> >>>>> If that's the case, the issue with that is that the RAR has a lot of >>>>> functionality to start/stop transactions, participate in connection >>>> pooling >>>>> etc. To the application, the RAR exposes only application connection >>>>> factories. In practical terms, these are non-XA connection factories. >> In >>>>> other words, the factories that the RAR exposes to the application are >>>>> wrappers around the "naked" connection factories, and these wrappers >> add >>>> a >>>>> lot of functionality. >>>>> >>>>> What JMSJCA needs are the "naked" connection factories. What I mean >> with >>>>> that are the factories that provide a direct line of communication >>>> between >>>>> the calling code and the JMS server, of course all using the JMS api. >>>>> >>>>> So, to make it work with JNDI, you would have to instantiate the WMQ >>>> "naked" >>>>> factories, bind them into JNDI (e.g. a file provider if WMQ 7 did not >>>> any >>>>> new facilities such as a built-in JNDI server), and use those in >> JMSJCA. >>>>> We're looking into adding explicit support for WMQ7. First issue we >> ran >>>> into >>>>> is how to get a copy of WMQ7. Do you know by any chance? >>>>> >>>>> BTW, are you in contact with Jason Baragry? >>>>> >>>>> One more thing: would you mind if we move this discussion to the >> OpenESB >>>>> users list? >>>>> >>>>> Frank >>>>> >>>>> Frank Kieviet >>>>> Senior Staff Engineer, SOA/BI >>>>> Sun Microsystems, Monrovia, CA >>>>> Tel +1 626 471 6322 >>>>> Blog: http://frankkieviet.blogspot.com/ >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ioj [mailto:[hidden email]] >>>>>> Sent: Monday, November 02, 2009 08:44 >>>>>> To: [hidden email] >>>>>> Subject: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>>>> >>>>>> Hi Frank :) >>>>>> >>>>>> Configured a JMSJCA-driven JCD in jndi:// mode to connect to a >>>> WebSphere >>>>>> MQ 7 queue; Getting this error: >>>>>> >>>>>> [#|2009-11-02T17:09:55.496+0100|INFO|sun- >>>>>> >> appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=18;_Threa >>>>>> dName=httpWorkerThread-4848-4;dpJMSJCATest_1_0_0;|LDR5010: >>>>>> All ejb(s) of [dpJMSJCATest_1_0_0] loaded successfully!|#] >>>>>> >>>>>> [#|2009-11-02T17:09:55.498+0100|WARNING|sun- >>>>>> >> appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=25;_ThreadName=JMSJC >>>>>> A >>>>>> connect;Context=TestProjects | >>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=07fb37e9-63b3- >>>> 4015- >>>>>> a035-dcc50c47ac93;|JMSJCA-E016: >>>>>> [serial-QueueReceiver(QJMSJCATEST){TestProjects | >>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message >>>>>> delivery initiation failed (attempt #1); will retry in 1 seconds. The >>>>>> error was: com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl >>>>>> cannot be cast to javax.jms.XAQueueConnectionFactory >>>>>> java.lang.ClassCastException: >>>>>> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl cannot be >> cast >>>>>> to javax.jms.XAQueueConnectionFactory >>>>>> at >>>>>> >> com.stc.jmsjca.jndi.RAJNDIObjectFactory.createConnectionFactory(RAJNDIObje >>>>>> ctFactory.java:208) >>>>>> at com.stc.jmsjca.core.SerialDelivery.start(SerialDelivery.java:74) >>>>>> at com.stc.jmsjca.core.Activation.asyncStart(Activation.java:552) >>>>>> at com.stc.jmsjca.core.Activation.access$000(Activation.java:81) >>>>>> at com.stc.jmsjca.core.Activation$1.run(Activation.java:347) >>>>>> at java.lang.Thread.run(Thread.java:619) >>>>>> |#] >>>>>> >>>>>> >>>>>> >>>>>> Details: >>>>>> >>>>>> I've installed and configured the WMQ 7 RA from IBM in GlassFish >>>>>> Enterprise v2.1 Patch 02. The IVT (installation verification test) >> app >>>>>> from IBM runs fine and passes all tests. >>>>>> >>>>>> Next, I have the simplest message driven JCD you can think of: it >> reads >>>>>> a TextMessage using JMSJCA and writes the Text to the server.log. >> Works >>>>>> fine with GlassFish MQ. >>>>>> >>>>>> Then I have a connector connection pool of type >> QueueConnectionFactory, >>>>>> using the IBM RA, configured for XA (Transaction Support: >>>> XATransaction) >>>>>> When I configure JMSJCA (inside GF, with the Env overrides in CAPS >> 6.x) >>>>>> with: >>>>>> >>>>>> Connection URL: jndi:// >>>>>> JMSJCA.NoXA=false >>>>>> JMSJCA.QueueCF=jms/wmq/xa/qcf >>>>>> >>>>>> and enable the JCD, I get the message above. >>>>>> >>>>>> I've made sure that the MQ transaction support jar is available to >> the >>>>>> appserver etc. etc. (the IVT passes all tests incl. transactions - >>>>>> though it's much simpler than a JCD with JMSJCA +) >>>>>> >>>>>> What's going wrong here, and how can it be fixed? >>>>>> >>>>>> >>>>>> Thanks in advance! >>>>>> /sysprv >>>>>> --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
|
sysprv
|
In reply to this post
by Frank Kieviet
Hi! I've done a little more testing with JMSJCA jndi://, MQ 7 and a simple JCD. The JCD is strictly a consumer, and the CAPS classic documentation tells us that means it works under a XA transaction. This is my JMSJCA configuration (env object): Connection URL: jndi:// Options: JMSJCA.NoXA=false JMSJCA.overrideissamerm=true JMSJCA.QueueCF=centos_QM1_xaqcf java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory java.naming.provider.url=file:/var/mqm/jndictx centos_QM1_xaqcf is defined as a MQXAQueueConnectionFactory. When I enable the application, it doesn't receive any messages from the queue... When I disable the application, I see this in the GlassFish logs: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2009' ('MQRC_CONNECTION_BROKEN'). The MQ queue manager reports unexpected errors (I'll take these up with IBM when I'm more clear on what I'm doing), and dumps First Failure Symptom Reports; yet, its "Connection History" has Reason 2072 (MQRC_SYNCPOINT_NOT_AVAILABLE) and before that Reason 30737 (lpiRC_WAITCANCELLED_ASYNCCONSUME). Am I configuring JMSJCA wrong? Some more test configurations and results: Non-XA connection factory, JMSJCA.NoXA=false := JCD works as expected (emulated-XA?) XA connection factory, JMSJCA.NoXA=false := JCD works as expected Non-XA connection factory, JMSJCA.NoXA=true := Obvious, MQConnectionFactory can't be cast to XAConnectionFactory Non-XA connection factory, JMSJCA.NoXA=true := above :) Thanks in advance, /sysprv Frank Kieviet wrote: > Hi sysprv, > >> The multi-instance queue manager feature (new in v7.0.1) is important to >> us; at first glance that means using >> MQConnectionFactory.setClientReconnectHosts(); >> Can JMSJCA set properties it does not know about? I'll investigate this >> more tomorrow. > > Recently we added a new feature to the WMQ support in JMSJCA that will allow > you to set arbitrary properties on the factory. See > http://wiki.open-esb.java.net/Wiki.jsp?page=JMSJCAReadme#section-JMSJCAReadm > e-SupportForWebSphereMQMQSeries, where you'll find this: > > <Quote> > The com.ibm.mq.jms.MQConnectionFactory has a large list of properties of > type boolean, int, long, String, URL which can be set. The setter can be > invoked by specifying a connection URL option named using the following > convention: remove the 'set' prefix from the name of the setter method and > prepend 'WMQ_', e.g. > > * setMessageRetention(int): WMQ_MessageRetention=1 > * setSecurityExit(String): WMQ_SecurityExit=wmq.exits.MySecurityExit > * setSparseSubscriptions(boolean): WMQ_SparseSubscriptions=true > </Quote> > >> Now I'm interested in these "naked" factories just for the sake of >> knowing :) > You could write a small Java program that instantiates the factories, and > then bind these factories into JNDI. The JNDI provider could a file provider > so that you'll end up with a file that has a serialized connection factory > in there. You can then tell JMSJCA to use this JNDI file provider to read > the file, deserialize the factory, and as such obtain an instance of the > factory. This small Java program that would initially instantiate the > factories would simply call new com.ibm.mq.jms.MQConnectionFactory() and set > some properties on this factory. > > BTW, if you're going down this road, also set JMSJCA.overrideissamerm=true > to workaround an issue in GlassFish/WMQ where GlassFish tries to join an XA > resource onto a suspended XA resource. > > Frank > > > >> -----Original Message----- >> From: [hidden email] >> [mailto:[hidden email]] On >> Behalf Of ioj >> Sent: Monday, November 02, 2009 11:20 >> To: [hidden email] >> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >> >> >> Hi Frank, >> >> Yes, as expected, with wmq:// the JCD can connect to the queue manager >> without any problems. >> >> >> The multi-instance queue manager feature (new in v7.0.1) is important to >> us; at first glance that means using >> MQConnectionFactory.setClientReconnectHosts(); >> Can JMSJCA set properties it does not know about? I'll investigate this >> more tomorrow. >> >> >> Apart from that, I expected better performance; just an uneducated guess. >> >> >> Now I'm interested in these "naked" factories just for the sake of >> knowing :) >> >> >> /sysprv >> >> >> Frank Kieviet wrote: >>> Hi sysprv, >>> >>> I would hope that IBM would provide complete backwards compatibility, so >> you >>> could copy the WMQ jars (com.ibm.mqjms.jar, com.ibm.mq.jar, >>> com.ibm.mqetclient.jar and dhbcore.jar if I remember correctly) into the >> lib >>> directory, and try to use a wmq://xxxx connection URL. If that works, at >>> least we know how to programmatically create the "naked" factories. Next >> we >>> can figure out how to bind them into JNDI. Before we go there, would >> using >>> the wmq:// URL work for you? Or is it something particular you hope to >> get >>> out of the JNDI? If so, could you elaborate on that a little bit? >>> >>> Frank >>> >>> >>>> -----Original Message----- >>>> From: ioj [mailto:[hidden email]] >>>> Sent: Monday, November 02, 2009 10:31 >>>> To: [hidden email] >>>> Cc: [hidden email]; [hidden email] >>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>> >>>> Hi! >>>> >>>> Yes, that's exactly what I tried to do; our developers are chummy with >>>> STCMS and GF MQ; but for some applications we in ops would rather use >>>> WMQ. Hence this. And we need WMQ >= 7.0.1 (multi-instance queue >> managers). >>>> >>>> Our company's merely an IBM customer; the other way I know of to get >> WMQ >>>> is the 90 day trial :) >>>> I'll check with IBM on this; perhaps Sun already has some partnership >> or >>>> agreement with IBM? >>>> >>>> >>>> Yep, I'm in contact with Jason, and bug him from time to time. >>>> >>>> >>>> I have access to test systems with WMQ and GF (CAPS only, not OpenESB) >>>> running on RHEL and AIX. And time too. >>>> >>>> >>>> No problem with moving to OpenESB-users; I just considered this to be >>>> very JMSJCA-specific. >>>> >>>> >>>> Apart from explicit WMQ7 support (which would be very nice, as WMQ has >>>> become much more JMS-like since v6), how would one go about setting up >>>> naked factories? >>>> >>>> >>>> >>>> /sysprv >>>> >>>> >>>> Frank Kieviet wrote: >>>>> Hi sysprv, >>>>> >>>>> From what you're describing it looks like you're deploying the IBM RAR >>>> into >>>>> GlassFish, then bind its connection factories into JNDI, and then use >>>> JMSJCA >>>>> to look them up. >>>>> >>>>> If that's the case, the issue with that is that the RAR has a lot of >>>>> functionality to start/stop transactions, participate in connection >>>> pooling >>>>> etc. To the application, the RAR exposes only application connection >>>>> factories. In practical terms, these are non-XA connection factories. >> In >>>>> other words, the factories that the RAR exposes to the application are >>>>> wrappers around the "naked" connection factories, and these wrappers >> add >>>> a >>>>> lot of functionality. >>>>> >>>>> What JMSJCA needs are the "naked" connection factories. What I mean >> with >>>>> that are the factories that provide a direct line of communication >>>> between >>>>> the calling code and the JMS server, of course all using the JMS api. >>>>> >>>>> So, to make it work with JNDI, you would have to instantiate the WMQ >>>> "naked" >>>>> factories, bind them into JNDI (e.g. a file provider if WMQ 7 did not >>>> any >>>>> new facilities such as a built-in JNDI server), and use those in >> JMSJCA. >>>>> We're looking into adding explicit support for WMQ7. First issue we >> ran >>>> into >>>>> is how to get a copy of WMQ7. Do you know by any chance? >>>>> >>>>> BTW, are you in contact with Jason Baragry? >>>>> >>>>> One more thing: would you mind if we move this discussion to the >> OpenESB >>>>> users list? >>>>> >>>>> Frank >>>>> >>>>> Frank Kieviet >>>>> Senior Staff Engineer, SOA/BI >>>>> Sun Microsystems, Monrovia, CA >>>>> Tel +1 626 471 6322 >>>>> Blog: http://frankkieviet.blogspot.com/ >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ioj [mailto:[hidden email]] >>>>>> Sent: Monday, November 02, 2009 08:44 >>>>>> To: [hidden email] >>>>>> Subject: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>>>> >>>>>> Hi Frank :) >>>>>> >>>>>> Configured a JMSJCA-driven JCD in jndi:// mode to connect to a >>>> WebSphere >>>>>> MQ 7 queue; Getting this error: >>>>>> >>>>>> [#|2009-11-02T17:09:55.496+0100|INFO|sun- >>>>>> >> appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=18;_Threa >>>>>> dName=httpWorkerThread-4848-4;dpJMSJCATest_1_0_0;|LDR5010: >>>>>> All ejb(s) of [dpJMSJCATest_1_0_0] loaded successfully!|#] >>>>>> >>>>>> [#|2009-11-02T17:09:55.498+0100|WARNING|sun- >>>>>> >> appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=25;_ThreadName=JMSJC >>>>>> A >>>>>> connect;Context=TestProjects | >>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=07fb37e9-63b3- >>>> 4015- >>>>>> a035-dcc50c47ac93;|JMSJCA-E016: >>>>>> [serial-QueueReceiver(QJMSJCATEST){TestProjects | >>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message >>>>>> delivery initiation failed (attempt #1); will retry in 1 seconds. The >>>>>> error was: com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl >>>>>> cannot be cast to javax.jms.XAQueueConnectionFactory >>>>>> java.lang.ClassCastException: >>>>>> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl cannot be >> cast >>>>>> to javax.jms.XAQueueConnectionFactory >>>>>> at >>>>>> >> com.stc.jmsjca.jndi.RAJNDIObjectFactory.createConnectionFactory(RAJNDIObje >>>>>> ctFactory.java:208) >>>>>> at com.stc.jmsjca.core.SerialDelivery.start(SerialDelivery.java:74) >>>>>> at com.stc.jmsjca.core.Activation.asyncStart(Activation.java:552) >>>>>> at com.stc.jmsjca.core.Activation.access$000(Activation.java:81) >>>>>> at com.stc.jmsjca.core.Activation$1.run(Activation.java:347) >>>>>> at java.lang.Thread.run(Thread.java:619) >>>>>> |#] >>>>>> >>>>>> >>>>>> >>>>>> Details: >>>>>> >>>>>> I've installed and configured the WMQ 7 RA from IBM in GlassFish >>>>>> Enterprise v2.1 Patch 02. The IVT (installation verification test) >> app >>>>>> from IBM runs fine and passes all tests. >>>>>> >>>>>> Next, I have the simplest message driven JCD you can think of: it >> reads >>>>>> a TextMessage using JMSJCA and writes the Text to the server.log. >> Works >>>>>> fine with GlassFish MQ. >>>>>> >>>>>> Then I have a connector connection pool of type >> QueueConnectionFactory, >>>>>> using the IBM RA, configured for XA (Transaction Support: >>>> XATransaction) >>>>>> When I configure JMSJCA (inside GF, with the Env overrides in CAPS >> 6.x) >>>>>> with: >>>>>> >>>>>> Connection URL: jndi:// >>>>>> JMSJCA.NoXA=false >>>>>> JMSJCA.QueueCF=jms/wmq/xa/qcf >>>>>> >>>>>> and enable the JCD, I get the message above. >>>>>> >>>>>> I've made sure that the MQ transaction support jar is available to >> the >>>>>> appserver etc. etc. (the IVT passes all tests incl. transactions - >>>>>> though it's much simpler than a JCD with JMSJCA +) >>>>>> >>>>>> What's going wrong here, and how can it be fixed? >>>>>> >>>>>> >>>>>> Thanks in advance! >>>>>> /sysprv >>>>>> >>>>>> --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
|
Frank Kieviet
|
Hi sysprv,
Not sure what is going wrong here. You configuration appears ok, although I don't think you can have seen success with a non-XA factory if you use NoXA=false. Can you send a larger snippet of the server log? Frank > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On > Behalf Of ioj > Sent: Friday, November 06, 2009 07:54 > To: [hidden email] > Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > > > Hi! > > I've done a little more testing with JMSJCA jndi://, MQ 7 and a simple > JCD. > > The JCD is strictly a consumer, and the CAPS classic documentation tells > us that means it works under a XA transaction. > > This is my JMSJCA configuration (env object): > > Connection URL: jndi:// > Options: > > JMSJCA.NoXA=false > JMSJCA.overrideissamerm=true > JMSJCA.QueueCF=centos_QM1_xaqcf > java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory > java.naming.provider.url=file:/var/mqm/jndictx > > > centos_QM1_xaqcf is defined as a MQXAQueueConnectionFactory. > > When I enable the application, it doesn't receive any messages from the > queue... When I disable the application, I see this in the GlassFish logs: > > JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') > reason '2009' ('MQRC_CONNECTION_BROKEN'). > > The MQ queue manager reports unexpected errors (I'll take these up with > IBM when I'm more clear on what I'm doing), and dumps First Failure > Symptom Reports; yet, its "Connection History" has Reason 2072 > (MQRC_SYNCPOINT_NOT_AVAILABLE) and before that Reason 30737 > (lpiRC_WAITCANCELLED_ASYNCCONSUME). > > > Am I configuring JMSJCA wrong? > > > Some more test configurations and results: > > Non-XA connection factory, JMSJCA.NoXA=false := JCD works as expected > (emulated-XA?) > > XA connection factory, JMSJCA.NoXA=false := JCD works as expected > > Non-XA connection factory, JMSJCA.NoXA=true := Obvious, > MQConnectionFactory can't be cast to XAConnectionFactory > > Non-XA connection factory, JMSJCA.NoXA=true := above :) > > > Thanks in advance, > > /sysprv > > > > > Frank Kieviet wrote: > > Hi sysprv, > > > >> The multi-instance queue manager feature (new in v7.0.1) is important > to > >> us; at first glance that means using > >> MQConnectionFactory.setClientReconnectHosts(); > >> Can JMSJCA set properties it does not know about? I'll investigate this > >> more tomorrow. > > > > Recently we added a new feature to the WMQ support in JMSJCA that will > allow > > you to set arbitrary properties on the factory. See > > http://wiki.open-esb.java.net/Wiki.jsp?page=JMSJCAReadme#section- > JMSJCAReadm > > e-SupportForWebSphereMQMQSeries, where you'll find this: > > > > <Quote> > > The com.ibm.mq.jms.MQConnectionFactory has a large list of properties of > > type boolean, int, long, String, URL which can be set. The setter can be > > invoked by specifying a connection URL option named using the following > > convention: remove the 'set' prefix from the name of the setter method > and > > prepend 'WMQ_', e.g. > > > > * setMessageRetention(int): WMQ_MessageRetention=1 > > * setSecurityExit(String): WMQ_SecurityExit=wmq.exits.MySecurityExit > > * setSparseSubscriptions(boolean): WMQ_SparseSubscriptions=true > > </Quote> > > > >> Now I'm interested in these "naked" factories just for the sake of > >> knowing :) > > You could write a small Java program that instantiates the factories, > and > > then bind these factories into JNDI. The JNDI provider could a file > provider > > so that you'll end up with a file that has a serialized connection > factory > > in there. You can then tell JMSJCA to use this JNDI file provider to > read > > the file, deserialize the factory, and as such obtain an instance of the > > factory. This small Java program that would initially instantiate the > > factories would simply call new com.ibm.mq.jms.MQConnectionFactory() and > set > > some properties on this factory. > > > > BTW, if you're going down this road, also set > JMSJCA.overrideissamerm=true > > to workaround an issue in GlassFish/WMQ where GlassFish tries to join an > XA > > resource onto a suspended XA resource. > > > > Frank > > > > > > > >> -----Original Message----- > >> From: [hidden email] > >> [mailto:[hidden email]] > On > >> Behalf Of ioj > >> Sent: Monday, November 02, 2009 11:20 > >> To: [hidden email] > >> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >> > >> > >> Hi Frank, > >> > >> Yes, as expected, with wmq:// the JCD can connect to the queue manager > >> without any problems. > >> > >> > >> The multi-instance queue manager feature (new in v7.0.1) is important > to > >> us; at first glance that means using > >> MQConnectionFactory.setClientReconnectHosts(); > >> Can JMSJCA set properties it does not know about? I'll investigate this > >> more tomorrow. > >> > >> > >> Apart from that, I expected better performance; just an uneducated > guess. > >> > >> > >> Now I'm interested in these "naked" factories just for the sake of > >> knowing :) > >> > >> > >> /sysprv > >> > >> > >> Frank Kieviet wrote: > >>> Hi sysprv, > >>> > >>> I would hope that IBM would provide complete backwards compatibility, > so > >> you > >>> could copy the WMQ jars (com.ibm.mqjms.jar, com.ibm.mq.jar, > >>> com.ibm.mqetclient.jar and dhbcore.jar if I remember correctly) into > the > >> lib > >>> directory, and try to use a wmq://xxxx connection URL. If that works, > at > >>> least we know how to programmatically create the "naked" factories. > Next > >> we > >>> can figure out how to bind them into JNDI. Before we go there, would > >> using > >>> the wmq:// URL work for you? Or is it something particular you hope to > >> get > >>> out of the JNDI? If so, could you elaborate on that a little bit? > >>> > >>> Frank > >>> > >>> > >>>> -----Original Message----- > >>>> From: ioj [mailto:[hidden email]] > >>>> Sent: Monday, November 02, 2009 10:31 > >>>> To: [hidden email] > >>>> Cc: [hidden email]; [hidden email] > >>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>> > >>>> Hi! > >>>> > >>>> Yes, that's exactly what I tried to do; our developers are chummy > with > >>>> STCMS and GF MQ; but for some applications we in ops would rather use > >>>> WMQ. Hence this. And we need WMQ >= 7.0.1 (multi-instance queue > >> managers). > >>>> > >>>> Our company's merely an IBM customer; the other way I know of to get > >> WMQ > >>>> is the 90 day trial :) > >>>> I'll check with IBM on this; perhaps Sun already has some partnership > >> or > >>>> agreement with IBM? > >>>> > >>>> > >>>> Yep, I'm in contact with Jason, and bug him from time to time. > >>>> > >>>> > >>>> I have access to test systems with WMQ and GF (CAPS only, not > OpenESB) > >>>> running on RHEL and AIX. And time too. > >>>> > >>>> > >>>> No problem with moving to OpenESB-users; I just considered this to be > >>>> very JMSJCA-specific. > >>>> > >>>> > >>>> Apart from explicit WMQ7 support (which would be very nice, as WMQ > has > >>>> become much more JMS-like since v6), how would one go about setting > up > >>>> naked factories? > >>>> > >>>> > >>>> > >>>> /sysprv > >>>> > >>>> > >>>> Frank Kieviet wrote: > >>>>> Hi sysprv, > >>>>> > >>>>> From what you're describing it looks like you're deploying the IBM > RAR > >>>> into > >>>>> GlassFish, then bind its connection factories into JNDI, and then > use > >>>> JMSJCA > >>>>> to look them up. > >>>>> > >>>>> If that's the case, the issue with that is that the RAR has a lot of > >>>>> functionality to start/stop transactions, participate in connection > >>>> pooling > >>>>> etc. To the application, the RAR exposes only application connection > >>>>> factories. In practical terms, these are non-XA connection > factories. > >> In > >>>>> other words, the factories that the RAR exposes to the application > are > >>>>> wrappers around the "naked" connection factories, and these wrappers > >> add > >>>> a > >>>>> lot of functionality. > >>>>> > >>>>> What JMSJCA needs are the "naked" connection factories. What I mean > >> with > >>>>> that are the factories that provide a direct line of communication > >>>> between > >>>>> the calling code and the JMS server, of course all using the JMS > api. > >>>>> > >>>>> So, to make it work with JNDI, you would have to instantiate the WMQ > >>>> "naked" > >>>>> factories, bind them into JNDI (e.g. a file provider if WMQ 7 did > not > >>>> any > >>>>> new facilities such as a built-in JNDI server), and use those in > >> JMSJCA. > >>>>> We're looking into adding explicit support for WMQ7. First issue we > >> ran > >>>> into > >>>>> is how to get a copy of WMQ7. Do you know by any chance? > >>>>> > >>>>> BTW, are you in contact with Jason Baragry? > >>>>> > >>>>> One more thing: would you mind if we move this discussion to the > >> OpenESB > >>>>> users list? > >>>>> > >>>>> Frank > >>>>> > >>>>> Frank Kieviet > >>>>> Senior Staff Engineer, SOA/BI > >>>>> Sun Microsystems, Monrovia, CA > >>>>> Tel +1 626 471 6322 > >>>>> Blog: http://frankkieviet.blogspot.com/ > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: ioj [mailto:[hidden email]] > >>>>>> Sent: Monday, November 02, 2009 08:44 > >>>>>> To: [hidden email] > >>>>>> Subject: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>>>> > >>>>>> Hi Frank :) > >>>>>> > >>>>>> Configured a JMSJCA-driven JCD in jndi:// mode to connect to a > >>>> WebSphere > >>>>>> MQ 7 queue; Getting this error: > >>>>>> > >>>>>> [#|2009-11-02T17:09:55.496+0100|INFO|sun- > >>>>>> > >> > appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=18;_Threa > >>>>>> dName=httpWorkerThread-4848-4;dpJMSJCATest_1_0_0;|LDR5010: > >>>>>> All ejb(s) of [dpJMSJCATest_1_0_0] loaded successfully!|#] > >>>>>> > >>>>>> [#|2009-11-02T17:09:55.498+0100|WARNING|sun- > >>>>>> > >> > appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=25;_ThreadName=JMSJC > >>>>>> A > >>>>>> connect;Context=TestProjects | > >>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=07fb37e9-63b3- > >>>> 4015- > >>>>>> a035-dcc50c47ac93;|JMSJCA-E016: > >>>>>> [serial-QueueReceiver(QJMSJCATEST){TestProjects | > >>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message > >>>>>> delivery initiation failed (attempt #1); will retry in 1 seconds. > The > >>>>>> error was: com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl > >>>>>> cannot be cast to javax.jms.XAQueueConnectionFactory > >>>>>> java.lang.ClassCastException: > >>>>>> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl cannot be > >> cast > >>>>>> to javax.jms.XAQueueConnectionFactory > >>>>>> at > >>>>>> > >> > com.stc.jmsjca.jndi.RAJNDIObjectFactory.createConnectionFactory(RAJNDIObje > >>>>>> ctFactory.java:208) > >>>>>> at > com.stc.jmsjca.core.SerialDelivery.start(SerialDelivery.java:74) > >>>>>> at > com.stc.jmsjca.core.Activation.asyncStart(Activation.java:552) > >>>>>> at > com.stc.jmsjca.core.Activation.access$000(Activation.java:81) > >>>>>> at com.stc.jmsjca.core.Activation$1.run(Activation.java:347) > >>>>>> at java.lang.Thread.run(Thread.java:619) > >>>>>> |#] > >>>>>> > >>>>>> > >>>>>> > >>>>>> Details: > >>>>>> > >>>>>> I've installed and configured the WMQ 7 RA from IBM in GlassFish > >>>>>> Enterprise v2.1 Patch 02. The IVT (installation verification test) > >> app > >>>>>> from IBM runs fine and passes all tests. > >>>>>> > >>>>>> Next, I have the simplest message driven JCD you can think of: it > >> reads > >>>>>> a TextMessage using JMSJCA and writes the Text to the server.log. > >> Works > >>>>>> fine with GlassFish MQ. > >>>>>> > >>>>>> Then I have a connector connection pool of type > >> QueueConnectionFactory, > >>>>>> using the IBM RA, configured for XA (Transaction Support: > >>>> XATransaction) > >>>>>> When I configure JMSJCA (inside GF, with the Env overrides in CAPS > >> 6.x) > >>>>>> with: > >>>>>> > >>>>>> Connection URL: jndi:// > >>>>>> JMSJCA.NoXA=false > >>>>>> JMSJCA.QueueCF=jms/wmq/xa/qcf > >>>>>> > >>>>>> and enable the JCD, I get the message above. > >>>>>> > >>>>>> I've made sure that the MQ transaction support jar is available to > >> the > >>>>>> appserver etc. etc. (the IVT passes all tests incl. transactions - > >>>>>> though it's much simpler than a JCD with JMSJCA +) > >>>>>> > >>>>>> What's going wrong here, and how can it be fixed? > >>>>>> > >>>>>> > >>>>>> Thanks in advance! > >>>>>> /sysprv > >>>>>> > >>>>>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
|
sysprv
|
Hi Frank,
My bad, it should be: >> Non-XA connection factory, JMSJCA.NoXA=true := JCD works as expected >> (emulated-XA?) A longer snippet from the log is attached (in case of hard wrapping), and inline: [#|2009-11-07T00:54:00.106+0100|INFO|sun-appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=39;_ThreadName=JMSJCA connect;Context=TestProjects | prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;|JMSJCA-E015: [serial-QueueReceiver(QJMSJCATEST){TestProjects | prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message delivery initiation was successful.|#] There are already some messages on the queue; I expect to see their contents in server.log, but it seems they're never delivered to the JCD. Then I disable the JCD: [#|2009-11-07T00:54:40.928+0100|WARNING|sun-appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p: thread-pool-1; w: 41;Context=TestProjects | prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14-4680-82dc-5aae8f323bba;|JMSJCA-E054: Unexpected exception stopping JMS connection: JMSCMQ0002: The method 'MQCTL' failed.. com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ0002: The method 'MQCTL' failed. A WebSphere MQ call failed. Please see the linked exception for more information. at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:608) at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:236) at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:275) at com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService(WMQConsumerOwnerShadow.java:308) at com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.stop(WMQConsumerOwnerShadow.java:654) at com.ibm.msg.client.wmq.internal.WMQSession.stop(WMQSession.java:1466) at com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:2028) at com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:1936) at com.ibm.msg.client.jms.internal.JmsConnectionImpl.stop(JmsConnectionImpl.java:792) at com.ibm.mq.jms.MQConnection.stop(MQConnection.java:471) at com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:153) at com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) at com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) at com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourceAdapter.java:717) at com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(ConnectorMessageBeanClient.java:313) at com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(MessageBeanContainer.java:920) at com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.service(MessageBeanContainer.java:912) at com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555) Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2009' ('MQRC_CONNECTION_BROKEN'). at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:223) ... 17 more Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 at com.ibm.mq.jmqi.remote.internal.RemoteHconn.exchangeTSH(RemoteHconn.java:1472) at com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.sendNotification(RemoteAsyncConsume.java:409) at com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.sendConnState(RemoteAsyncConsume.java:522) at com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQCTL(RemoteFAP.java:2066) at com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService(WMQConsumerOwnerShadow.java:296) ... 15 more Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error on receive from host 'centos/10.0.0.1:1414 (centos)'. [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThread.java:698) at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThread.java:638) at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:136) at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:209) at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:100) at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:224) at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:298) at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) |#] [#|2009-11-07T00:54:40.933+0100|WARNING|sun-appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p: thread-pool-1; w: 41;Context=TestProjects | prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14-4680-82dc-5aae8f323bba;|JMSJCA-E087: Error while closing session: JMSCMQ0002: The method 'MQCTL' failed. com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ0002: The method 'MQCTL' failed. A WebSphere MQ call failed. Please see the linked exception for more information. at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:608) at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:236) at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:275) at com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService(WMQConsumerOwnerShadow.java:308) at com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.stop(WMQConsumerOwnerShadow.java:654) at com.ibm.msg.client.wmq.internal.WMQSession.stop(WMQSession.java:1466) at com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:2028) at com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:289) at com.ibm.msg.client.jms.internal.JmsXASessionImpl.close(JmsXASessionImpl.java:234) at com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:235) at com.ibm.msg.client.jms.internal.JmsXASessionImpl.close(JmsXASessionImpl.java:199) at com.ibm.mq.jms.MQSession.close(MQSession.java:195) at com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:167) at com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) at com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) at com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourceAdapter.java:717) at com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(ConnectorMessageBeanClient.java:313) at com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(MessageBeanContainer.java:920) at com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.service(MessageBeanContainer.java:912) at com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555) Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2009' ('MQRC_CONNECTION_BROKEN'). at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:223) ... 19 more Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 at com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:381) at com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:304) at com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQCTL(RemoteFAP.java:1923) at com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService(WMQConsumerOwnerShadow.java:296) ... 17 more Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error on receive from host 'centos/10.0.0.1:1414 (centos)'. [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThread.java:698) at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThread.java:638) at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:136) at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:209) at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:100) at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:224) at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:298) at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) |#] [#|2009-11-07T00:54:40.935+0100|WARNING|sun-appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p: thread-pool-1; w: 41;Context=TestProjects | prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14-4680-82dc-5aae8f323bba;|JMSJCA-E055: Unexpected exception closing JMS connection: JMSWMQ0019: Failed to disconnect from queue manager '' using connection mode '1' and host name 'centos'. com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ0019: Failed to disconnect from queue manager '' using connection mode '1' and host name 'centos'. Please see the linked exception for more information. at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:608) at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:236) at com.ibm.msg.client.wmq.internal.WMQConnection.close(WMQConnection.java:677) at com.ibm.msg.client.jms.internal.JmsConnectionImpl.close(JmsConnectionImpl.java:328) at com.ibm.mq.jms.MQConnection.close(MQConnection.java:93) at com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:175) at com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) at com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) at com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourceAdapter.java:717) at com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(ConnectorMessageBeanClient.java:313) at com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(MessageBeanContainer.java:920) at com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.service(MessageBeanContainer.java:912) at com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555) Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2009' ('MQRC_CONNECTION_BROKEN'). at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:223) ... 12 more Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 at com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:381) at com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:304) at com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQDISC(RemoteFAP.java:2347) at com.ibm.msg.client.wmq.internal.WMQConnection.close(WMQConnection.java:659) ... 11 more Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error on receive from host 'centos/10.0.0.1:1414 (centos)'. [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThread.java:698) at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThread.java:638) at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:136) at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:209) at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:100) at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:224) at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:298) at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) |#] [#|2009-11-07T00:54:41.025+0100|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=17;_ThreadName=httpWorkerThread-4848-1;dpJMSJCATest_1_0_0;|CORE5022: All ejb(s) of [dpJMSJCATest_1_0_0] were unloaded successfully!|#] Frank Kieviet wrote: > Hi sysprv, > > Not sure what is going wrong here. You configuration appears ok, although I > don't think you can have seen success with a non-XA factory if you use > NoXA=false. Can you send a larger snippet of the server log? > > Frank > > >> -----Original Message----- >> From: [hidden email] >> [mailto:[hidden email]] On >> Behalf Of ioj >> Sent: Friday, November 06, 2009 07:54 >> To: [hidden email] >> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >> >> >> Hi! >> >> I've done a little more testing with JMSJCA jndi://, MQ 7 and a simple >> JCD. >> >> The JCD is strictly a consumer, and the CAPS classic documentation tells >> us that means it works under a XA transaction. >> >> This is my JMSJCA configuration (env object): >> >> Connection URL: jndi:// >> Options: >> >> JMSJCA.NoXA=false >> JMSJCA.overrideissamerm=true >> JMSJCA.QueueCF=centos_QM1_xaqcf >> java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory >> java.naming.provider.url=file:/var/mqm/jndictx >> >> >> centos_QM1_xaqcf is defined as a MQXAQueueConnectionFactory. >> >> When I enable the application, it doesn't receive any messages from the >> queue... When I disable the application, I see this in the GlassFish logs: >> >> JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') >> reason '2009' ('MQRC_CONNECTION_BROKEN'). >> >> The MQ queue manager reports unexpected errors (I'll take these up with >> IBM when I'm more clear on what I'm doing), and dumps First Failure >> Symptom Reports; yet, its "Connection History" has Reason 2072 >> (MQRC_SYNCPOINT_NOT_AVAILABLE) and before that Reason 30737 >> (lpiRC_WAITCANCELLED_ASYNCCONSUME). >> >> >> Am I configuring JMSJCA wrong? >> >> >> Some more test configurations and results: >> >> Non-XA connection factory, JMSJCA.NoXA=false := JCD works as expected >> (emulated-XA?) >> >> XA connection factory, JMSJCA.NoXA=false := JCD works as expected >> >> Non-XA connection factory, JMSJCA.NoXA=true := Obvious, >> MQConnectionFactory can't be cast to XAConnectionFactory >> >> Non-XA connection factory, JMSJCA.NoXA=true := above :) >> >> >> Thanks in advance, >> >> /sysprv >> >> >> >> >> Frank Kieviet wrote: >>> Hi sysprv, >>> >>>> The multi-instance queue manager feature (new in v7.0.1) is important >> to >>>> us; at first glance that means using >>>> MQConnectionFactory.setClientReconnectHosts(); >>>> Can JMSJCA set properties it does not know about? I'll investigate this >>>> more tomorrow. >>> Recently we added a new feature to the WMQ support in JMSJCA that will >> allow >>> you to set arbitrary properties on the factory. See >>> http://wiki.open-esb.java.net/Wiki.jsp?page=JMSJCAReadme#section- >> JMSJCAReadm >>> e-SupportForWebSphereMQMQSeries, where you'll find this: >>> >>> <Quote> >>> The com.ibm.mq.jms.MQConnectionFactory has a large list of properties of >>> type boolean, int, long, String, URL which can be set. The setter can be >>> invoked by specifying a connection URL option named using the following >>> convention: remove the 'set' prefix from the name of the setter method >> and >>> prepend 'WMQ_', e.g. >>> >>> * setMessageRetention(int): WMQ_MessageRetention=1 >>> * setSecurityExit(String): WMQ_SecurityExit=wmq.exits.MySecurityExit >>> * setSparseSubscriptions(boolean): WMQ_SparseSubscriptions=true >>> </Quote> >>> >>>> Now I'm interested in these "naked" factories just for the sake of >>>> knowing :) >>> You could write a small Java program that instantiates the factories, >> and >>> then bind these factories into JNDI. The JNDI provider could a file >> provider >>> so that you'll end up with a file that has a serialized connection >> factory >>> in there. You can then tell JMSJCA to use this JNDI file provider to >> read >>> the file, deserialize the factory, and as such obtain an instance of the >>> factory. This small Java program that would initially instantiate the >>> factories would simply call new com.ibm.mq.jms.MQConnectionFactory() and >> set >>> some properties on this factory. >>> >>> BTW, if you're going down this road, also set >> JMSJCA.overrideissamerm=true >>> to workaround an issue in GlassFish/WMQ where GlassFish tries to join an >> XA >>> resource onto a suspended XA resource. >>> >>> Frank >>> >>> >>> >>>> -----Original Message----- >>>> From: [hidden email] >>>> [mailto:[hidden email]] >> On >>>> Behalf Of ioj >>>> Sent: Monday, November 02, 2009 11:20 >>>> To: [hidden email] >>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>> >>>> >>>> Hi Frank, >>>> >>>> Yes, as expected, with wmq:// the JCD can connect to the queue manager >>>> without any problems. >>>> >>>> >>>> The multi-instance queue manager feature (new in v7.0.1) is important >> to >>>> us; at first glance that means using >>>> MQConnectionFactory.setClientReconnectHosts(); >>>> Can JMSJCA set properties it does not know about? I'll investigate this >>>> more tomorrow. >>>> >>>> >>>> Apart from that, I expected better performance; just an uneducated >> guess. >>>> >>>> Now I'm interested in these "naked" factories just for the sake of >>>> knowing :) >>>> >>>> >>>> /sysprv >>>> >>>> >>>> Frank Kieviet wrote: >>>>> Hi sysprv, >>>>> >>>>> I would hope that IBM would provide complete backwards compatibility, >> so >>>> you >>>>> could copy the WMQ jars (com.ibm.mqjms.jar, com.ibm.mq.jar, >>>>> com.ibm.mqetclient.jar and dhbcore.jar if I remember correctly) into >> the >>>> lib >>>>> directory, and try to use a wmq://xxxx connection URL. If that works, >> at >>>>> least we know how to programmatically create the "naked" factories. >> Next >>>> we >>>>> can figure out how to bind them into JNDI. Before we go there, would >>>> using >>>>> the wmq:// URL work for you? Or is it something particular you hope to >>>> get >>>>> out of the JNDI? If so, could you elaborate on that a little bit? >>>>> >>>>> Frank >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ioj [mailto:[hidden email]] >>>>>> Sent: Monday, November 02, 2009 10:31 >>>>>> To: [hidden email] >>>>>> Cc: [hidden email]; [hidden email] >>>>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>>>> >>>>>> Hi! >>>>>> >>>>>> Yes, that's exactly what I tried to do; our developers are chummy >> with >>>>>> STCMS and GF MQ; but for some applications we in ops would rather use >>>>>> WMQ. Hence this. And we need WMQ >= 7.0.1 (multi-instance queue >>>> managers). >>>>>> Our company's merely an IBM customer; the other way I know of to get >>>> WMQ >>>>>> is the 90 day trial :) >>>>>> I'll check with IBM on this; perhaps Sun already has some partnership >>>> or >>>>>> agreement with IBM? >>>>>> >>>>>> >>>>>> Yep, I'm in contact with Jason, and bug him from time to time. >>>>>> >>>>>> >>>>>> I have access to test systems with WMQ and GF (CAPS only, not >> OpenESB) >>>>>> running on RHEL and AIX. And time too. >>>>>> >>>>>> >>>>>> No problem with moving to OpenESB-users; I just considered this to be >>>>>> very JMSJCA-specific. >>>>>> >>>>>> >>>>>> Apart from explicit WMQ7 support (which would be very nice, as WMQ >> has >>>>>> become much more JMS-like since v6), how would one go about setting >> up >>>>>> naked factories? >>>>>> >>>>>> >>>>>> >>>>>> /sysprv >>>>>> >>>>>> >>>>>> Frank Kieviet wrote: >>>>>>> Hi sysprv, >>>>>>> >>>>>>> From what you're describing it looks like you're deploying the IBM >> RAR >>>>>> into >>>>>>> GlassFish, then bind its connection factories into JNDI, and then >> use >>>>>> JMSJCA >>>>>>> to look them up. >>>>>>> >>>>>>> If that's the case, the issue with that is that the RAR has a lot of >>>>>>> functionality to start/stop transactions, participate in connection >>>>>> pooling >>>>>>> etc. To the application, the RAR exposes only application connection >>>>>>> factories. In practical terms, these are non-XA connection >> factories. >>>> In >>>>>>> other words, the factories that the RAR exposes to the application >> are >>>>>>> wrappers around the "naked" connection factories, and these wrappers >>>> add >>>>>> a >>>>>>> lot of functionality. >>>>>>> >>>>>>> What JMSJCA needs are the "naked" connection factories. What I mean >>>> with >>>>>>> that are the factories that provide a direct line of communication >>>>>> between >>>>>>> the calling code and the JMS server, of course all using the JMS >> api. >>>>>>> So, to make it work with JNDI, you would have to instantiate the WMQ >>>>>> "naked" >>>>>>> factories, bind them into JNDI (e.g. a file provider if WMQ 7 did >> not >>>>>> any >>>>>>> new facilities such as a built-in JNDI server), and use those in >>>> JMSJCA. >>>>>>> We're looking into adding explicit support for WMQ7. First issue we >>>> ran >>>>>> into >>>>>>> is how to get a copy of WMQ7. Do you know by any chance? >>>>>>> >>>>>>> BTW, are you in contact with Jason Baragry? >>>>>>> >>>>>>> One more thing: would you mind if we move this discussion to the >>>> OpenESB >>>>>>> users list? >>>>>>> >>>>>>> Frank >>>>>>> >>>>>>> Frank Kieviet >>>>>>> Senior Staff Engineer, SOA/BI >>>>>>> Sun Microsystems, Monrovia, CA >>>>>>> Tel +1 626 471 6322 >>>>>>> Blog: http://frankkieviet.blogspot.com/ >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ioj [mailto:[hidden email]] >>>>>>>> Sent: Monday, November 02, 2009 08:44 >>>>>>>> To: [hidden email] >>>>>>>> Subject: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>>>>>> >>>>>>>> Hi Frank :) >>>>>>>> >>>>>>>> Configured a JMSJCA-driven JCD in jndi:// mode to connect to a >>>>>> WebSphere >>>>>>>> MQ 7 queue; Getting this error: >>>>>>>> >>>>>>>> [#|2009-11-02T17:09:55.496+0100|INFO|sun- >>>>>>>> >> appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=18;_Threa >>>>>>>> dName=httpWorkerThread-4848-4;dpJMSJCATest_1_0_0;|LDR5010: >>>>>>>> All ejb(s) of [dpJMSJCATest_1_0_0] loaded successfully!|#] >>>>>>>> >>>>>>>> [#|2009-11-02T17:09:55.498+0100|WARNING|sun- >>>>>>>> >> appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=25;_ThreadName=JMSJC >>>>>>>> A >>>>>>>> connect;Context=TestProjects | >>>>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=07fb37e9-63b3- >>>>>> 4015- >>>>>>>> a035-dcc50c47ac93;|JMSJCA-E016: >>>>>>>> [serial-QueueReceiver(QJMSJCATEST){TestProjects | >>>>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message >>>>>>>> delivery initiation failed (attempt #1); will retry in 1 seconds. >> The >>>>>>>> error was: com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl >>>>>>>> cannot be cast to javax.jms.XAQueueConnectionFactory >>>>>>>> java.lang.ClassCastException: >>>>>>>> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl cannot be >>>> cast >>>>>>>> to javax.jms.XAQueueConnectionFactory >>>>>>>> at >>>>>>>> >> com.stc.jmsjca.jndi.RAJNDIObjectFactory.createConnectionFactory(RAJNDIObje >>>>>>>> ctFactory.java:208) >>>>>>>> at >> com.stc.jmsjca.core.SerialDelivery.start(SerialDelivery.java:74) >>>>>>>> at >> com.stc.jmsjca.core.Activation.asyncStart(Activation.java:552) >>>>>>>> at >> com.stc.jmsjca.core.Activation.access$000(Activation.java:81) >>>>>>>> at com.stc.jmsjca.core.Activation$1.run(Activation.java:347) >>>>>>>> at java.lang.Thread.run(Thread.java:619) >>>>>>>> |#] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Details: >>>>>>>> >>>>>>>> I've installed and configured the WMQ 7 RA from IBM in GlassFish >>>>>>>> Enterprise v2.1 Patch 02. The IVT (installation verification test) >>>> app >>>>>>>> from IBM runs fine and passes all tests. >>>>>>>> >>>>>>>> Next, I have the simplest message driven JCD you can think of: it >>>> reads >>>>>>>> a TextMessage using JMSJCA and writes the Text to the server.log. >>>> Works >>>>>>>> fine with GlassFish MQ. >>>>>>>> >>>>>>>> Then I have a connector connection pool of type >>>> QueueConnectionFactory, >>>>>>>> using the IBM RA, configured for XA (Transaction Support: >>>>>> XATransaction) >>>>>>>> When I configure JMSJCA (inside GF, with the Env overrides in CAPS >>>> 6.x) >>>>>>>> with: >>>>>>>> >>>>>>>> Connection URL: jndi:// >>>>>>>> JMSJCA.NoXA=false >>>>>>>> JMSJCA.QueueCF=jms/wmq/xa/qcf >>>>>>>> >>>>>>>> and enable the JCD, I get the message above. >>>>>>>> >>>>>>>> I've made sure that the MQ transaction support jar is available to >>>> the >>>>>>>> appserver etc. etc. (the IVT passes all tests incl. transactions - >>>>>>>> though it's much simpler than a JCD with JMSJCA +) >>>>>>>> >>>>>>>> What's going wrong here, and how can it be fixed? >>>>>>>> >>>>>>>> >>>>>>>> Thanks in advance! >>>>>>>> /sysprv >>>>>>>> >>>>>>>> >> [#|2009-11-07T00:54:00.106+0100|INFO|sun-appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=39;_ThreadName=JMSJCA connect;Context=TestProjects | prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;|JMSJCA-E015: [serial-QueueReceiver(QJMSJCATEST){TestProjects | prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message delivery initiation was successful.|#] [#|2009-11-07T00:54:30.819+0100|INFO|sun-appserver2.1|javax.enterprise.system.tools.admin|_ThreadID=17;_ThreadName=httpWorkerThread-4848-1;ApplicationDeployEvent -- disable dpJMSJCATest_1_0_0;|ADM1041:Sent the event to instance:[ApplicationDeployEvent -- disable dpJMSJCATest_1_0_0]|#] [#|2009-11-07T00:54:40.928+0100|WARNING|sun-appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p: thread-pool-1; w: 41;Context=TestProjects | prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14-4680-82dc-5aae8f323bba;|JMSJCA-E054: Unexpected exception stopping JMS connection: JMSCMQ0002: The method 'MQCTL' failed.. com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ0002: The method 'MQCTL' failed. A WebSphere MQ call failed. Please see the linked exception for more information. at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:608) at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:236) at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:275) at com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService(WMQConsumerOwnerShadow.java:308) at com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.stop(WMQConsumerOwnerShadow.java:654) at com.ibm.msg.client.wmq.internal.WMQSession.stop(WMQSession.java:1466) at com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:2028) at com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:1936) at com.ibm.msg.client.jms.internal.JmsConnectionImpl.stop(JmsConnectionImpl.java:792) at com.ibm.mq.jms.MQConnection.stop(MQConnection.java:471) at com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:153) at com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) at com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) at com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourceAdapter.java:717) at com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(ConnectorMessageBeanClient.java:313) at com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(MessageBeanContainer.java:920) at com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.service(MessageBeanContainer.java:912) at com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555) Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2009' ('MQRC_CONNECTION_BROKEN'). at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:223) ... 17 more Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 at com.ibm.mq.jmqi.remote.internal.RemoteHconn.exchangeTSH(RemoteHconn.java:1472) at com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.sendNotification(RemoteAsyncConsume.java:409) at com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.sendConnState(RemoteAsyncConsume.java:522) at com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQCTL(RemoteFAP.java:2066) at com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService(WMQConsumerOwnerShadow.java:296) ... 15 more Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error on receive from host 'centos/10.0.0.1:1414 (centos)'. [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThread.java:698) at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThread.java:638) at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:136) at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:209) at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:100) at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:224) at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:298) at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) |#] [#|2009-11-07T00:54:40.933+0100|WARNING|sun-appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p: thread-pool-1; w: 41;Context=TestProjects | prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14-4680-82dc-5aae8f323bba;|JMSJCA-E087: Error while closing session: JMSCMQ0002: The method 'MQCTL' failed. com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ0002: The method 'MQCTL' failed. A WebSphere MQ call failed. Please see the linked exception for more information. at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:608) at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:236) at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:275) at com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService(WMQConsumerOwnerShadow.java:308) at com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.stop(WMQConsumerOwnerShadow.java:654) at com.ibm.msg.client.wmq.internal.WMQSession.stop(WMQSession.java:1466) at com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:2028) at com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:289) at com.ibm.msg.client.jms.internal.JmsXASessionImpl.close(JmsXASessionImpl.java:234) at com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:235) at com.ibm.msg.client.jms.internal.JmsXASessionImpl.close(JmsXASessionImpl.java:199) at com.ibm.mq.jms.MQSession.close(MQSession.java:195) at com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:167) at com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) at com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) at com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourceAdapter.java:717) at com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(ConnectorMessageBeanClient.java:313) at com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(MessageBeanContainer.java:920) at com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.service(MessageBeanContainer.java:912) at com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555) Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2009' ('MQRC_CONNECTION_BROKEN'). at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:223) ... 19 more Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 at com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:381) at com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:304) at com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQCTL(RemoteFAP.java:1923) at com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService(WMQConsumerOwnerShadow.java:296) ... 17 more Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error on receive from host 'centos/10.0.0.1:1414 (centos)'. [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThread.java:698) at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThread.java:638) at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:136) at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:209) at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:100) at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:224) at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:298) at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) |#] [#|2009-11-07T00:54:40.935+0100|WARNING|sun-appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p: thread-pool-1; w: 41;Context=TestProjects | prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14-4680-82dc-5aae8f323bba;|JMSJCA-E055: Unexpected exception closing JMS connection: JMSWMQ0019: Failed to disconnect from queue manager '' using connection mode '1' and host name 'centos'. com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ0019: Failed to disconnect from queue manager '' using connection mode '1' and host name 'centos'. Please see the linked exception for more information. at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:608) at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:236) at com.ibm.msg.client.wmq.internal.WMQConnection.close(WMQConnection.java:677) at com.ibm.msg.client.jms.internal.JmsConnectionImpl.close(JmsConnectionImpl.java:328) at com.ibm.mq.jms.MQConnection.close(MQConnection.java:93) at com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:175) at com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) at com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) at com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourceAdapter.java:717) at com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(ConnectorMessageBeanClient.java:313) at com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(MessageBeanContainer.java:920) at com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.service(MessageBeanContainer.java:912) at com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555) Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2009' ('MQRC_CONNECTION_BROKEN'). at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:223) ... 12 more Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 at com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:381) at com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:304) at com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQDISC(RemoteFAP.java:2347) at com.ibm.msg.client.wmq.internal.WMQConnection.close(WMQConnection.java:659) ... 11 more Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error on receive from host 'centos/10.0.0.1:1414 (centos)'. [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThread.java:698) at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThread.java:638) at com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:136) at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:209) at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:100) at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:224) at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:298) at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) |#] [#|2009-11-07T00:54:41.025+0100|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=17;_ThreadName=httpWorkerThread-4848-1;dpJMSJCATest_1_0_0;|CORE5022: All ejb(s) of [dpJMSJCATest_1_0_0] were unloaded successfully!|#] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
|
Frank Kieviet
|
Hi sysprv,
Could you add the following option as well? JMSJCA.concurrencymode=sync This will change the delivery from serial to sync which is the only mode that works with WMQ and XA. HTH, Frank > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On > Behalf Of ioj > Sent: Friday, November 06, 2009 16:01 > To: [hidden email] > Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > > Hi Frank, > > My bad, it should be: > > >> Non-XA connection factory, JMSJCA.NoXA=true := JCD works as expected > >> (emulated-XA?) > > > > A longer snippet from the log is attached (in case of hard wrapping), > and inline: > > [#|2009-11-07T00:54:00.106+0100|INFO|sun- > appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=39;_ThreadName=JMSJC > A > connect;Context=TestProjects | > prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;|JMSJCA-E015: > [serial-QueueReceiver(QJMSJCATEST){TestProjects | > prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message > delivery initiation was successful.|#] > > > There are already some messages on the queue; I expect to see their > contents in server.log, but it seems they're never delivered to the JCD. > > Then I disable the JCD: > > [#|2009-11-07T00:54:40.928+0100|WARNING|sun- > appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p > : > thread-pool-1; w: 41;Context=TestProjects | > prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14-4680- > 82dc-5aae8f323bba;|JMSJCA-E054: > Unexpected exception stopping JMS connection: JMSCMQ0002: The method > 'MQCTL' failed.. > com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ0002: The method > 'MQCTL' failed. A WebSphere MQ call failed. Please see the linked > exception for more information. > at > com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav > a:608) > at > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > 236) > at > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > 275) > at > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService > (WMQConsumerOwnerShadow.java:308) > at > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.stop(WMQConsumerOwn > erShadow.java:654) > at > com.ibm.msg.client.wmq.internal.WMQSession.stop(WMQSession.java:1466) > at > com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:20 > 28) > at > com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:19 > 36) > at > com.ibm.msg.client.jms.internal.JmsConnectionImpl.stop(JmsConnectionImpl.j > ava:792) > at com.ibm.mq.jms.MQConnection.stop(MQConnection.java:471) > at > com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:153) > at > com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) > at com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) > at > com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc > eAdapter.java:717) > at > com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn > ectorMessageBeanClient.java:313) > at > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me > ssageBeanContainer.java:920) > at > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic > e(MessageBeanContainer.java:912) > at > com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) > at > com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T > hreadPoolImpl.java:555) > Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed > with compcode '2' ('MQCC_FAILED') reason '2009' > ('MQRC_CONNECTION_BROKEN'). > at > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > 223) > ... 17 more > Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 > at > com.ibm.mq.jmqi.remote.internal.RemoteHconn.exchangeTSH(RemoteHconn.java:1 > 472) > at > com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.sendNotification(Remote > AsyncConsume.java:409) > at > com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.sendConnState(RemoteAsy > ncConsume.java:522) > at > com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQCTL(RemoteFAP.java:2066) > at > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService > (WMQConsumerOwnerShadow.java:296) > ... 15 more > Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error on > receive from host 'centos/10.0.0.1:1414 (centos)'. > [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] > at > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr > ead.java:698) > at > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr > ead.java:638) > at > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 > 36) > at > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu > eItem.java:209) > at > com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si > mpleWorkQueueItem.java:100) > at > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte > m.java:224) > at > com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI > tem(WorkQueueManager.java:298) > at > com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement > ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) > |#] > > [#|2009-11-07T00:54:40.933+0100|WARNING|sun- > appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p > : > thread-pool-1; w: 41;Context=TestProjects | > prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14-4680- > 82dc-5aae8f323bba;|JMSJCA-E087: > Error while closing session: JMSCMQ0002: The method 'MQCTL' failed. > com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ0002: The method > 'MQCTL' failed. A WebSphere MQ call failed. Please see the linked > exception for more information. > at > com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav > a:608) > at > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > 236) > at > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > 275) > at > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService > (WMQConsumerOwnerShadow.java:308) > at > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.stop(WMQConsumerOwn > erShadow.java:654) > at > com.ibm.msg.client.wmq.internal.WMQSession.stop(WMQSession.java:1466) > at > com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:20 > 28) > at > com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:2 > 89) > at > com.ibm.msg.client.jms.internal.JmsXASessionImpl.close(JmsXASessionImpl.ja > va:234) > at > com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:2 > 35) > at > com.ibm.msg.client.jms.internal.JmsXASessionImpl.close(JmsXASessionImpl.ja > va:199) > at com.ibm.mq.jms.MQSession.close(MQSession.java:195) > at > com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:167) > at > com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) > at com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) > at > com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc > eAdapter.java:717) > at > com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn > ectorMessageBeanClient.java:313) > at > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me > ssageBeanContainer.java:920) > at > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic > e(MessageBeanContainer.java:912) > at > com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) > at > com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T > hreadPoolImpl.java:555) > Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed > with compcode '2' ('MQCC_FAILED') reason '2009' > ('MQRC_CONNECTION_BROKEN'). > at > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > 223) > ... 19 more > Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 > at > com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:381 > ) > at > com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:304 > ) > at > com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQCTL(RemoteFAP.java:1923) > at > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService > (WMQConsumerOwnerShadow.java:296) > ... 17 more > Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error on > receive from host 'centos/10.0.0.1:1414 (centos)'. > [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] > at > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr > ead.java:698) > at > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr > ead.java:638) > at > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 > 36) > at > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu > eItem.java:209) > at > com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si > mpleWorkQueueItem.java:100) > at > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte > m.java:224) > at > com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI > tem(WorkQueueManager.java:298) > at > com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement > ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) > |#] > > [#|2009-11-07T00:54:40.935+0100|WARNING|sun- > appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p > : > thread-pool-1; w: 41;Context=TestProjects | > prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14-4680- > 82dc-5aae8f323bba;|JMSJCA-E055: > Unexpected exception closing JMS connection: JMSWMQ0019: Failed to > disconnect from queue manager '' using connection mode '1' and host name > 'centos'. > com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ0019: Failed to > disconnect from queue manager '' using connection mode '1' and host name > 'centos'. Please see the linked exception for more information. > at > com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav > a:608) > at > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > 236) > at > com.ibm.msg.client.wmq.internal.WMQConnection.close(WMQConnection.java:677 > ) > at > com.ibm.msg.client.jms.internal.JmsConnectionImpl.close(JmsConnectionImpl. > java:328) > at com.ibm.mq.jms.MQConnection.close(MQConnection.java:93) > at > com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:175) > at > com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) > at com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) > at > com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc > eAdapter.java:717) > at > com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn > ectorMessageBeanClient.java:313) > at > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me > ssageBeanContainer.java:920) > at > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic > e(MessageBeanContainer.java:912) > at > com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) > at > com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T > hreadPoolImpl.java:555) > Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed > with compcode '2' ('MQCC_FAILED') reason '2009' > ('MQRC_CONNECTION_BROKEN'). > at > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > 223) > ... 12 more > Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 > at > com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:381 > ) > at > com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:304 > ) > at > com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQDISC(RemoteFAP.java:2347) > at > com.ibm.msg.client.wmq.internal.WMQConnection.close(WMQConnection.java:659 > ) > ... 11 more > Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error on > receive from host 'centos/10.0.0.1:1414 (centos)'. > [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] > at > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr > ead.java:698) > at > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr > ead.java:638) > at > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 > 36) > at > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu > eItem.java:209) > at > com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si > mpleWorkQueueItem.java:100) > at > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte > m.java:224) > at > com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI > tem(WorkQueueManager.java:298) > at > com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement > ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) > |#] > > [#|2009-11-07T00:54:41.025+0100|INFO|sun- > appserver2.1|javax.enterprise.system.core|_ThreadID=17;_ThreadName=httpWor > kerThread-4848-1;dpJMSJCATest_1_0_0;|CORE5022: > All ejb(s) of [dpJMSJCATest_1_0_0] were unloaded successfully!|#] > > > > > > > > Frank Kieviet wrote: > > Hi sysprv, > > > > Not sure what is going wrong here. You configuration appears ok, > although I > > don't think you can have seen success with a non-XA factory if you use > > NoXA=false. Can you send a larger snippet of the server log? > > > > Frank > > > > > >> -----Original Message----- > >> From: [hidden email] > >> [mailto:[hidden email]] > On > >> Behalf Of ioj > >> Sent: Friday, November 06, 2009 07:54 > >> To: [hidden email] > >> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >> > >> > >> Hi! > >> > >> I've done a little more testing with JMSJCA jndi://, MQ 7 and a simple > >> JCD. > >> > >> The JCD is strictly a consumer, and the CAPS classic documentation > tells > >> us that means it works under a XA transaction. > >> > >> This is my JMSJCA configuration (env object): > >> > >> Connection URL: jndi:// > >> Options: > >> > >> JMSJCA.NoXA=false > >> JMSJCA.overrideissamerm=true > >> JMSJCA.QueueCF=centos_QM1_xaqcf > >> java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory > >> java.naming.provider.url=file:/var/mqm/jndictx > >> > >> > >> centos_QM1_xaqcf is defined as a MQXAQueueConnectionFactory. > >> > >> When I enable the application, it doesn't receive any messages from the > >> queue... When I disable the application, I see this in the GlassFish > logs: > >> > >> JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') > >> reason '2009' ('MQRC_CONNECTION_BROKEN'). > >> > >> The MQ queue manager reports unexpected errors (I'll take these up with > >> IBM when I'm more clear on what I'm doing), and dumps First Failure > >> Symptom Reports; yet, its "Connection History" has Reason 2072 > >> (MQRC_SYNCPOINT_NOT_AVAILABLE) and before that Reason 30737 > >> (lpiRC_WAITCANCELLED_ASYNCCONSUME). > >> > >> > >> Am I configuring JMSJCA wrong? > >> > >> > >> Some more test configurations and results: > >> > >> Non-XA connection factory, JMSJCA.NoXA=false := JCD works as expected > >> (emulated-XA?) > >> > >> XA connection factory, JMSJCA.NoXA=false := JCD works as expected > >> > >> Non-XA connection factory, JMSJCA.NoXA=true := Obvious, > >> MQConnectionFactory can't be cast to XAConnectionFactory > >> > >> Non-XA connection factory, JMSJCA.NoXA=true := above :) > >> > >> > >> Thanks in advance, > >> > >> /sysprv > >> > >> > >> > >> > >> Frank Kieviet wrote: > >>> Hi sysprv, > >>> > >>>> The multi-instance queue manager feature (new in v7.0.1) is important > >> to > >>>> us; at first glance that means using > >>>> MQConnectionFactory.setClientReconnectHosts(); > >>>> Can JMSJCA set properties it does not know about? I'll investigate > this > >>>> more tomorrow. > >>> Recently we added a new feature to the WMQ support in JMSJCA that will > >> allow > >>> you to set arbitrary properties on the factory. See > >>> http://wiki.open-esb.java.net/Wiki.jsp?page=JMSJCAReadme#section- > >> JMSJCAReadm > >>> e-SupportForWebSphereMQMQSeries, where you'll find this: > >>> > >>> <Quote> > >>> The com.ibm.mq.jms.MQConnectionFactory has a large list of properties > of > >>> type boolean, int, long, String, URL which can be set. The setter can > be > >>> invoked by specifying a connection URL option named using the > following > >>> convention: remove the 'set' prefix from the name of the setter method > >> and > >>> prepend 'WMQ_', e.g. > >>> > >>> * setMessageRetention(int): WMQ_MessageRetention=1 > >>> * setSecurityExit(String): > WMQ_SecurityExit=wmq.exits.MySecurityExit > >>> * setSparseSubscriptions(boolean): WMQ_SparseSubscriptions=true > >>> </Quote> > >>> > >>>> Now I'm interested in these "naked" factories just for the sake of > >>>> knowing :) > >>> You could write a small Java program that instantiates the factories, > >> and > >>> then bind these factories into JNDI. The JNDI provider could a file > >> provider > >>> so that you'll end up with a file that has a serialized connection > >> factory > >>> in there. You can then tell JMSJCA to use this JNDI file provider to > >> read > >>> the file, deserialize the factory, and as such obtain an instance of > the > >>> factory. This small Java program that would initially instantiate the > >>> factories would simply call new com.ibm.mq.jms.MQConnectionFactory() > and > >> set > >>> some properties on this factory. > >>> > >>> BTW, if you're going down this road, also set > >> JMSJCA.overrideissamerm=true > >>> to workaround an issue in GlassFish/WMQ where GlassFish tries to join > an > >> XA > >>> resource onto a suspended XA resource. > >>> > >>> Frank > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: [hidden email] > >>>> [mailto:users-return-11999-frank.kieviet=sun.com@open- > esb.dev.java.net] > >> On > >>>> Behalf Of ioj > >>>> Sent: Monday, November 02, 2009 11:20 > >>>> To: [hidden email] > >>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>> > >>>> > >>>> Hi Frank, > >>>> > >>>> Yes, as expected, with wmq:// the JCD can connect to the queue > manager > >>>> without any problems. > >>>> > >>>> > >>>> The multi-instance queue manager feature (new in v7.0.1) is important > >> to > >>>> us; at first glance that means using > >>>> MQConnectionFactory.setClientReconnectHosts(); > >>>> Can JMSJCA set properties it does not know about? I'll investigate > this > >>>> more tomorrow. > >>>> > >>>> > >>>> Apart from that, I expected better performance; just an uneducated > >> guess. > >>>> > >>>> Now I'm interested in these "naked" factories just for the sake of > >>>> knowing :) > >>>> > >>>> > >>>> /sysprv > >>>> > >>>> > >>>> Frank Kieviet wrote: > >>>>> Hi sysprv, > >>>>> > >>>>> I would hope that IBM would provide complete backwards > compatibility, > >> so > >>>> you > >>>>> could copy the WMQ jars (com.ibm.mqjms.jar, com.ibm.mq.jar, > >>>>> com.ibm.mqetclient.jar and dhbcore.jar if I remember correctly) into > >> the > >>>> lib > >>>>> directory, and try to use a wmq://xxxx connection URL. If that > works, > >> at > >>>>> least we know how to programmatically create the "naked" factories. > >> Next > >>>> we > >>>>> can figure out how to bind them into JNDI. Before we go there, would > >>>> using > >>>>> the wmq:// URL work for you? Or is it something particular you hope > to > >>>> get > >>>>> out of the JNDI? If so, could you elaborate on that a little bit? > >>>>> > >>>>> Frank > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: ioj [mailto:[hidden email]] > >>>>>> Sent: Monday, November 02, 2009 10:31 > >>>>>> To: [hidden email] > >>>>>> Cc: [hidden email]; [hidden email] > >>>>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>>>> > >>>>>> Hi! > >>>>>> > >>>>>> Yes, that's exactly what I tried to do; our developers are chummy > >> with > >>>>>> STCMS and GF MQ; but for some applications we in ops would rather > use > >>>>>> WMQ. Hence this. And we need WMQ >= 7.0.1 (multi-instance queue > >>>> managers). > >>>>>> Our company's merely an IBM customer; the other way I know of to > get > >>>> WMQ > >>>>>> is the 90 day trial :) > >>>>>> I'll check with IBM on this; perhaps Sun already has some > partnership > >>>> or > >>>>>> agreement with IBM? > >>>>>> > >>>>>> > >>>>>> Yep, I'm in contact with Jason, and bug him from time to time. > >>>>>> > >>>>>> > >>>>>> I have access to test systems with WMQ and GF (CAPS only, not > >> OpenESB) > >>>>>> running on RHEL and AIX. And time too. > >>>>>> > >>>>>> > >>>>>> No problem with moving to OpenESB-users; I just considered this to > be > >>>>>> very JMSJCA-specific. > >>>>>> > >>>>>> > >>>>>> Apart from explicit WMQ7 support (which would be very nice, as WMQ > >> has > >>>>>> become much more JMS-like since v6), how would one go about setting > >> up > >>>>>> naked factories? > >>>>>> > >>>>>> > >>>>>> > >>>>>> /sysprv > >>>>>> > >>>>>> > >>>>>> Frank Kieviet wrote: > >>>>>>> Hi sysprv, > >>>>>>> > >>>>>>> From what you're describing it looks like you're deploying the IBM > >> RAR > >>>>>> into > >>>>>>> GlassFish, then bind its connection factories into JNDI, and then > >> use > >>>>>> JMSJCA > >>>>>>> to look them up. > >>>>>>> > >>>>>>> If that's the case, the issue with that is that the RAR has a lot > of > >>>>>>> functionality to start/stop transactions, participate in > connection > >>>>>> pooling > >>>>>>> etc. To the application, the RAR exposes only application > connection > >>>>>>> factories. In practical terms, these are non-XA connection > >> factories. > >>>> In > >>>>>>> other words, the factories that the RAR exposes to the application > >> are > >>>>>>> wrappers around the "naked" connection factories, and these > wrappers > >>>> add > >>>>>> a > >>>>>>> lot of functionality. > >>>>>>> > >>>>>>> What JMSJCA needs are the "naked" connection factories. What I > mean > >>>> with > >>>>>>> that are the factories that provide a direct line of communication > >>>>>> between > >>>>>>> the calling code and the JMS server, of course all using the JMS > >> api. > >>>>>>> So, to make it work with JNDI, you would have to instantiate the > WMQ > >>>>>> "naked" > >>>>>>> factories, bind them into JNDI (e.g. a file provider if WMQ 7 did > >> not > >>>>>> any > >>>>>>> new facilities such as a built-in JNDI server), and use those in > >>>> JMSJCA. > >>>>>>> We're looking into adding explicit support for WMQ7. First issue > we > >>>> ran > >>>>>> into > >>>>>>> is how to get a copy of WMQ7. Do you know by any chance? > >>>>>>> > >>>>>>> BTW, are you in contact with Jason Baragry? > >>>>>>> > >>>>>>> One more thing: would you mind if we move this discussion to the > >>>> OpenESB > >>>>>>> users list? > >>>>>>> > >>>>>>> Frank > >>>>>>> > >>>>>>> Frank Kieviet > >>>>>>> Senior Staff Engineer, SOA/BI > >>>>>>> Sun Microsystems, Monrovia, CA > >>>>>>> Tel +1 626 471 6322 > >>>>>>> Blog: http://frankkieviet.blogspot.com/ > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: ioj [mailto:[hidden email]] > >>>>>>>> Sent: Monday, November 02, 2009 08:44 > >>>>>>>> To: [hidden email] > >>>>>>>> Subject: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>>>>>> > >>>>>>>> Hi Frank :) > >>>>>>>> > >>>>>>>> Configured a JMSJCA-driven JCD in jndi:// mode to connect to a > >>>>>> WebSphere > >>>>>>>> MQ 7 queue; Getting this error: > >>>>>>>> > >>>>>>>> [#|2009-11-02T17:09:55.496+0100|INFO|sun- > >>>>>>>> > >> > appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=18;_Threa > >>>>>>>> dName=httpWorkerThread-4848-4;dpJMSJCATest_1_0_0;|LDR5010: > >>>>>>>> All ejb(s) of [dpJMSJCATest_1_0_0] loaded successfully!|#] > >>>>>>>> > >>>>>>>> [#|2009-11-02T17:09:55.498+0100|WARNING|sun- > >>>>>>>> > >> > appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=25;_ThreadName=JMSJC > >>>>>>>> A > >>>>>>>> connect;Context=TestProjects | > >>>>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=07fb37e9- > 63b3- > >>>>>> 4015- > >>>>>>>> a035-dcc50c47ac93;|JMSJCA-E016: > >>>>>>>> [serial-QueueReceiver(QJMSJCATEST){TestProjects | > >>>>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message > >>>>>>>> delivery initiation failed (attempt #1); will retry in 1 seconds. > >> The > >>>>>>>> error was: > com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl > >>>>>>>> cannot be cast to javax.jms.XAQueueConnectionFactory > >>>>>>>> java.lang.ClassCastException: > >>>>>>>> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl cannot > be > >>>> cast > >>>>>>>> to javax.jms.XAQueueConnectionFactory > >>>>>>>> at > >>>>>>>> > >> > com.stc.jmsjca.jndi.RAJNDIObjectFactory.createConnectionFactory(RAJNDIObje > >>>>>>>> ctFactory.java:208) > >>>>>>>> at > >> com.stc.jmsjca.core.SerialDelivery.start(SerialDelivery.java:74) > >>>>>>>> at > >> com.stc.jmsjca.core.Activation.asyncStart(Activation.java:552) > >>>>>>>> at > >> com.stc.jmsjca.core.Activation.access$000(Activation.java:81) > >>>>>>>> at com.stc.jmsjca.core.Activation$1.run(Activation.java:347) > >>>>>>>> at java.lang.Thread.run(Thread.java:619) > >>>>>>>> |#] > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Details: > >>>>>>>> > >>>>>>>> I've installed and configured the WMQ 7 RA from IBM in GlassFish > >>>>>>>> Enterprise v2.1 Patch 02. The IVT (installation verification > test) > >>>> app > >>>>>>>> from IBM runs fine and passes all tests. > >>>>>>>> > >>>>>>>> Next, I have the simplest message driven JCD you can think of: it > >>>> reads > >>>>>>>> a TextMessage using JMSJCA and writes the Text to the server.log. > >>>> Works > >>>>>>>> fine with GlassFish MQ. > >>>>>>>> > >>>>>>>> Then I have a connector connection pool of type > >>>> QueueConnectionFactory, > >>>>>>>> using the IBM RA, configured for XA (Transaction Support: > >>>>>> XATransaction) > >>>>>>>> When I configure JMSJCA (inside GF, with the Env overrides in > CAPS > >>>> 6.x) > >>>>>>>> with: > >>>>>>>> > >>>>>>>> Connection URL: jndi:// > >>>>>>>> JMSJCA.NoXA=false > >>>>>>>> JMSJCA.QueueCF=jms/wmq/xa/qcf > >>>>>>>> > >>>>>>>> and enable the JCD, I get the message above. > >>>>>>>> > >>>>>>>> I've made sure that the MQ transaction support jar is available > to > >>>> the > >>>>>>>> appserver etc. etc. (the IVT passes all tests incl. transactions > - > >>>>>>>> though it's much simpler than a JCD with JMSJCA +) > >>>>>>>> > >>>>>>>> What's going wrong here, and how can it be fixed? > >>>>>>>> > >>>>>>>> > >>>>>>>> Thanks in advance! > >>>>>>>> /sysprv > >>>>>>>> > >>>>>>>> > >> --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
|
sysprv
|
That seems to have done the job :) After a restart of GF and the MQ queue manager, everything seems to work as it should. Thanks for your help! Frank Kieviet wrote: > Hi sysprv, > > Could you add the following option as well? > JMSJCA.concurrencymode=sync > > This will change the delivery from serial to sync which is the only mode > that works with WMQ and XA. > > HTH, > Frank > > >> -----Original Message----- >> From: [hidden email] >> [mailto:[hidden email]] On >> Behalf Of ioj >> Sent: Friday, November 06, 2009 16:01 >> To: [hidden email] >> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >> >> Hi Frank, >> >> My bad, it should be: >> >> >> Non-XA connection factory, JMSJCA.NoXA=true := JCD works as expected >> >> (emulated-XA?) >> >> >> >> A longer snippet from the log is attached (in case of hard wrapping), >> and inline: >> >> [#|2009-11-07T00:54:00.106+0100|INFO|sun- >> appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=39;_ThreadName=JMSJC >> A >> connect;Context=TestProjects | >> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;|JMSJCA-E015: >> [serial-QueueReceiver(QJMSJCATEST){TestProjects | >> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message >> delivery initiation was successful.|#] >> >> >> There are already some messages on the queue; I expect to see their >> contents in server.log, but it seems they're never delivered to the JCD. >> >> Then I disable the JCD: >> >> [#|2009-11-07T00:54:40.928+0100|WARNING|sun- >> appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p >> : >> thread-pool-1; w: 41;Context=TestProjects | >> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14-4680- >> 82dc-5aae8f323bba;|JMSJCA-E054: >> Unexpected exception stopping JMS connection: JMSCMQ0002: The method >> 'MQCTL' failed.. >> com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ0002: The method >> 'MQCTL' failed. A WebSphere MQ call failed. Please see the linked >> exception for more information. >> at >> com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav >> a:608) >> at >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >> 236) >> at >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >> 275) >> at >> com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService >> (WMQConsumerOwnerShadow.java:308) >> at >> com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.stop(WMQConsumerOwn >> erShadow.java:654) >> at >> com.ibm.msg.client.wmq.internal.WMQSession.stop(WMQSession.java:1466) >> at >> com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:20 >> 28) >> at >> com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:19 >> 36) >> at >> com.ibm.msg.client.jms.internal.JmsConnectionImpl.stop(JmsConnectionImpl.j >> ava:792) >> at com.ibm.mq.jms.MQConnection.stop(MQConnection.java:471) >> at >> com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:153) >> at >> com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) >> at com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) >> at >> com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc >> eAdapter.java:717) >> at >> com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn >> ectorMessageBeanClient.java:313) >> at >> com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me >> ssageBeanContainer.java:920) >> at >> com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic >> e(MessageBeanContainer.java:912) >> at >> com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) >> at >> com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T >> hreadPoolImpl.java:555) >> Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed >> with compcode '2' ('MQCC_FAILED') reason '2009' >> ('MQRC_CONNECTION_BROKEN'). >> at >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >> 223) >> ... 17 more >> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 >> at >> com.ibm.mq.jmqi.remote.internal.RemoteHconn.exchangeTSH(RemoteHconn.java:1 >> 472) >> at >> com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.sendNotification(Remote >> AsyncConsume.java:409) >> at >> com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.sendConnState(RemoteAsy >> ncConsume.java:522) >> at >> com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQCTL(RemoteFAP.java:2066) >> at >> com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService >> (WMQConsumerOwnerShadow.java:296) >> ... 15 more >> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error on >> receive from host 'centos/10.0.0.1:1414 (centos)'. >> [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] >> at >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr >> ead.java:698) >> at >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr >> ead.java:638) >> at >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 >> 36) >> at >> com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu >> eItem.java:209) >> at >> com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si >> mpleWorkQueueItem.java:100) >> at >> com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte >> m.java:224) >> at >> com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI >> tem(WorkQueueManager.java:298) >> at >> com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement >> ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) >> |#] >> >> [#|2009-11-07T00:54:40.933+0100|WARNING|sun- >> appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p >> : >> thread-pool-1; w: 41;Context=TestProjects | >> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14-4680- >> 82dc-5aae8f323bba;|JMSJCA-E087: >> Error while closing session: JMSCMQ0002: The method 'MQCTL' failed. >> com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ0002: The method >> 'MQCTL' failed. A WebSphere MQ call failed. Please see the linked >> exception for more information. >> at >> com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav >> a:608) >> at >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >> 236) >> at >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >> 275) >> at >> com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService >> (WMQConsumerOwnerShadow.java:308) >> at >> com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.stop(WMQConsumerOwn >> erShadow.java:654) >> at >> com.ibm.msg.client.wmq.internal.WMQSession.stop(WMQSession.java:1466) >> at >> com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:20 >> 28) >> at >> com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:2 >> 89) >> at >> com.ibm.msg.client.jms.internal.JmsXASessionImpl.close(JmsXASessionImpl.ja >> va:234) >> at >> com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:2 >> 35) >> at >> com.ibm.msg.client.jms.internal.JmsXASessionImpl.close(JmsXASessionImpl.ja >> va:199) >> at com.ibm.mq.jms.MQSession.close(MQSession.java:195) >> at >> com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:167) >> at >> com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) >> at com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) >> at >> com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc >> eAdapter.java:717) >> at >> com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn >> ectorMessageBeanClient.java:313) >> at >> com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me >> ssageBeanContainer.java:920) >> at >> com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic >> e(MessageBeanContainer.java:912) >> at >> com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) >> at >> com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T >> hreadPoolImpl.java:555) >> Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed >> with compcode '2' ('MQCC_FAILED') reason '2009' >> ('MQRC_CONNECTION_BROKEN'). >> at >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >> 223) >> ... 19 more >> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 >> at >> com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:381 >> ) >> at >> com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:304 >> ) >> at >> com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQCTL(RemoteFAP.java:1923) >> at >> com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService >> (WMQConsumerOwnerShadow.java:296) >> ... 17 more >> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error on >> receive from host 'centos/10.0.0.1:1414 (centos)'. >> [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] >> at >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr >> ead.java:698) >> at >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr >> ead.java:638) >> at >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 >> 36) >> at >> com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu >> eItem.java:209) >> at >> com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si >> mpleWorkQueueItem.java:100) >> at >> com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte >> m.java:224) >> at >> com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI >> tem(WorkQueueManager.java:298) >> at >> com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement >> ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) >> |#] >> >> [#|2009-11-07T00:54:40.935+0100|WARNING|sun- >> appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p >> : >> thread-pool-1; w: 41;Context=TestProjects | >> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14-4680- >> 82dc-5aae8f323bba;|JMSJCA-E055: >> Unexpected exception closing JMS connection: JMSWMQ0019: Failed to >> disconnect from queue manager '' using connection mode '1' and host name >> 'centos'. >> com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ0019: Failed to >> disconnect from queue manager '' using connection mode '1' and host name >> 'centos'. Please see the linked exception for more information. >> at >> com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav >> a:608) >> at >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >> 236) >> at >> com.ibm.msg.client.wmq.internal.WMQConnection.close(WMQConnection.java:677 >> ) >> at >> com.ibm.msg.client.jms.internal.JmsConnectionImpl.close(JmsConnectionImpl. >> java:328) >> at com.ibm.mq.jms.MQConnection.close(MQConnection.java:93) >> at >> com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:175) >> at >> com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) >> at com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) >> at >> com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc >> eAdapter.java:717) >> at >> com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn >> ectorMessageBeanClient.java:313) >> at >> com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me >> ssageBeanContainer.java:920) >> at >> com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic >> e(MessageBeanContainer.java:912) >> at >> com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) >> at >> com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T >> hreadPoolImpl.java:555) >> Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed >> with compcode '2' ('MQCC_FAILED') reason '2009' >> ('MQRC_CONNECTION_BROKEN'). >> at >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >> 223) >> ... 12 more >> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 >> at >> com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:381 >> ) >> at >> com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:304 >> ) >> at >> com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQDISC(RemoteFAP.java:2347) >> at >> com.ibm.msg.client.wmq.internal.WMQConnection.close(WMQConnection.java:659 >> ) >> ... 11 more >> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error on >> receive from host 'centos/10.0.0.1:1414 (centos)'. >> [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] >> at >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr >> ead.java:698) >> at >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr >> ead.java:638) >> at >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 >> 36) >> at >> com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu >> eItem.java:209) >> at >> com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si >> mpleWorkQueueItem.java:100) >> at >> com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte >> m.java:224) >> at >> com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI >> tem(WorkQueueManager.java:298) >> at >> com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement >> ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) >> |#] >> >> [#|2009-11-07T00:54:41.025+0100|INFO|sun- >> appserver2.1|javax.enterprise.system.core|_ThreadID=17;_ThreadName=httpWor >> kerThread-4848-1;dpJMSJCATest_1_0_0;|CORE5022: >> All ejb(s) of [dpJMSJCATest_1_0_0] were unloaded successfully!|#] >> >> >> >> >> >> >> >> Frank Kieviet wrote: >>> Hi sysprv, >>> >>> Not sure what is going wrong here. You configuration appears ok, >> although I >>> don't think you can have seen success with a non-XA factory if you use >>> NoXA=false. Can you send a larger snippet of the server log? >>> >>> Frank >>> >>> >>>> -----Original Message----- >>>> From: [hidden email] >>>> [mailto:[hidden email]] >> On >>>> Behalf Of ioj >>>> Sent: Friday, November 06, 2009 07:54 >>>> To: [hidden email] >>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>> >>>> >>>> Hi! >>>> >>>> I've done a little more testing with JMSJCA jndi://, MQ 7 and a simple >>>> JCD. >>>> >>>> The JCD is strictly a consumer, and the CAPS classic documentation >> tells >>>> us that means it works under a XA transaction. >>>> >>>> This is my JMSJCA configuration (env object): >>>> >>>> Connection URL: jndi:// >>>> Options: >>>> >>>> JMSJCA.NoXA=false >>>> JMSJCA.overrideissamerm=true >>>> JMSJCA.QueueCF=centos_QM1_xaqcf >>>> java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory >>>> java.naming.provider.url=file:/var/mqm/jndictx >>>> >>>> >>>> centos_QM1_xaqcf is defined as a MQXAQueueConnectionFactory. >>>> >>>> When I enable the application, it doesn't receive any messages from the >>>> queue... When I disable the application, I see this in the GlassFish >> logs: >>>> JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') >>>> reason '2009' ('MQRC_CONNECTION_BROKEN'). >>>> >>>> The MQ queue manager reports unexpected errors (I'll take these up with >>>> IBM when I'm more clear on what I'm doing), and dumps First Failure >>>> Symptom Reports; yet, its "Connection History" has Reason 2072 >>>> (MQRC_SYNCPOINT_NOT_AVAILABLE) and before that Reason 30737 >>>> (lpiRC_WAITCANCELLED_ASYNCCONSUME). >>>> >>>> >>>> Am I configuring JMSJCA wrong? >>>> >>>> >>>> Some more test configurations and results: >>>> >>>> Non-XA connection factory, JMSJCA.NoXA=false := JCD works as expected >>>> (emulated-XA?) >>>> >>>> XA connection factory, JMSJCA.NoXA=false := JCD works as expected >>>> >>>> Non-XA connection factory, JMSJCA.NoXA=true := Obvious, >>>> MQConnectionFactory can't be cast to XAConnectionFactory >>>> >>>> Non-XA connection factory, JMSJCA.NoXA=true := above :) >>>> >>>> >>>> Thanks in advance, >>>> >>>> /sysprv >>>> >>>> >>>> >>>> >>>> Frank Kieviet wrote: >>>>> Hi sysprv, >>>>> >>>>>> The multi-instance queue manager feature (new in v7.0.1) is important >>>> to >>>>>> us; at first glance that means using >>>>>> MQConnectionFactory.setClientReconnectHosts(); >>>>>> Can JMSJCA set properties it does not know about? I'll investigate >> this >>>>>> more tomorrow. >>>>> Recently we added a new feature to the WMQ support in JMSJCA that will >>>> allow >>>>> you to set arbitrary properties on the factory. See >>>>> http://wiki.open-esb.java.net/Wiki.jsp?page=JMSJCAReadme#section- >>>> JMSJCAReadm >>>>> e-SupportForWebSphereMQMQSeries, where you'll find this: >>>>> >>>>> <Quote> >>>>> The com.ibm.mq.jms.MQConnectionFactory has a large list of properties >> of >>>>> type boolean, int, long, String, URL which can be set. The setter can >> be >>>>> invoked by specifying a connection URL option named using the >> following >>>>> convention: remove the 'set' prefix from the name of the setter method >>>> and >>>>> prepend 'WMQ_', e.g. >>>>> >>>>> * setMessageRetention(int): WMQ_MessageRetention=1 >>>>> * setSecurityExit(String): >> WMQ_SecurityExit=wmq.exits.MySecurityExit >>>>> * setSparseSubscriptions(boolean): WMQ_SparseSubscriptions=true >>>>> </Quote> >>>>> >>>>>> Now I'm interested in these "naked" factories just for the sake of >>>>>> knowing :) >>>>> You could write a small Java program that instantiates the factories, >>>> and >>>>> then bind these factories into JNDI. The JNDI provider could a file >>>> provider >>>>> so that you'll end up with a file that has a serialized connection >>>> factory >>>>> in there. You can then tell JMSJCA to use this JNDI file provider to >>>> read >>>>> the file, deserialize the factory, and as such obtain an instance of >> the >>>>> factory. This small Java program that would initially instantiate the >>>>> factories would simply call new com.ibm.mq.jms.MQConnectionFactory() >> and >>>> set >>>>> some properties on this factory. >>>>> >>>>> BTW, if you're going down this road, also set >>>> JMSJCA.overrideissamerm=true >>>>> to workaround an issue in GlassFish/WMQ where GlassFish tries to join >> an >>>> XA >>>>> resource onto a suspended XA resource. >>>>> >>>>> Frank >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: [hidden email] >>>>>> [mailto:users-return-11999-frank.kieviet=sun.com@open- >> esb.dev.java.net] >>>> On >>>>>> Behalf Of ioj >>>>>> Sent: Monday, November 02, 2009 11:20 >>>>>> To: [hidden email] >>>>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>>>> >>>>>> >>>>>> Hi Frank, >>>>>> >>>>>> Yes, as expected, with wmq:// the JCD can connect to the queue >> manager >>>>>> without any problems. >>>>>> >>>>>> >>>>>> The multi-instance queue manager feature (new in v7.0.1) is important >>>> to >>>>>> us; at first glance that means using >>>>>> MQConnectionFactory.setClientReconnectHosts(); >>>>>> Can JMSJCA set properties it does not know about? I'll investigate >> this >>>>>> more tomorrow. >>>>>> >>>>>> >>>>>> Apart from that, I expected better performance; just an uneducated >>>> guess. >>>>>> Now I'm interested in these "naked" factories just for the sake of >>>>>> knowing :) >>>>>> >>>>>> >>>>>> /sysprv >>>>>> >>>>>> >>>>>> Frank Kieviet wrote: >>>>>>> Hi sysprv, >>>>>>> >>>>>>> I would hope that IBM would provide complete backwards >> compatibility, >>>> so >>>>>> you >>>>>>> could copy the WMQ jars (com.ibm.mqjms.jar, com.ibm.mq.jar, >>>>>>> com.ibm.mqetclient.jar and dhbcore.jar if I remember correctly) into >>>> the >>>>>> lib >>>>>>> directory, and try to use a wmq://xxxx connection URL. If that >> works, >>>> at >>>>>>> least we know how to programmatically create the "naked" factories. >>>> Next >>>>>> we >>>>>>> can figure out how to bind them into JNDI. Before we go there, would >>>>>> using >>>>>>> the wmq:// URL work for you? Or is it something particular you hope >> to >>>>>> get >>>>>>> out of the JNDI? If so, could you elaborate on that a little bit? >>>>>>> >>>>>>> Frank >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ioj [mailto:[hidden email]] >>>>>>>> Sent: Monday, November 02, 2009 10:31 >>>>>>>> To: [hidden email] >>>>>>>> Cc: [hidden email]; [hidden email] >>>>>>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>>>>>> >>>>>>>> Hi! >>>>>>>> >>>>>>>> Yes, that's exactly what I tried to do; our developers are chummy >>>> with >>>>>>>> STCMS and GF MQ; but for some applications we in ops would rather >> use >>>>>>>> WMQ. Hence this. And we need WMQ >= 7.0.1 (multi-instance queue >>>>>> managers). >>>>>>>> Our company's merely an IBM customer; the other way I know of to >> get >>>>>> WMQ >>>>>>>> is the 90 day trial :) >>>>>>>> I'll check with IBM on this; perhaps Sun already has some >> partnership >>>>>> or >>>>>>>> agreement with IBM? >>>>>>>> >>>>>>>> >>>>>>>> Yep, I'm in contact with Jason, and bug him from time to time. >>>>>>>> >>>>>>>> >>>>>>>> I have access to test systems with WMQ and GF (CAPS only, not >>>> OpenESB) >>>>>>>> running on RHEL and AIX. And time too. >>>>>>>> >>>>>>>> >>>>>>>> No problem with moving to OpenESB-users; I just considered this to >> be >>>>>>>> very JMSJCA-specific. >>>>>>>> >>>>>>>> >>>>>>>> Apart from explicit WMQ7 support (which would be very nice, as WMQ >>>> has >>>>>>>> become much more JMS-like since v6), how would one go about setting >>>> up >>>>>>>> naked factories? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> /sysprv >>>>>>>> >>>>>>>> >>>>>>>> Frank Kieviet wrote: >>>>>>>>> Hi sysprv, >>>>>>>>> >>>>>>>>> From what you're describing it looks like you're deploying the IBM >>>> RAR >>>>>>>> into >>>>>>>>> GlassFish, then bind its connection factories into JNDI, and then >>>> use >>>>>>>> JMSJCA >>>>>>>>> to look them up. >>>>>>>>> >>>>>>>>> If that's the case, the issue with that is that the RAR has a lot >> of >>>>>>>>> functionality to start/stop transactions, participate in >> connection >>>>>>>> pooling >>>>>>>>> etc. To the application, the RAR exposes only application >> connection >>>>>>>>> factories. In practical terms, these are non-XA connection >>>> factories. >>>>>> In >>>>>>>>> other words, the factories that the RAR exposes to the application >>>> are >>>>>>>>> wrappers around the "naked" connection factories, and these >> wrappers >>>>>> add >>>>>>>> a >>>>>>>>> lot of functionality. >>>>>>>>> >>>>>>>>> What JMSJCA needs are the "naked" connection factories. What I >> mean >>>>>> with >>>>>>>>> that are the factories that provide a direct line of communication >>>>>>>> between >>>>>>>>> the calling code and the JMS server, of course all using the JMS >>>> api. >>>>>>>>> So, to make it work with JNDI, you would have to instantiate the >> WMQ >>>>>>>> "naked" >>>>>>>>> factories, bind them into JNDI (e.g. a file provider if WMQ 7 did >>>> not >>>>>>>> any >>>>>>>>> new facilities such as a built-in JNDI server), and use those in >>>>>> JMSJCA. >>>>>>>>> We're looking into adding explicit support for WMQ7. First issue >> we >>>>>> ran >>>>>>>> into >>>>>>>>> is how to get a copy of WMQ7. Do you know by any chance? >>>>>>>>> >>>>>>>>> BTW, are you in contact with Jason Baragry? >>>>>>>>> >>>>>>>>> One more thing: would you mind if we move this discussion to the >>>>>> OpenESB >>>>>>>>> users list? >>>>>>>>> >>>>>>>>> Frank >>>>>>>>> >>>>>>>>> Frank Kieviet >>>>>>>>> Senior Staff Engineer, SOA/BI >>>>>>>>> Sun Microsystems, Monrovia, CA >>>>>>>>> Tel +1 626 471 6322 >>>>>>>>> Blog: http://frankkieviet.blogspot.com/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: ioj [mailto:[hidden email]] >>>>>>>>>> Sent: Monday, November 02, 2009 08:44 >>>>>>>>>> To: [hidden email] >>>>>>>>>> Subject: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>>>>>>>> >>>>>>>>>> Hi Frank :) >>>>>>>>>> >>>>>>>>>> Configured a JMSJCA-driven JCD in jndi:// mode to connect to a >>>>>>>> WebSphere >>>>>>>>>> MQ 7 queue; Getting this error: >>>>>>>>>> >>>>>>>>>> [#|2009-11-02T17:09:55.496+0100|INFO|sun- >>>>>>>>>> >> appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=18;_Threa >>>>>>>>>> dName=httpWorkerThread-4848-4;dpJMSJCATest_1_0_0;|LDR5010: >>>>>>>>>> All ejb(s) of [dpJMSJCATest_1_0_0] loaded successfully!|#] >>>>>>>>>> >>>>>>>>>> [#|2009-11-02T17:09:55.498+0100|WARNING|sun- >>>>>>>>>> >> appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=25;_ThreadName=JMSJC >>>>>>>>>> A >>>>>>>>>> connect;Context=TestProjects | >>>>>>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=07fb37e9- >> 63b3- >>>>>>>> 4015- >>>>>>>>>> a035-dcc50c47ac93;|JMSJCA-E016: >>>>>>>>>> [serial-QueueReceiver(QJMSJCATEST){TestProjects | >>>>>>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message >>>>>>>>>> delivery initiation failed (attempt #1); will retry in 1 seconds. >>>> The >>>>>>>>>> error was: >> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl >>>>>>>>>> cannot be cast to javax.jms.XAQueueConnectionFactory >>>>>>>>>> java.lang.ClassCastException: >>>>>>>>>> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl cannot >> be >>>>>> cast >>>>>>>>>> to javax.jms.XAQueueConnectionFactory >>>>>>>>>> at >>>>>>>>>> >> com.stc.jmsjca.jndi.RAJNDIObjectFactory.createConnectionFactory(RAJNDIObje >>>>>>>>>> ctFactory.java:208) >>>>>>>>>> at >>>> com.stc.jmsjca.core.SerialDelivery.start(SerialDelivery.java:74) >>>>>>>>>> at >>>> com.stc.jmsjca.core.Activation.asyncStart(Activation.java:552) >>>>>>>>>> at >>>> com.stc.jmsjca.core.Activation.access$000(Activation.java:81) >>>>>>>>>> at com.stc.jmsjca.core.Activation$1.run(Activation.java:347) >>>>>>>>>> at java.lang.Thread.run(Thread.java:619) >>>>>>>>>> |#] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Details: >>>>>>>>>> >>>>>>>>>> I've installed and configured the WMQ 7 RA from IBM in GlassFish >>>>>>>>>> Enterprise v2.1 Patch 02. The IVT (installation verification >> test) >>>>>> app >>>>>>>>>> from IBM runs fine and passes all tests. >>>>>>>>>> >>>>>>>>>> Next, I have the simplest message driven JCD you can think of: it >>>>>> reads >>>>>>>>>> a TextMessage using JMSJCA and writes the Text to the server.log. >>>>>> Works >>>>>>>>>> fine with GlassFish MQ. >>>>>>>>>> >>>>>>>>>> Then I have a connector connection pool of type >>>>>> QueueConnectionFactory, >>>>>>>>>> using the IBM RA, configured for XA (Transaction Support: >>>>>>>> XATransaction) >>>>>>>>>> When I configure JMSJCA (inside GF, with the Env overrides in >> CAPS >>>>>> 6.x) >>>>>>>>>> with: >>>>>>>>>> >>>>>>>>>> Connection URL: jndi:// >>>>>>>>>> JMSJCA.NoXA=false >>>>>>>>>> JMSJCA.QueueCF=jms/wmq/xa/qcf >>>>>>>>>> >>>>>>>>>> and enable the JCD, I get the message above. >>>>>>>>>> >>>>>>>>>> I've made sure that the MQ transaction support jar is available >> to >>>>>> the >>>>>>>>>> appserver etc. etc. (the IVT passes all tests incl. transactions >> - >>>>>>>>>> though it's much simpler than a JCD with JMSJCA +) >>>>>>>>>> >>>>>>>>>> What's going wrong here, and how can it be fixed? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks in advance! >>>>>>>>>> /sysprv >>>>>>>>>> >>>>>>>>>> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
|
Frank Kieviet
|
Great! I'm glad it works now! Do let us know if you find on further testing
that it doesn't fully meet your requirements, e.g. with respect to usability. Frank > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On > Behalf Of ioj > Sent: Friday, November 06, 2009 16:51 > To: [hidden email] > Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > > > That seems to have done the job :) > > After a restart of GF and the MQ queue manager, everything seems to work > as it should. > > Thanks for your help! > > > > > Frank Kieviet wrote: > > Hi sysprv, > > > > Could you add the following option as well? > > JMSJCA.concurrencymode=sync > > > > This will change the delivery from serial to sync which is the only mode > > that works with WMQ and XA. > > > > HTH, > > Frank > > > > > >> -----Original Message----- > >> From: [hidden email] > >> [mailto:[hidden email]] > On > >> Behalf Of ioj > >> Sent: Friday, November 06, 2009 16:01 > >> To: [hidden email] > >> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >> > >> Hi Frank, > >> > >> My bad, it should be: > >> > >> >> Non-XA connection factory, JMSJCA.NoXA=true := JCD works as > expected > >> >> (emulated-XA?) > >> > >> > >> > >> A longer snippet from the log is attached (in case of hard wrapping), > >> and inline: > >> > >> [#|2009-11-07T00:54:00.106+0100|INFO|sun- > >> > appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=39;_ThreadName=JMSJC > >> A > >> connect;Context=TestProjects | > >> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;|JMSJCA-E015: > >> [serial-QueueReceiver(QJMSJCATEST){TestProjects | > >> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message > >> delivery initiation was successful.|#] > >> > >> > >> There are already some messages on the queue; I expect to see their > >> contents in server.log, but it seems they're never delivered to the > JCD. > >> > >> Then I disable the JCD: > >> > >> [#|2009-11-07T00:54:40.928+0100|WARNING|sun- > >> > appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p > >> : > >> thread-pool-1; w: 41;Context=TestProjects | > >> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14- > 4680- > >> 82dc-5aae8f323bba;|JMSJCA-E054: > >> Unexpected exception stopping JMS connection: JMSCMQ0002: The method > >> 'MQCTL' failed.. > >> com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ0002: The method > >> 'MQCTL' failed. A WebSphere MQ call failed. Please see the linked > >> exception for more information. > >> at > >> > com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav > >> a:608) > >> at > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >> 236) > >> at > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >> 275) > >> at > >> > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService > >> (WMQConsumerOwnerShadow.java:308) > >> at > >> > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.stop(WMQConsumerOwn > >> erShadow.java:654) > >> at > >> com.ibm.msg.client.wmq.internal.WMQSession.stop(WMQSession.java:1466) > >> at > >> > com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:20 > >> 28) > >> at > >> > com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:19 > >> 36) > >> at > >> > com.ibm.msg.client.jms.internal.JmsConnectionImpl.stop(JmsConnectionImpl.j > >> ava:792) > >> at com.ibm.mq.jms.MQConnection.stop(MQConnection.java:471) > >> at > >> com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:153) > >> at > >> com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) > >> at > com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) > >> at > >> > com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc > >> eAdapter.java:717) > >> at > >> > com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn > >> ectorMessageBeanClient.java:313) > >> at > >> > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me > >> ssageBeanContainer.java:920) > >> at > >> > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic > >> e(MessageBeanContainer.java:912) > >> at > >> com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) > >> at > >> > com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T > >> hreadPoolImpl.java:555) > >> Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed > >> with compcode '2' ('MQCC_FAILED') reason '2009' > >> ('MQRC_CONNECTION_BROKEN'). > >> at > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >> 223) > >> ... 17 more > >> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteHconn.exchangeTSH(RemoteHconn.java:1 > >> 472) > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.sendNotification(Remote > >> AsyncConsume.java:409) > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.sendConnState(RemoteAsy > >> ncConsume.java:522) > >> at > >> com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQCTL(RemoteFAP.java:2066) > >> at > >> > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService > >> (WMQConsumerOwnerShadow.java:296) > >> ... 15 more > >> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error > on > >> receive from host 'centos/10.0.0.1:1414 (centos)'. > >> [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr > >> ead.java:698) > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr > >> ead.java:638) > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 > >> 36) > >> at > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu > >> eItem.java:209) > >> at > >> > com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si > >> mpleWorkQueueItem.java:100) > >> at > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte > >> m.java:224) > >> at > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI > >> tem(WorkQueueManager.java:298) > >> at > >> > com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement > >> ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) > >> |#] > >> > >> [#|2009-11-07T00:54:40.933+0100|WARNING|sun- > >> > appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p > >> : > >> thread-pool-1; w: 41;Context=TestProjects | > >> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14- > 4680- > >> 82dc-5aae8f323bba;|JMSJCA-E087: > >> Error while closing session: JMSCMQ0002: The method 'MQCTL' failed. > >> com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ0002: The method > >> 'MQCTL' failed. A WebSphere MQ call failed. Please see the linked > >> exception for more information. > >> at > >> > com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav > >> a:608) > >> at > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >> 236) > >> at > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >> 275) > >> at > >> > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService > >> (WMQConsumerOwnerShadow.java:308) > >> at > >> > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.stop(WMQConsumerOwn > >> erShadow.java:654) > >> at > >> com.ibm.msg.client.wmq.internal.WMQSession.stop(WMQSession.java:1466) > >> at > >> > com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:20 > >> 28) > >> at > >> > com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:2 > >> 89) > >> at > >> > com.ibm.msg.client.jms.internal.JmsXASessionImpl.close(JmsXASessionImpl.ja > >> va:234) > >> at > >> > com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:2 > >> 35) > >> at > >> > com.ibm.msg.client.jms.internal.JmsXASessionImpl.close(JmsXASessionImpl.ja > >> va:199) > >> at com.ibm.mq.jms.MQSession.close(MQSession.java:195) > >> at > >> com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:167) > >> at > >> com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) > >> at > com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) > >> at > >> > com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc > >> eAdapter.java:717) > >> at > >> > com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn > >> ectorMessageBeanClient.java:313) > >> at > >> > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me > >> ssageBeanContainer.java:920) > >> at > >> > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic > >> e(MessageBeanContainer.java:912) > >> at > >> com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) > >> at > >> > com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T > >> hreadPoolImpl.java:555) > >> Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed > >> with compcode '2' ('MQCC_FAILED') reason '2009' > >> ('MQRC_CONNECTION_BROKEN'). > >> at > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >> 223) > >> ... 19 more > >> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:381 > >> ) > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:304 > >> ) > >> at > >> com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQCTL(RemoteFAP.java:1923) > >> at > >> > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService > >> (WMQConsumerOwnerShadow.java:296) > >> ... 17 more > >> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error > on > >> receive from host 'centos/10.0.0.1:1414 (centos)'. > >> [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr > >> ead.java:698) > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr > >> ead.java:638) > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 > >> 36) > >> at > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu > >> eItem.java:209) > >> at > >> > com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si > >> mpleWorkQueueItem.java:100) > >> at > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte > >> m.java:224) > >> at > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI > >> tem(WorkQueueManager.java:298) > >> at > >> > com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement > >> ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) > >> |#] > >> > >> [#|2009-11-07T00:54:40.935+0100|WARNING|sun- > >> > appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p > >> : > >> thread-pool-1; w: 41;Context=TestProjects | > >> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14- > 4680- > >> 82dc-5aae8f323bba;|JMSJCA-E055: > >> Unexpected exception closing JMS connection: JMSWMQ0019: Failed to > >> disconnect from queue manager '' using connection mode '1' and host > name > >> 'centos'. > >> com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ0019: Failed to > >> disconnect from queue manager '' using connection mode '1' and host > name > >> 'centos'. Please see the linked exception for more information. > >> at > >> > com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav > >> a:608) > >> at > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >> 236) > >> at > >> > com.ibm.msg.client.wmq.internal.WMQConnection.close(WMQConnection.java:677 > >> ) > >> at > >> > com.ibm.msg.client.jms.internal.JmsConnectionImpl.close(JmsConnectionImpl. > >> java:328) > >> at com.ibm.mq.jms.MQConnection.close(MQConnection.java:93) > >> at > >> com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:175) > >> at > >> com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) > >> at > com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) > >> at > >> > com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc > >> eAdapter.java:717) > >> at > >> > com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn > >> ectorMessageBeanClient.java:313) > >> at > >> > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me > >> ssageBeanContainer.java:920) > >> at > >> > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic > >> e(MessageBeanContainer.java:912) > >> at > >> com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) > >> at > >> > com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T > >> hreadPoolImpl.java:555) > >> Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed > >> with compcode '2' ('MQCC_FAILED') reason '2009' > >> ('MQRC_CONNECTION_BROKEN'). > >> at > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >> 223) > >> ... 12 more > >> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:381 > >> ) > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:304 > >> ) > >> at > >> com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQDISC(RemoteFAP.java:2347) > >> at > >> > com.ibm.msg.client.wmq.internal.WMQConnection.close(WMQConnection.java:659 > >> ) > >> ... 11 more > >> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error > on > >> receive from host 'centos/10.0.0.1:1414 (centos)'. > >> [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr > >> ead.java:698) > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr > >> ead.java:638) > >> at > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 > >> 36) > >> at > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu > >> eItem.java:209) > >> at > >> > com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si > >> mpleWorkQueueItem.java:100) > >> at > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte > >> m.java:224) > >> at > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI > >> tem(WorkQueueManager.java:298) > >> at > >> > com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement > >> ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) > >> |#] > >> > >> [#|2009-11-07T00:54:41.025+0100|INFO|sun- > >> > appserver2.1|javax.enterprise.system.core|_ThreadID=17;_ThreadName=httpWor > >> kerThread-4848-1;dpJMSJCATest_1_0_0;|CORE5022: > >> All ejb(s) of [dpJMSJCATest_1_0_0] were unloaded successfully!|#] > >> > >> > >> > >> > >> > >> > >> > >> Frank Kieviet wrote: > >>> Hi sysprv, > >>> > >>> Not sure what is going wrong here. You configuration appears ok, > >> although I > >>> don't think you can have seen success with a non-XA factory if you use > >>> NoXA=false. Can you send a larger snippet of the server log? > >>> > >>> Frank > >>> > >>> > >>>> -----Original Message----- > >>>> From: [hidden email] > >>>> [mailto:users-return-12104-frank.kieviet=sun.com@open- > esb.dev.java.net] > >> On > >>>> Behalf Of ioj > >>>> Sent: Friday, November 06, 2009 07:54 > >>>> To: [hidden email] > >>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>> > >>>> > >>>> Hi! > >>>> > >>>> I've done a little more testing with JMSJCA jndi://, MQ 7 and a > simple > >>>> JCD. > >>>> > >>>> The JCD is strictly a consumer, and the CAPS classic documentation > >> tells > >>>> us that means it works under a XA transaction. > >>>> > >>>> This is my JMSJCA configuration (env object): > >>>> > >>>> Connection URL: jndi:// > >>>> Options: > >>>> > >>>> JMSJCA.NoXA=false > >>>> JMSJCA.overrideissamerm=true > >>>> JMSJCA.QueueCF=centos_QM1_xaqcf > >>>> > java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory > >>>> java.naming.provider.url=file:/var/mqm/jndictx > >>>> > >>>> > >>>> centos_QM1_xaqcf is defined as a MQXAQueueConnectionFactory. > >>>> > >>>> When I enable the application, it doesn't receive any messages from > the > >>>> queue... When I disable the application, I see this in the GlassFish > >> logs: > >>>> JMSCMQ0001: WebSphere MQ call failed with compcode '2' > ('MQCC_FAILED') > >>>> reason '2009' ('MQRC_CONNECTION_BROKEN'). > >>>> > >>>> The MQ queue manager reports unexpected errors (I'll take these up > with > >>>> IBM when I'm more clear on what I'm doing), and dumps First Failure > >>>> Symptom Reports; yet, its "Connection History" has Reason 2072 > >>>> (MQRC_SYNCPOINT_NOT_AVAILABLE) and before that Reason 30737 > >>>> (lpiRC_WAITCANCELLED_ASYNCCONSUME). > >>>> > >>>> > >>>> Am I configuring JMSJCA wrong? > >>>> > >>>> > >>>> Some more test configurations and results: > >>>> > >>>> Non-XA connection factory, JMSJCA.NoXA=false := JCD works as expected > >>>> (emulated-XA?) > >>>> > >>>> XA connection factory, JMSJCA.NoXA=false := JCD works as expected > >>>> > >>>> Non-XA connection factory, JMSJCA.NoXA=true := Obvious, > >>>> MQConnectionFactory can't be cast to XAConnectionFactory > >>>> > >>>> Non-XA connection factory, JMSJCA.NoXA=true := above :) > >>>> > >>>> > >>>> Thanks in advance, > >>>> > >>>> /sysprv > >>>> > >>>> > >>>> > >>>> > >>>> Frank Kieviet wrote: > >>>>> Hi sysprv, > >>>>> > >>>>>> The multi-instance queue manager feature (new in v7.0.1) is > important > >>>> to > >>>>>> us; at first glance that means using > >>>>>> MQConnectionFactory.setClientReconnectHosts(); > >>>>>> Can JMSJCA set properties it does not know about? I'll investigate > >> this > >>>>>> more tomorrow. > >>>>> Recently we added a new feature to the WMQ support in JMSJCA that > will > >>>> allow > >>>>> you to set arbitrary properties on the factory. See > >>>>> http://wiki.open-esb.java.net/Wiki.jsp?page=JMSJCAReadme#section- > >>>> JMSJCAReadm > >>>>> e-SupportForWebSphereMQMQSeries, where you'll find this: > >>>>> > >>>>> <Quote> > >>>>> The com.ibm.mq.jms.MQConnectionFactory has a large list of > properties > >> of > >>>>> type boolean, int, long, String, URL which can be set. The setter > can > >> be > >>>>> invoked by specifying a connection URL option named using the > >> following > >>>>> convention: remove the 'set' prefix from the name of the setter > method > >>>> and > >>>>> prepend 'WMQ_', e.g. > >>>>> > >>>>> * setMessageRetention(int): WMQ_MessageRetention=1 > >>>>> * setSecurityExit(String): > >> WMQ_SecurityExit=wmq.exits.MySecurityExit > >>>>> * setSparseSubscriptions(boolean): WMQ_SparseSubscriptions=true > >>>>> </Quote> > >>>>> > >>>>>> Now I'm interested in these "naked" factories just for the sake of > >>>>>> knowing :) > >>>>> You could write a small Java program that instantiates the > factories, > >>>> and > >>>>> then bind these factories into JNDI. The JNDI provider could a file > >>>> provider > >>>>> so that you'll end up with a file that has a serialized connection > >>>> factory > >>>>> in there. You can then tell JMSJCA to use this JNDI file provider to > >>>> read > >>>>> the file, deserialize the factory, and as such obtain an instance of > >> the > >>>>> factory. This small Java program that would initially instantiate > the > >>>>> factories would simply call new com.ibm.mq.jms.MQConnectionFactory() > >> and > >>>> set > >>>>> some properties on this factory. > >>>>> > >>>>> BTW, if you're going down this road, also set > >>>> JMSJCA.overrideissamerm=true > >>>>> to workaround an issue in GlassFish/WMQ where GlassFish tries to > join > >> an > >>>> XA > >>>>> resource onto a suspended XA resource. > >>>>> > >>>>> Frank > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: users-return-11999-frank.kieviet=sun.com@open- > esb.dev.java.net > >>>>>> [mailto:users-return-11999-frank.kieviet=sun.com@open- > >> esb.dev.java.net] > >>>> On > >>>>>> Behalf Of ioj > >>>>>> Sent: Monday, November 02, 2009 11:20 > >>>>>> To: [hidden email] > >>>>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>>>> > >>>>>> > >>>>>> Hi Frank, > >>>>>> > >>>>>> Yes, as expected, with wmq:// the JCD can connect to the queue > >> manager > >>>>>> without any problems. > >>>>>> > >>>>>> > >>>>>> The multi-instance queue manager feature (new in v7.0.1) is > important > >>>> to > >>>>>> us; at first glance that means using > >>>>>> MQConnectionFactory.setClientReconnectHosts(); > >>>>>> Can JMSJCA set properties it does not know about? I'll investigate > >> this > >>>>>> more tomorrow. > >>>>>> > >>>>>> > >>>>>> Apart from that, I expected better performance; just an uneducated > >>>> guess. > >>>>>> Now I'm interested in these "naked" factories just for the sake of > >>>>>> knowing :) > >>>>>> > >>>>>> > >>>>>> /sysprv > >>>>>> > >>>>>> > >>>>>> Frank Kieviet wrote: > >>>>>>> Hi sysprv, > >>>>>>> > >>>>>>> I would hope that IBM would provide complete backwards > >> compatibility, > >>>> so > >>>>>> you > >>>>>>> could copy the WMQ jars (com.ibm.mqjms.jar, com.ibm.mq.jar, > >>>>>>> com.ibm.mqetclient.jar and dhbcore.jar if I remember correctly) > into > >>>> the > >>>>>> lib > >>>>>>> directory, and try to use a wmq://xxxx connection URL. If that > >> works, > >>>> at > >>>>>>> least we know how to programmatically create the "naked" > factories. > >>>> Next > >>>>>> we > >>>>>>> can figure out how to bind them into JNDI. Before we go there, > would > >>>>>> using > >>>>>>> the wmq:// URL work for you? Or is it something particular you > hope > >> to > >>>>>> get > >>>>>>> out of the JNDI? If so, could you elaborate on that a little bit? > >>>>>>> > >>>>>>> Frank > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: ioj [mailto:[hidden email]] > >>>>>>>> Sent: Monday, November 02, 2009 10:31 > >>>>>>>> To: [hidden email] > >>>>>>>> Cc: [hidden email]; [hidden email] > >>>>>>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>>>>>> > >>>>>>>> Hi! > >>>>>>>> > >>>>>>>> Yes, that's exactly what I tried to do; our developers are chummy > >>>> with > >>>>>>>> STCMS and GF MQ; but for some applications we in ops would rather > >> use > >>>>>>>> WMQ. Hence this. And we need WMQ >= 7.0.1 (multi-instance queue > >>>>>> managers). > >>>>>>>> Our company's merely an IBM customer; the other way I know of to > >> get > >>>>>> WMQ > >>>>>>>> is the 90 day trial :) > >>>>>>>> I'll check with IBM on this; perhaps Sun already has some > >> partnership > >>>>>> or > >>>>>>>> agreement with IBM? > >>>>>>>> > >>>>>>>> > >>>>>>>> Yep, I'm in contact with Jason, and bug him from time to time. > >>>>>>>> > >>>>>>>> > >>>>>>>> I have access to test systems with WMQ and GF (CAPS only, not > >>>> OpenESB) > >>>>>>>> running on RHEL and AIX. And time too. > >>>>>>>> > >>>>>>>> > >>>>>>>> No problem with moving to OpenESB-users; I just considered this > to > >> be > >>>>>>>> very JMSJCA-specific. > >>>>>>>> > >>>>>>>> > >>>>>>>> Apart from explicit WMQ7 support (which would be very nice, as > WMQ > >>>> has > >>>>>>>> become much more JMS-like since v6), how would one go about > setting > >>>> up > >>>>>>>> naked factories? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> /sysprv > >>>>>>>> > >>>>>>>> > >>>>>>>> Frank Kieviet wrote: > >>>>>>>>> Hi sysprv, > >>>>>>>>> > >>>>>>>>> From what you're describing it looks like you're deploying the > IBM > >>>> RAR > >>>>>>>> into > >>>>>>>>> GlassFish, then bind its connection factories into JNDI, and > then > >>>> use > >>>>>>>> JMSJCA > >>>>>>>>> to look them up. > >>>>>>>>> > >>>>>>>>> If that's the case, the issue with that is that the RAR has a > lot > >> of > >>>>>>>>> functionality to start/stop transactions, participate in > >> connection > >>>>>>>> pooling > >>>>>>>>> etc. To the application, the RAR exposes only application > >> connection > >>>>>>>>> factories. In practical terms, these are non-XA connection > >>>> factories. > >>>>>> In > >>>>>>>>> other words, the factories that the RAR exposes to the > application > >>>> are > >>>>>>>>> wrappers around the "naked" connection factories, and these > >> wrappers > >>>>>> add > >>>>>>>> a > >>>>>>>>> lot of functionality. > >>>>>>>>> > >>>>>>>>> What JMSJCA needs are the "naked" connection factories. What I > >> mean > >>>>>> with > >>>>>>>>> that are the factories that provide a direct line of > communication > >>>>>>>> between > >>>>>>>>> the calling code and the JMS server, of course all using the JMS > >>>> api. > >>>>>>>>> So, to make it work with JNDI, you would have to instantiate the > >> WMQ > >>>>>>>> "naked" > >>>>>>>>> factories, bind them into JNDI (e.g. a file provider if WMQ 7 > did > >>>> not > >>>>>>>> any > >>>>>>>>> new facilities such as a built-in JNDI server), and use those in > >>>>>> JMSJCA. > >>>>>>>>> We're looking into adding explicit support for WMQ7. First issue > >> we > >>>>>> ran > >>>>>>>> into > >>>>>>>>> is how to get a copy of WMQ7. Do you know by any chance? > >>>>>>>>> > >>>>>>>>> BTW, are you in contact with Jason Baragry? > >>>>>>>>> > >>>>>>>>> One more thing: would you mind if we move this discussion to the > >>>>>> OpenESB > >>>>>>>>> users list? > >>>>>>>>> > >>>>>>>>> Frank > >>>>>>>>> > >>>>>>>>> Frank Kieviet > >>>>>>>>> Senior Staff Engineer, SOA/BI > >>>>>>>>> Sun Microsystems, Monrovia, CA > >>>>>>>>> Tel +1 626 471 6322 > >>>>>>>>> Blog: http://frankkieviet.blogspot.com/ > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: ioj [mailto:[hidden email]] > >>>>>>>>>> Sent: Monday, November 02, 2009 08:44 > >>>>>>>>>> To: [hidden email] > >>>>>>>>>> Subject: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>>>>>>>> > >>>>>>>>>> Hi Frank :) > >>>>>>>>>> > >>>>>>>>>> Configured a JMSJCA-driven JCD in jndi:// mode to connect to a > >>>>>>>> WebSphere > >>>>>>>>>> MQ 7 queue; Getting this error: > >>>>>>>>>> > >>>>>>>>>> [#|2009-11-02T17:09:55.496+0100|INFO|sun- > >>>>>>>>>> > >> > appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=18;_Threa > >>>>>>>>>> dName=httpWorkerThread-4848-4;dpJMSJCATest_1_0_0;|LDR5010: > >>>>>>>>>> All ejb(s) of [dpJMSJCATest_1_0_0] loaded successfully!|#] > >>>>>>>>>> > >>>>>>>>>> [#|2009-11-02T17:09:55.498+0100|WARNING|sun- > >>>>>>>>>> > >> > appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=25;_ThreadName=JMSJC > >>>>>>>>>> A > >>>>>>>>>> connect;Context=TestProjects | > >>>>>>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=07fb37e9- > >> 63b3- > >>>>>>>> 4015- > >>>>>>>>>> a035-dcc50c47ac93;|JMSJCA-E016: > >>>>>>>>>> [serial-QueueReceiver(QJMSJCATEST){TestProjects | > >>>>>>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: > message > >>>>>>>>>> delivery initiation failed (attempt #1); will retry in 1 > seconds. > >>>> The > >>>>>>>>>> error was: > >> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl > >>>>>>>>>> cannot be cast to javax.jms.XAQueueConnectionFactory > >>>>>>>>>> java.lang.ClassCastException: > >>>>>>>>>> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl cannot > >> be > >>>>>> cast > >>>>>>>>>> to javax.jms.XAQueueConnectionFactory > >>>>>>>>>> at > >>>>>>>>>> > >> > com.stc.jmsjca.jndi.RAJNDIObjectFactory.createConnectionFactory(RAJNDIObje > >>>>>>>>>> ctFactory.java:208) > >>>>>>>>>> at > >>>> com.stc.jmsjca.core.SerialDelivery.start(SerialDelivery.java:74) > >>>>>>>>>> at > >>>> com.stc.jmsjca.core.Activation.asyncStart(Activation.java:552) > >>>>>>>>>> at > >>>> com.stc.jmsjca.core.Activation.access$000(Activation.java:81) > >>>>>>>>>> at com.stc.jmsjca.core.Activation$1.run(Activation.java:347) > >>>>>>>>>> at java.lang.Thread.run(Thread.java:619) > >>>>>>>>>> |#] > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Details: > >>>>>>>>>> > >>>>>>>>>> I've installed and configured the WMQ 7 RA from IBM in > GlassFish > >>>>>>>>>> Enterprise v2.1 Patch 02. The IVT (installation verification > >> test) > >>>>>> app > >>>>>>>>>> from IBM runs fine and passes all tests. > >>>>>>>>>> > >>>>>>>>>> Next, I have the simplest message driven JCD you can think of: > it > >>>>>> reads > >>>>>>>>>> a TextMessage using JMSJCA and writes the Text to the > server.log. > >>>>>> Works > >>>>>>>>>> fine with GlassFish MQ. > >>>>>>>>>> > >>>>>>>>>> Then I have a connector connection pool of type > >>>>>> QueueConnectionFactory, > >>>>>>>>>> using the IBM RA, configured for XA (Transaction Support: > >>>>>>>> XATransaction) > >>>>>>>>>> When I configure JMSJCA (inside GF, with the Env overrides in > >> CAPS > >>>>>> 6.x) > >>>>>>>>>> with: > >>>>>>>>>> > >>>>>>>>>> Connection URL: jndi:// > >>>>>>>>>> JMSJCA.NoXA=false > >>>>>>>>>> JMSJCA.QueueCF=jms/wmq/xa/qcf > >>>>>>>>>> > >>>>>>>>>> and enable the JCD, I get the message above. > >>>>>>>>>> > >>>>>>>>>> I've made sure that the MQ transaction support jar is available > >> to > >>>>>> the > >>>>>>>>>> appserver etc. etc. (the IVT passes all tests incl. > transactions > >> - > >>>>>>>>>> though it's much simpler than a JCD with JMSJCA +) > >>>>>>>>>> > >>>>>>>>>> What's going wrong here, and how can it be fixed? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Thanks in advance! > >>>>>>>>>> /sysprv > >>>>>>>>>> > >>>>>>>>>> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [hidden email] > > For additional commands, e-mail: [hidden email] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
|
sysprv
|
Thanks, will do. When not using sync mode with XA, the MQ queue manager logged some quite alarming error messages: internal errors, timeout waiting for semaphores, etc. Do you think it's worth raising a PMR with IBM? Also for issamerm=true. Frank Kieviet wrote: > Great! I'm glad it works now! Do let us know if you find on further testing > that it doesn't fully meet your requirements, e.g. with respect to > usability. > > Frank > > >> -----Original Message----- >> From: [hidden email] >> [mailto:[hidden email]] On >> Behalf Of ioj >> Sent: Friday, November 06, 2009 16:51 >> To: [hidden email] >> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >> >> >> That seems to have done the job :) >> >> After a restart of GF and the MQ queue manager, everything seems to work >> as it should. >> >> Thanks for your help! >> >> >> >> >> Frank Kieviet wrote: >>> Hi sysprv, >>> >>> Could you add the following option as well? >>> JMSJCA.concurrencymode=sync >>> >>> This will change the delivery from serial to sync which is the only mode >>> that works with WMQ and XA. >>> >>> HTH, >>> Frank >>> >>> >>>> -----Original Message----- >>>> From: [hidden email] >>>> [mailto:[hidden email]] >> On >>>> Behalf Of ioj >>>> Sent: Friday, November 06, 2009 16:01 >>>> To: [hidden email] >>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>> >>>> Hi Frank, >>>> >>>> My bad, it should be: >>>> >>>> >> Non-XA connection factory, JMSJCA.NoXA=true := JCD works as >> expected >>>> >> (emulated-XA?) >>>> >>>> >>>> >>>> A longer snippet from the log is attached (in case of hard wrapping), >>>> and inline: >>>> >>>> [#|2009-11-07T00:54:00.106+0100|INFO|sun- >>>> >> appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=39;_ThreadName=JMSJC >>>> A >>>> connect;Context=TestProjects | >>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;|JMSJCA-E015: >>>> [serial-QueueReceiver(QJMSJCATEST){TestProjects | >>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message >>>> delivery initiation was successful.|#] >>>> >>>> >>>> There are already some messages on the queue; I expect to see their >>>> contents in server.log, but it seems they're never delivered to the >> JCD. >>>> Then I disable the JCD: >>>> >>>> [#|2009-11-07T00:54:40.928+0100|WARNING|sun- >>>> >> appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p >>>> : >>>> thread-pool-1; w: 41;Context=TestProjects | >>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14- >> 4680- >>>> 82dc-5aae8f323bba;|JMSJCA-E054: >>>> Unexpected exception stopping JMS connection: JMSCMQ0002: The method >>>> 'MQCTL' failed.. >>>> com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ0002: The method >>>> 'MQCTL' failed. A WebSphere MQ call failed. Please see the linked >>>> exception for more information. >>>> at >>>> >> com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav >>>> a:608) >>>> at >>>> >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >>>> 236) >>>> at >>>> >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >>>> 275) >>>> at >>>> >> com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService >>>> (WMQConsumerOwnerShadow.java:308) >>>> at >>>> >> com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.stop(WMQConsumerOwn >>>> erShadow.java:654) >>>> at >>>> com.ibm.msg.client.wmq.internal.WMQSession.stop(WMQSession.java:1466) >>>> at >>>> >> com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:20 >>>> 28) >>>> at >>>> >> com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:19 >>>> 36) >>>> at >>>> >> com.ibm.msg.client.jms.internal.JmsConnectionImpl.stop(JmsConnectionImpl.j >>>> ava:792) >>>> at com.ibm.mq.jms.MQConnection.stop(MQConnection.java:471) >>>> at >>>> com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:153) >>>> at >>>> com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) >>>> at >> com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) >>>> at >>>> >> com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc >>>> eAdapter.java:717) >>>> at >>>> >> com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn >>>> ectorMessageBeanClient.java:313) >>>> at >>>> >> com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me >>>> ssageBeanContainer.java:920) >>>> at >>>> >> com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic >>>> e(MessageBeanContainer.java:912) >>>> at >>>> com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) >>>> at >>>> >> com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T >>>> hreadPoolImpl.java:555) >>>> Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed >>>> with compcode '2' ('MQCC_FAILED') reason '2009' >>>> ('MQRC_CONNECTION_BROKEN'). >>>> at >>>> >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >>>> 223) >>>> ... 17 more >>>> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteHconn.exchangeTSH(RemoteHconn.java:1 >>>> 472) >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.sendNotification(Remote >>>> AsyncConsume.java:409) >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.sendConnState(RemoteAsy >>>> ncConsume.java:522) >>>> at >>>> com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQCTL(RemoteFAP.java:2066) >>>> at >>>> >> com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService >>>> (WMQConsumerOwnerShadow.java:296) >>>> ... 15 more >>>> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error >> on >>>> receive from host 'centos/10.0.0.1:1414 (centos)'. >>>> [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr >>>> ead.java:698) >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr >>>> ead.java:638) >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 >>>> 36) >>>> at >>>> >> com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu >>>> eItem.java:209) >>>> at >>>> >> com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si >>>> mpleWorkQueueItem.java:100) >>>> at >>>> >> com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte >>>> m.java:224) >>>> at >>>> >> com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI >>>> tem(WorkQueueManager.java:298) >>>> at >>>> >> com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement >>>> ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) >>>> |#] >>>> >>>> [#|2009-11-07T00:54:40.933+0100|WARNING|sun- >>>> >> appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p >>>> : >>>> thread-pool-1; w: 41;Context=TestProjects | >>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14- >> 4680- >>>> 82dc-5aae8f323bba;|JMSJCA-E087: >>>> Error while closing session: JMSCMQ0002: The method 'MQCTL' failed. >>>> com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ0002: The method >>>> 'MQCTL' failed. A WebSphere MQ call failed. Please see the linked >>>> exception for more information. >>>> at >>>> >> com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav >>>> a:608) >>>> at >>>> >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >>>> 236) >>>> at >>>> >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >>>> 275) >>>> at >>>> >> com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService >>>> (WMQConsumerOwnerShadow.java:308) >>>> at >>>> >> com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.stop(WMQConsumerOwn >>>> erShadow.java:654) >>>> at >>>> com.ibm.msg.client.wmq.internal.WMQSession.stop(WMQSession.java:1466) >>>> at >>>> >> com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:20 >>>> 28) >>>> at >>>> >> com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:2 >>>> 89) >>>> at >>>> >> com.ibm.msg.client.jms.internal.JmsXASessionImpl.close(JmsXASessionImpl.ja >>>> va:234) >>>> at >>>> >> com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:2 >>>> 35) >>>> at >>>> >> com.ibm.msg.client.jms.internal.JmsXASessionImpl.close(JmsXASessionImpl.ja >>>> va:199) >>>> at com.ibm.mq.jms.MQSession.close(MQSession.java:195) >>>> at >>>> com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:167) >>>> at >>>> com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) >>>> at >> com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) >>>> at >>>> >> com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc >>>> eAdapter.java:717) >>>> at >>>> >> com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn >>>> ectorMessageBeanClient.java:313) >>>> at >>>> >> com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me >>>> ssageBeanContainer.java:920) >>>> at >>>> >> com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic >>>> e(MessageBeanContainer.java:912) >>>> at >>>> com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) >>>> at >>>> >> com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T >>>> hreadPoolImpl.java:555) >>>> Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed >>>> with compcode '2' ('MQCC_FAILED') reason '2009' >>>> ('MQRC_CONNECTION_BROKEN'). >>>> at >>>> >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >>>> 223) >>>> ... 19 more >>>> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:381 >>>> ) >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:304 >>>> ) >>>> at >>>> com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQCTL(RemoteFAP.java:1923) >>>> at >>>> >> com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService >>>> (WMQConsumerOwnerShadow.java:296) >>>> ... 17 more >>>> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error >> on >>>> receive from host 'centos/10.0.0.1:1414 (centos)'. >>>> [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr >>>> ead.java:698) >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr >>>> ead.java:638) >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 >>>> 36) >>>> at >>>> >> com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu >>>> eItem.java:209) >>>> at >>>> >> com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si >>>> mpleWorkQueueItem.java:100) >>>> at >>>> >> com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte >>>> m.java:224) >>>> at >>>> >> com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI >>>> tem(WorkQueueManager.java:298) >>>> at >>>> >> com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement >>>> ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) >>>> |#] >>>> >>>> [#|2009-11-07T00:54:40.935+0100|WARNING|sun- >>>> >> appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p >>>> : >>>> thread-pool-1; w: 41;Context=TestProjects | >>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14- >> 4680- >>>> 82dc-5aae8f323bba;|JMSJCA-E055: >>>> Unexpected exception closing JMS connection: JMSWMQ0019: Failed to >>>> disconnect from queue manager '' using connection mode '1' and host >> name >>>> 'centos'. >>>> com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ0019: Failed to >>>> disconnect from queue manager '' using connection mode '1' and host >> name >>>> 'centos'. Please see the linked exception for more information. >>>> at >>>> >> com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav >>>> a:608) >>>> at >>>> >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >>>> 236) >>>> at >>>> >> com.ibm.msg.client.wmq.internal.WMQConnection.close(WMQConnection.java:677 >>>> ) >>>> at >>>> >> com.ibm.msg.client.jms.internal.JmsConnectionImpl.close(JmsConnectionImpl. >>>> java:328) >>>> at com.ibm.mq.jms.MQConnection.close(MQConnection.java:93) >>>> at >>>> com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:175) >>>> at >>>> com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) >>>> at >> com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) >>>> at >>>> >> com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc >>>> eAdapter.java:717) >>>> at >>>> >> com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn >>>> ectorMessageBeanClient.java:313) >>>> at >>>> >> com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me >>>> ssageBeanContainer.java:920) >>>> at >>>> >> com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic >>>> e(MessageBeanContainer.java:912) >>>> at >>>> com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) >>>> at >>>> >> com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T >>>> hreadPoolImpl.java:555) >>>> Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed >>>> with compcode '2' ('MQCC_FAILED') reason '2009' >>>> ('MQRC_CONNECTION_BROKEN'). >>>> at >>>> >> com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: >>>> 223) >>>> ... 12 more >>>> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:381 >>>> ) >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:304 >>>> ) >>>> at >>>> com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQDISC(RemoteFAP.java:2347) >>>> at >>>> >> com.ibm.msg.client.wmq.internal.WMQConnection.close(WMQConnection.java:659 >>>> ) >>>> ... 11 more >>>> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error >> on >>>> receive from host 'centos/10.0.0.1:1414 (centos)'. >>>> [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr >>>> ead.java:698) >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr >>>> ead.java:638) >>>> at >>>> >> com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 >>>> 36) >>>> at >>>> >> com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu >>>> eItem.java:209) >>>> at >>>> >> com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si >>>> mpleWorkQueueItem.java:100) >>>> at >>>> >> com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte >>>> m.java:224) >>>> at >>>> >> com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI >>>> tem(WorkQueueManager.java:298) >>>> at >>>> >> com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement >>>> ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) >>>> |#] >>>> >>>> [#|2009-11-07T00:54:41.025+0100|INFO|sun- >>>> >> appserver2.1|javax.enterprise.system.core|_ThreadID=17;_ThreadName=httpWor >>>> kerThread-4848-1;dpJMSJCATest_1_0_0;|CORE5022: >>>> All ejb(s) of [dpJMSJCATest_1_0_0] were unloaded successfully!|#] >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Frank Kieviet wrote: >>>>> Hi sysprv, >>>>> >>>>> Not sure what is going wrong here. You configuration appears ok, >>>> although I >>>>> don't think you can have seen success with a non-XA factory if you use >>>>> NoXA=false. Can you send a larger snippet of the server log? >>>>> >>>>> Frank >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: [hidden email] >>>>>> [mailto:users-return-12104-frank.kieviet=sun.com@open- >> esb.dev.java.net] >>>> On >>>>>> Behalf Of ioj >>>>>> Sent: Friday, November 06, 2009 07:54 >>>>>> To: [hidden email] >>>>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>>>> >>>>>> >>>>>> Hi! >>>>>> >>>>>> I've done a little more testing with JMSJCA jndi://, MQ 7 and a >> simple >>>>>> JCD. >>>>>> >>>>>> The JCD is strictly a consumer, and the CAPS classic documentation >>>> tells >>>>>> us that means it works under a XA transaction. >>>>>> >>>>>> This is my JMSJCA configuration (env object): >>>>>> >>>>>> Connection URL: jndi:// >>>>>> Options: >>>>>> >>>>>> JMSJCA.NoXA=false >>>>>> JMSJCA.overrideissamerm=true >>>>>> JMSJCA.QueueCF=centos_QM1_xaqcf >>>>>> >> java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory >>>>>> java.naming.provider.url=file:/var/mqm/jndictx >>>>>> >>>>>> >>>>>> centos_QM1_xaqcf is defined as a MQXAQueueConnectionFactory. >>>>>> >>>>>> When I enable the application, it doesn't receive any messages from >> the >>>>>> queue... When I disable the application, I see this in the GlassFish >>>> logs: >>>>>> JMSCMQ0001: WebSphere MQ call failed with compcode '2' >> ('MQCC_FAILED') >>>>>> reason '2009' ('MQRC_CONNECTION_BROKEN'). >>>>>> >>>>>> The MQ queue manager reports unexpected errors (I'll take these up >> with >>>>>> IBM when I'm more clear on what I'm doing), and dumps First Failure >>>>>> Symptom Reports; yet, its "Connection History" has Reason 2072 >>>>>> (MQRC_SYNCPOINT_NOT_AVAILABLE) and before that Reason 30737 >>>>>> (lpiRC_WAITCANCELLED_ASYNCCONSUME). >>>>>> >>>>>> >>>>>> Am I configuring JMSJCA wrong? >>>>>> >>>>>> >>>>>> Some more test configurations and results: >>>>>> >>>>>> Non-XA connection factory, JMSJCA.NoXA=false := JCD works as expected >>>>>> (emulated-XA?) >>>>>> >>>>>> XA connection factory, JMSJCA.NoXA=false := JCD works as expected >>>>>> >>>>>> Non-XA connection factory, JMSJCA.NoXA=true := Obvious, >>>>>> MQConnectionFactory can't be cast to XAConnectionFactory >>>>>> >>>>>> Non-XA connection factory, JMSJCA.NoXA=true := above :) >>>>>> >>>>>> >>>>>> Thanks in advance, >>>>>> >>>>>> /sysprv >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Frank Kieviet wrote: >>>>>>> Hi sysprv, >>>>>>> >>>>>>>> The multi-instance queue manager feature (new in v7.0.1) is >> important >>>>>> to >>>>>>>> us; at first glance that means using >>>>>>>> MQConnectionFactory.setClientReconnectHosts(); >>>>>>>> Can JMSJCA set properties it does not know about? I'll investigate >>>> this >>>>>>>> more tomorrow. >>>>>>> Recently we added a new feature to the WMQ support in JMSJCA that >> will >>>>>> allow >>>>>>> you to set arbitrary properties on the factory. See >>>>>>> http://wiki.open-esb.java.net/Wiki.jsp?page=JMSJCAReadme#section- >>>>>> JMSJCAReadm >>>>>>> e-SupportForWebSphereMQMQSeries, where you'll find this: >>>>>>> >>>>>>> <Quote> >>>>>>> The com.ibm.mq.jms.MQConnectionFactory has a large list of >> properties >>>> of >>>>>>> type boolean, int, long, String, URL which can be set. The setter >> can >>>> be >>>>>>> invoked by specifying a connection URL option named using the >>>> following >>>>>>> convention: remove the 'set' prefix from the name of the setter >> method >>>>>> and >>>>>>> prepend 'WMQ_', e.g. >>>>>>> >>>>>>> * setMessageRetention(int): WMQ_MessageRetention=1 >>>>>>> * setSecurityExit(String): >>>> WMQ_SecurityExit=wmq.exits.MySecurityExit >>>>>>> * setSparseSubscriptions(boolean): WMQ_SparseSubscriptions=true >>>>>>> </Quote> >>>>>>> >>>>>>>> Now I'm interested in these "naked" factories just for the sake of >>>>>>>> knowing :) >>>>>>> You could write a small Java program that instantiates the >> factories, >>>>>> and >>>>>>> then bind these factories into JNDI. The JNDI provider could a file >>>>>> provider >>>>>>> so that you'll end up with a file that has a serialized connection >>>>>> factory >>>>>>> in there. You can then tell JMSJCA to use this JNDI file provider to >>>>>> read >>>>>>> the file, deserialize the factory, and as such obtain an instance of >>>> the >>>>>>> factory. This small Java program that would initially instantiate >> the >>>>>>> factories would simply call new com.ibm.mq.jms.MQConnectionFactory() >>>> and >>>>>> set >>>>>>> some properties on this factory. >>>>>>> >>>>>>> BTW, if you're going down this road, also set >>>>>> JMSJCA.overrideissamerm=true >>>>>>> to workaround an issue in GlassFish/WMQ where GlassFish tries to >> join >>>> an >>>>>> XA >>>>>>> resource onto a suspended XA resource. >>>>>>> >>>>>>> Frank >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: users-return-11999-frank.kieviet=sun.com@open- >> esb.dev.java.net >>>>>>>> [mailto:users-return-11999-frank.kieviet=sun.com@open- >>>> esb.dev.java.net] >>>>>> On >>>>>>>> Behalf Of ioj >>>>>>>> Sent: Monday, November 02, 2009 11:20 >>>>>>>> To: [hidden email] >>>>>>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>>>>>> >>>>>>>> >>>>>>>> Hi Frank, >>>>>>>> >>>>>>>> Yes, as expected, with wmq:// the JCD can connect to the queue >>>> manager >>>>>>>> without any problems. >>>>>>>> >>>>>>>> >>>>>>>> The multi-instance queue manager feature (new in v7.0.1) is >> important >>>>>> to >>>>>>>> us; at first glance that means using >>>>>>>> MQConnectionFactory.setClientReconnectHosts(); >>>>>>>> Can JMSJCA set properties it does not know about? I'll investigate >>>> this >>>>>>>> more tomorrow. >>>>>>>> >>>>>>>> >>>>>>>> Apart from that, I expected better performance; just an uneducated >>>>>> guess. >>>>>>>> Now I'm interested in these "naked" factories just for the sake of >>>>>>>> knowing :) >>>>>>>> >>>>>>>> >>>>>>>> /sysprv >>>>>>>> >>>>>>>> >>>>>>>> Frank Kieviet wrote: >>>>>>>>> Hi sysprv, >>>>>>>>> >>>>>>>>> I would hope that IBM would provide complete backwards >>>> compatibility, >>>>>> so >>>>>>>> you >>>>>>>>> could copy the WMQ jars (com.ibm.mqjms.jar, com.ibm.mq.jar, >>>>>>>>> com.ibm.mqetclient.jar and dhbcore.jar if I remember correctly) >> into >>>>>> the >>>>>>>> lib >>>>>>>>> directory, and try to use a wmq://xxxx connection URL. If that >>>> works, >>>>>> at >>>>>>>>> least we know how to programmatically create the "naked" >> factories. >>>>>> Next >>>>>>>> we >>>>>>>>> can figure out how to bind them into JNDI. Before we go there, >> would >>>>>>>> using >>>>>>>>> the wmq:// URL work for you? Or is it something particular you >> hope >>>> to >>>>>>>> get >>>>>>>>> out of the JNDI? If so, could you elaborate on that a little bit? >>>>>>>>> >>>>>>>>> Frank >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: ioj [mailto:[hidden email]] >>>>>>>>>> Sent: Monday, November 02, 2009 10:31 >>>>>>>>>> To: [hidden email] >>>>>>>>>> Cc: [hidden email]; [hidden email] >>>>>>>>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>>>>>>>> >>>>>>>>>> Hi! >>>>>>>>>> >>>>>>>>>> Yes, that's exactly what I tried to do; our developers are chummy >>>>>> with >>>>>>>>>> STCMS and GF MQ; but for some applications we in ops would rather >>>> use >>>>>>>>>> WMQ. Hence this. And we need WMQ >= 7.0.1 (multi-instance queue >>>>>>>> managers). >>>>>>>>>> Our company's merely an IBM customer; the other way I know of to >>>> get >>>>>>>> WMQ >>>>>>>>>> is the 90 day trial :) >>>>>>>>>> I'll check with IBM on this; perhaps Sun already has some >>>> partnership >>>>>>>> or >>>>>>>>>> agreement with IBM? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yep, I'm in contact with Jason, and bug him from time to time. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I have access to test systems with WMQ and GF (CAPS only, not >>>>>> OpenESB) >>>>>>>>>> running on RHEL and AIX. And time too. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No problem with moving to OpenESB-users; I just considered this >> to >>>> be >>>>>>>>>> very JMSJCA-specific. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Apart from explicit WMQ7 support (which would be very nice, as >> WMQ >>>>>> has >>>>>>>>>> become much more JMS-like since v6), how would one go about >> setting >>>>>> up >>>>>>>>>> naked factories? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> /sysprv >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Frank Kieviet wrote: >>>>>>>>>>> Hi sysprv, >>>>>>>>>>> >>>>>>>>>>> From what you're describing it looks like you're deploying the >> IBM >>>>>> RAR >>>>>>>>>> into >>>>>>>>>>> GlassFish, then bind its connection factories into JNDI, and >> then >>>>>> use >>>>>>>>>> JMSJCA >>>>>>>>>>> to look them up. >>>>>>>>>>> >>>>>>>>>>> If that's the case, the issue with that is that the RAR has a >> lot >>>> of >>>>>>>>>>> functionality to start/stop transactions, participate in >>>> connection >>>>>>>>>> pooling >>>>>>>>>>> etc. To the application, the RAR exposes only application >>>> connection >>>>>>>>>>> factories. In practical terms, these are non-XA connection >>>>>> factories. >>>>>>>> In >>>>>>>>>>> other words, the factories that the RAR exposes to the >> application >>>>>> are >>>>>>>>>>> wrappers around the "naked" connection factories, and these >>>> wrappers >>>>>>>> add >>>>>>>>>> a >>>>>>>>>>> lot of functionality. >>>>>>>>>>> >>>>>>>>>>> What JMSJCA needs are the "naked" connection factories. What I >>>> mean >>>>>>>> with >>>>>>>>>>> that are the factories that provide a direct line of >> communication >>>>>>>>>> between >>>>>>>>>>> the calling code and the JMS server, of course all using the JMS >>>>>> api. >>>>>>>>>>> So, to make it work with JNDI, you would have to instantiate the >>>> WMQ >>>>>>>>>> "naked" >>>>>>>>>>> factories, bind them into JNDI (e.g. a file provider if WMQ 7 >> did >>>>>> not >>>>>>>>>> any >>>>>>>>>>> new facilities such as a built-in JNDI server), and use those in >>>>>>>> JMSJCA. >>>>>>>>>>> We're looking into adding explicit support for WMQ7. First issue >>>> we >>>>>>>> ran >>>>>>>>>> into >>>>>>>>>>> is how to get a copy of WMQ7. Do you know by any chance? >>>>>>>>>>> >>>>>>>>>>> BTW, are you in contact with Jason Baragry? >>>>>>>>>>> >>>>>>>>>>> One more thing: would you mind if we move this discussion to the >>>>>>>> OpenESB >>>>>>>>>>> users list? >>>>>>>>>>> >>>>>>>>>>> Frank >>>>>>>>>>> >>>>>>>>>>> Frank Kieviet >>>>>>>>>>> Senior Staff Engineer, SOA/BI >>>>>>>>>>> Sun Microsystems, Monrovia, CA >>>>>>>>>>> Tel +1 626 471 6322 >>>>>>>>>>> Blog: http://frankkieviet.blogspot.com/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: ioj [mailto:[hidden email]] >>>>>>>>>>>> Sent: Monday, November 02, 2009 08:44 >>>>>>>>>>>> To: [hidden email] >>>>>>>>>>>> Subject: JMSJCA, CAPS 6.2, WebSphere MQ 7 >>>>>>>>>>>> >>>>>>>>>>>> Hi Frank :) >>>>>>>>>>>> >>>>>>>>>>>> Configured a JMSJCA-driven JCD in jndi:// mode to connect to a >>>>>>>>>> WebSphere >>>>>>>>>>>> MQ 7 queue; Getting this error: >>>>>>>>>>>> >>>>>>>>>>>> [#|2009-11-02T17:09:55.496+0100|INFO|sun- >>>>>>>>>>>> >> appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=18;_Threa >>>>>>>>>>>> dName=httpWorkerThread-4848-4;dpJMSJCATest_1_0_0;|LDR5010: >>>>>>>>>>>> All ejb(s) of [dpJMSJCATest_1_0_0] loaded successfully!|#] >>>>>>>>>>>> >>>>>>>>>>>> [#|2009-11-02T17:09:55.498+0100|WARNING|sun- >>>>>>>>>>>> >> appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=25;_ThreadName=JMSJC >>>>>>>>>>>> A >>>>>>>>>>>> connect;Context=TestProjects | >>>>>>>>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=07fb37e9- >>>> 63b3- >>>>>>>>>> 4015- >>>>>>>>>>>> a035-dcc50c47ac93;|JMSJCA-E016: >>>>>>>>>>>> [serial-QueueReceiver(QJMSJCATEST){TestProjects | >>>>>>>>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: >> message >>>>>>>>>>>> delivery initiation failed (attempt #1); will retry in 1 >> seconds. >>>>>> The >>>>>>>>>>>> error was: >>>> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl >>>>>>>>>>>> cannot be cast to javax.jms.XAQueueConnectionFactory >>>>>>>>>>>> java.lang.ClassCastException: >>>>>>>>>>>> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl cannot >>>> be >>>>>>>> cast >>>>>>>>>>>> to javax.jms.XAQueueConnectionFactory >>>>>>>>>>>> at >>>>>>>>>>>> >> com.stc.jmsjca.jndi.RAJNDIObjectFactory.createConnectionFactory(RAJNDIObje >>>>>>>>>>>> ctFactory.java:208) >>>>>>>>>>>> at >>>>>> com.stc.jmsjca.core.SerialDelivery.start(SerialDelivery.java:74) >>>>>>>>>>>> at >>>>>> com.stc.jmsjca.core.Activation.asyncStart(Activation.java:552) >>>>>>>>>>>> at >>>>>> com.stc.jmsjca.core.Activation.access$000(Activation.java:81) >>>>>>>>>>>> at com.stc.jmsjca.core.Activation$1.run(Activation.java:347) >>>>>>>>>>>> at java.lang.Thread.run(Thread.java:619) >>>>>>>>>>>> |#] >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Details: >>>>>>>>>>>> >>>>>>>>>>>> I've installed and configured the WMQ 7 RA from IBM in >> GlassFish >>>>>>>>>>>> Enterprise v2.1 Patch 02. The IVT (installation verification >>>> test) >>>>>>>> app >>>>>>>>>>>> from IBM runs fine and passes all tests. >>>>>>>>>>>> >>>>>>>>>>>> Next, I have the simplest message driven JCD you can think of: >> it >>>>>>>> reads >>>>>>>>>>>> a TextMessage using JMSJCA and writes the Text to the >> server.log. >>>>>>>> Works >>>>>>>>>>>> fine with GlassFish MQ. >>>>>>>>>>>> >>>>>>>>>>>> Then I have a connector connection pool of type >>>>>>>> QueueConnectionFactory, >>>>>>>>>>>> using the IBM RA, configured for XA (Transaction Support: >>>>>>>>>> XATransaction) >>>>>>>>>>>> When I configure JMSJCA (inside GF, with the Env overrides in >>>> CAPS >>>>>>>> 6.x) >>>>>>>>>>>> with: >>>>>>>>>>>> >>>>>>>>>>>> Connection URL: jndi:// >>>>>>>>>>>> JMSJCA.NoXA=false >>>>>>>>>>>> JMSJCA.QueueCF=jms/wmq/xa/qcf >>>>>>>>>>>> >>>>>>>>>>>> and enable the JCD, I get the message above. >>>>>>>>>>>> >>>>>>>>>>>> I've made sure that the MQ transaction support jar is available >>>> to >>>>>>>> the >>>>>>>>>>>> appserver etc. etc. (the IVT passes all tests incl. >> transactions >>>> - >>>>>>>>>>>> though it's much simpler than a JCD with JMSJCA +) >>>>>>>>>>>> >>>>>>>>>>>> What's going wrong here, and how can it be fixed? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks in advance! >>>>>>>>>>>> /sysprv >>>>>>>>>>>> >>>>>>>>>>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [hidden email] >>> For additional commands, e-mail: [hidden email] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
|
Frank Kieviet
|
Hi sysprv,
The error messages from WMQ are confusing and typically don't convey much about what the problem is. IBM also didn't bother to upgrade their exceptions to the JDK 1.4 style of calling setCause() forcing users of their apis (like me) to litter their code with calls to getLinkedException(). But enough about my gripes with the WMQ api. The issue with serial delivery is that there is actually no standardization of how to use XA with serial delivery. With serial delivery I mean calling setMessageListener() on a consumer and receiving messages that way. The only place where a transaction can be started is *in* the onMessage() method. At this point, the message was already received, so starting a transaction at that point may be too late. Some providers support this anyways, e.g. STCMS. Others don't and throw scary errors. In JMSJCA when you use the wmq:// URL, all configuration options are set such that the user (you) don't have to do anything special. However, when you use JNDI, the RA doesn't know what the provider is, and you have to specify these options manually. If you forget, you'll run into these scary error messages. Perhaps there's a better solution to this: if you use JNDI, JMSJCA could somehow recognize that it is WMQ and choose the appropriate configuration options. Alternatively, we could extends wmq:// with a jdni option. (I left the door open to this when I invited you to raise usability issues) BTW, I don't think it'll help to raise these issues with IBM: I don't think they'll change their client code, and besides, since we have found workarounds for them, these issues are also no longer of any urgency. Best, Frank > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On > Behalf Of ioj > Sent: Saturday, November 07, 2009 00:48 > To: [hidden email] > Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > > > Thanks, will do. > > When not using sync mode with XA, the MQ queue manager logged some quite > alarming error messages: internal errors, timeout waiting for > semaphores, etc. Do you think it's worth raising a PMR with IBM? > > Also for issamerm=true. > > > Frank Kieviet wrote: > > Great! I'm glad it works now! Do let us know if you find on further > testing > > that it doesn't fully meet your requirements, e.g. with respect to > > usability. > > > > Frank > > > > > >> -----Original Message----- > >> From: [hidden email] > >> [mailto:[hidden email]] > On > >> Behalf Of ioj > >> Sent: Friday, November 06, 2009 16:51 > >> To: [hidden email] > >> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >> > >> > >> That seems to have done the job :) > >> > >> After a restart of GF and the MQ queue manager, everything seems to > work > >> as it should. > >> > >> Thanks for your help! > >> > >> > >> > >> > >> Frank Kieviet wrote: > >>> Hi sysprv, > >>> > >>> Could you add the following option as well? > >>> JMSJCA.concurrencymode=sync > >>> > >>> This will change the delivery from serial to sync which is the only > mode > >>> that works with WMQ and XA. > >>> > >>> HTH, > >>> Frank > >>> > >>> > >>>> -----Original Message----- > >>>> From: [hidden email] > >>>> [mailto:users-return-12115-frank.kieviet=sun.com@open- > esb.dev.java.net] > >> On > >>>> Behalf Of ioj > >>>> Sent: Friday, November 06, 2009 16:01 > >>>> To: [hidden email] > >>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>> > >>>> Hi Frank, > >>>> > >>>> My bad, it should be: > >>>> > >>>> >> Non-XA connection factory, JMSJCA.NoXA=true := JCD works as > >> expected > >>>> >> (emulated-XA?) > >>>> > >>>> > >>>> > >>>> A longer snippet from the log is attached (in case of hard wrapping), > >>>> and inline: > >>>> > >>>> [#|2009-11-07T00:54:00.106+0100|INFO|sun- > >>>> > >> > appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=39;_ThreadName=JMSJC > >>>> A > >>>> connect;Context=TestProjects | > >>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;|JMSJCA-E015: > >>>> [serial-QueueReceiver(QJMSJCATEST){TestProjects | > >>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: message > >>>> delivery initiation was successful.|#] > >>>> > >>>> > >>>> There are already some messages on the queue; I expect to see their > >>>> contents in server.log, but it seems they're never delivered to the > >> JCD. > >>>> Then I disable the JCD: > >>>> > >>>> [#|2009-11-07T00:54:40.928+0100|WARNING|sun- > >>>> > >> > appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p > >>>> : > >>>> thread-pool-1; w: 41;Context=TestProjects | > >>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14- > >> 4680- > >>>> 82dc-5aae8f323bba;|JMSJCA-E054: > >>>> Unexpected exception stopping JMS connection: JMSCMQ0002: The method > >>>> 'MQCTL' failed.. > >>>> com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ0002: The method > >>>> 'MQCTL' failed. A WebSphere MQ call failed. Please see the linked > >>>> exception for more information. > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav > >>>> a:608) > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >>>> 236) > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >>>> 275) > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService > >>>> (WMQConsumerOwnerShadow.java:308) > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.stop(WMQConsumerOwn > >>>> erShadow.java:654) > >>>> at > >>>> com.ibm.msg.client.wmq.internal.WMQSession.stop(WMQSession.java:1466) > >>>> at > >>>> > >> > com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:20 > >>>> 28) > >>>> at > >>>> > >> > com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:19 > >>>> 36) > >>>> at > >>>> > >> > com.ibm.msg.client.jms.internal.JmsConnectionImpl.stop(JmsConnectionImpl.j > >>>> ava:792) > >>>> at com.ibm.mq.jms.MQConnection.stop(MQConnection.java:471) > >>>> at > >>>> > com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:153) > >>>> at > >>>> com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) > >>>> at > >> com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) > >>>> at > >>>> > >> > com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc > >>>> eAdapter.java:717) > >>>> at > >>>> > >> > com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn > >>>> ectorMessageBeanClient.java:313) > >>>> at > >>>> > >> > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me > >>>> ssageBeanContainer.java:920) > >>>> at > >>>> > >> > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic > >>>> e(MessageBeanContainer.java:912) > >>>> at > >>>> com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) > >>>> at > >>>> > >> > com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T > >>>> hreadPoolImpl.java:555) > >>>> Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call > failed > >>>> with compcode '2' ('MQCC_FAILED') reason '2009' > >>>> ('MQRC_CONNECTION_BROKEN'). > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >>>> 223) > >>>> ... 17 more > >>>> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteHconn.exchangeTSH(RemoteHconn.java:1 > >>>> 472) > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.sendNotification(Remote > >>>> AsyncConsume.java:409) > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.sendConnState(RemoteAsy > >>>> ncConsume.java:522) > >>>> at > >>>> com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQCTL(RemoteFAP.java:2066) > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService > >>>> (WMQConsumerOwnerShadow.java:296) > >>>> ... 15 more > >>>> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error > >> on > >>>> receive from host 'centos/10.0.0.1:1414 (centos)'. > >>>> [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr > >>>> ead.java:698) > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr > >>>> ead.java:638) > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 > >>>> 36) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu > >>>> eItem.java:209) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si > >>>> mpleWorkQueueItem.java:100) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte > >>>> m.java:224) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI > >>>> tem(WorkQueueManager.java:298) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement > >>>> ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) > >>>> |#] > >>>> > >>>> [#|2009-11-07T00:54:40.933+0100|WARNING|sun- > >>>> > >> > appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p > >>>> : > >>>> thread-pool-1; w: 41;Context=TestProjects | > >>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14- > >> 4680- > >>>> 82dc-5aae8f323bba;|JMSJCA-E087: > >>>> Error while closing session: JMSCMQ0002: The method 'MQCTL' failed. > >>>> com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ0002: The method > >>>> 'MQCTL' failed. A WebSphere MQ call failed. Please see the linked > >>>> exception for more information. > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav > >>>> a:608) > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >>>> 236) > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >>>> 275) > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService > >>>> (WMQConsumerOwnerShadow.java:308) > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.stop(WMQConsumerOwn > >>>> erShadow.java:654) > >>>> at > >>>> com.ibm.msg.client.wmq.internal.WMQSession.stop(WMQSession.java:1466) > >>>> at > >>>> > >> > com.ibm.msg.client.jms.internal.JmsSessionImpl.stop(JmsSessionImpl.java:20 > >>>> 28) > >>>> at > >>>> > >> > com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:2 > >>>> 89) > >>>> at > >>>> > >> > com.ibm.msg.client.jms.internal.JmsXASessionImpl.close(JmsXASessionImpl.ja > >>>> va:234) > >>>> at > >>>> > >> > com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:2 > >>>> 35) > >>>> at > >>>> > >> > com.ibm.msg.client.jms.internal.JmsXASessionImpl.close(JmsXASessionImpl.ja > >>>> va:199) > >>>> at com.ibm.mq.jms.MQSession.close(MQSession.java:195) > >>>> at > >>>> > com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:167) > >>>> at > >>>> com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) > >>>> at > >> com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) > >>>> at > >>>> > >> > com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc > >>>> eAdapter.java:717) > >>>> at > >>>> > >> > com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn > >>>> ectorMessageBeanClient.java:313) > >>>> at > >>>> > >> > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me > >>>> ssageBeanContainer.java:920) > >>>> at > >>>> > >> > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic > >>>> e(MessageBeanContainer.java:912) > >>>> at > >>>> com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) > >>>> at > >>>> > >> > com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T > >>>> hreadPoolImpl.java:555) > >>>> Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call > failed > >>>> with compcode '2' ('MQCC_FAILED') reason '2009' > >>>> ('MQRC_CONNECTION_BROKEN'). > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >>>> 223) > >>>> ... 19 more > >>>> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:381 > >>>> ) > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:304 > >>>> ) > >>>> at > >>>> com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQCTL(RemoteFAP.java:1923) > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.internal.WMQConsumerOwnerShadow.controlAsyncService > >>>> (WMQConsumerOwnerShadow.java:296) > >>>> ... 17 more > >>>> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error > >> on > >>>> receive from host 'centos/10.0.0.1:1414 (centos)'. > >>>> [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr > >>>> ead.java:698) > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr > >>>> ead.java:638) > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 > >>>> 36) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu > >>>> eItem.java:209) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si > >>>> mpleWorkQueueItem.java:100) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte > >>>> m.java:224) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI > >>>> tem(WorkQueueManager.java:298) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement > >>>> ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) > >>>> |#] > >>>> > >>>> [#|2009-11-07T00:54:40.935+0100|WARNING|sun- > >>>> > >> > appserver2.1|com.stc.jmsjca.core.SerialDelivery|_ThreadID=41;_ThreadName=p > >>>> : > >>>> thread-pool-1; w: 41;Context=TestProjects | > >>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=1ad954a5-2c14- > >> 4680- > >>>> 82dc-5aae8f323bba;|JMSJCA-E055: > >>>> Unexpected exception closing JMS connection: JMSWMQ0019: Failed to > >>>> disconnect from queue manager '' using connection mode '1' and host > >> name > >>>> 'centos'. > >>>> com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ0019: Failed to > >>>> disconnect from queue manager '' using connection mode '1' and host > >> name > >>>> 'centos'. Please see the linked exception for more information. > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.jav > >>>> a:608) > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >>>> 236) > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.internal.WMQConnection.close(WMQConnection.java:677 > >>>> ) > >>>> at > >>>> > >> > com.ibm.msg.client.jms.internal.JmsConnectionImpl.close(JmsConnectionImpl. > >>>> java:328) > >>>> at com.ibm.mq.jms.MQConnection.close(MQConnection.java:93) > >>>> at > >>>> > com.stc.jmsjca.core.SerialDelivery.deactivate(SerialDelivery.java:175) > >>>> at > >>>> com.stc.jmsjca.core.Activation.internalStop(Activation.java:398) > >>>> at > >> com.stc.jmsjca.core.Activation.deactivate(Activation.java:671) > >>>> at > >>>> > >> > com.stc.jmsjca.core.RAJMSResourceAdapter.endpointDeactivation(RAJMSResourc > >>>> eAdapter.java:717) > >>>> at > >>>> > >> > com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.close(Conn > >>>> ectorMessageBeanClient.java:313) > >>>> at > >>>> > >> > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.run(Me > >>>> ssageBeanContainer.java:920) > >>>> at > >>>> > >> > com.sun.ejb.containers.MessageBeanContainer$ASyncClientShutdownTask.servic > >>>> e(MessageBeanContainer.java:912) > >>>> at > >>>> com.sun.ejb.containers.util.WorkAdapter.doWork(WorkAdapter.java:75) > >>>> at > >>>> > >> > com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(T > >>>> hreadPoolImpl.java:555) > >>>> Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call > failed > >>>> with compcode '2' ('MQCC_FAILED') reason '2009' > >>>> ('MQRC_CONNECTION_BROKEN'). > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java: > >>>> 223) > >>>> ... 12 more > >>>> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009 > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:381 > >>>> ) > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteHconn.enterCall(RemoteHconn.java:304 > >>>> ) > >>>> at > >>>> com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQDISC(RemoteFAP.java:2347) > >>>> at > >>>> > >> > com.ibm.msg.client.wmq.internal.WMQConnection.close(WMQConnection.java:659 > >>>> ) > >>>> ... 11 more > >>>> Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9208: Error > >> on > >>>> receive from host 'centos/10.0.0.1:1414 (centos)'. > >>>> [1=-1,2=ffffffff,3=centos/10.0.0.1:1414 (centos),4=TCP] > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveBuffer(RemoteRcvThr > >>>> ead.java:698) > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.receiveOneTSH(RemoteRcvThr > >>>> ead.java:638) > >>>> at > >>>> > >> > com.ibm.mq.jmqi.remote.internal.RemoteRcvThread.run(RemoteRcvThread.java:1 > >>>> 36) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueu > >>>> eItem.java:209) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(Si > >>>> mpleWorkQueueItem.java:100) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueIte > >>>> m.java:224) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueI > >>>> tem(WorkQueueManager.java:298) > >>>> at > >>>> > >> > com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplement > >>>> ation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220) > >>>> |#] > >>>> > >>>> [#|2009-11-07T00:54:41.025+0100|INFO|sun- > >>>> > >> > appserver2.1|javax.enterprise.system.core|_ThreadID=17;_ThreadName=httpWor > >>>> kerThread-4848-1;dpJMSJCATest_1_0_0;|CORE5022: > >>>> All ejb(s) of [dpJMSJCATest_1_0_0] were unloaded successfully!|#] > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Frank Kieviet wrote: > >>>>> Hi sysprv, > >>>>> > >>>>> Not sure what is going wrong here. You configuration appears ok, > >>>> although I > >>>>> don't think you can have seen success with a non-XA factory if you > use > >>>>> NoXA=false. Can you send a larger snippet of the server log? > >>>>> > >>>>> Frank > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: users-return-12104-frank.kieviet=sun.com@open- > esb.dev.java.net > >>>>>> [mailto:users-return-12104-frank.kieviet=sun.com@open- > >> esb.dev.java.net] > >>>> On > >>>>>> Behalf Of ioj > >>>>>> Sent: Friday, November 06, 2009 07:54 > >>>>>> To: [hidden email] > >>>>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>>>> > >>>>>> > >>>>>> Hi! > >>>>>> > >>>>>> I've done a little more testing with JMSJCA jndi://, MQ 7 and a > >> simple > >>>>>> JCD. > >>>>>> > >>>>>> The JCD is strictly a consumer, and the CAPS classic documentation > >>>> tells > >>>>>> us that means it works under a XA transaction. > >>>>>> > >>>>>> This is my JMSJCA configuration (env object): > >>>>>> > >>>>>> Connection URL: jndi:// > >>>>>> Options: > >>>>>> > >>>>>> JMSJCA.NoXA=false > >>>>>> JMSJCA.overrideissamerm=true > >>>>>> JMSJCA.QueueCF=centos_QM1_xaqcf > >>>>>> > >> java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory > >>>>>> java.naming.provider.url=file:/var/mqm/jndictx > >>>>>> > >>>>>> > >>>>>> centos_QM1_xaqcf is defined as a MQXAQueueConnectionFactory. > >>>>>> > >>>>>> When I enable the application, it doesn't receive any messages from > >> the > >>>>>> queue... When I disable the application, I see this in the > GlassFish > >>>> logs: > >>>>>> JMSCMQ0001: WebSphere MQ call failed with compcode '2' > >> ('MQCC_FAILED') > >>>>>> reason '2009' ('MQRC_CONNECTION_BROKEN'). > >>>>>> > >>>>>> The MQ queue manager reports unexpected errors (I'll take these up > >> with > >>>>>> IBM when I'm more clear on what I'm doing), and dumps First Failure > >>>>>> Symptom Reports; yet, its "Connection History" has Reason 2072 > >>>>>> (MQRC_SYNCPOINT_NOT_AVAILABLE) and before that Reason 30737 > >>>>>> (lpiRC_WAITCANCELLED_ASYNCCONSUME). > >>>>>> > >>>>>> > >>>>>> Am I configuring JMSJCA wrong? > >>>>>> > >>>>>> > >>>>>> Some more test configurations and results: > >>>>>> > >>>>>> Non-XA connection factory, JMSJCA.NoXA=false := JCD works as > expected > >>>>>> (emulated-XA?) > >>>>>> > >>>>>> XA connection factory, JMSJCA.NoXA=false := JCD works as > expected > >>>>>> > >>>>>> Non-XA connection factory, JMSJCA.NoXA=true := Obvious, > >>>>>> MQConnectionFactory can't be cast to XAConnectionFactory > >>>>>> > >>>>>> Non-XA connection factory, JMSJCA.NoXA=true := above :) > >>>>>> > >>>>>> > >>>>>> Thanks in advance, > >>>>>> > >>>>>> /sysprv > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Frank Kieviet wrote: > >>>>>>> Hi sysprv, > >>>>>>> > >>>>>>>> The multi-instance queue manager feature (new in v7.0.1) is > >> important > >>>>>> to > >>>>>>>> us; at first glance that means using > >>>>>>>> MQConnectionFactory.setClientReconnectHosts(); > >>>>>>>> Can JMSJCA set properties it does not know about? I'll > investigate > >>>> this > >>>>>>>> more tomorrow. > >>>>>>> Recently we added a new feature to the WMQ support in JMSJCA that > >> will > >>>>>> allow > >>>>>>> you to set arbitrary properties on the factory. See > >>>>>>> http://wiki.open-esb.java.net/Wiki.jsp?page=JMSJCAReadme#section- > >>>>>> JMSJCAReadm > >>>>>>> e-SupportForWebSphereMQMQSeries, where you'll find this: > >>>>>>> > >>>>>>> <Quote> > >>>>>>> The com.ibm.mq.jms.MQConnectionFactory has a large list of > >> properties > >>>> of > >>>>>>> type boolean, int, long, String, URL which can be set. The setter > >> can > >>>> be > >>>>>>> invoked by specifying a connection URL option named using the > >>>> following > >>>>>>> convention: remove the 'set' prefix from the name of the setter > >> method > >>>>>> and > >>>>>>> prepend 'WMQ_', e.g. > >>>>>>> > >>>>>>> * setMessageRetention(int): WMQ_MessageRetention=1 > >>>>>>> * setSecurityExit(String): > >>>> WMQ_SecurityExit=wmq.exits.MySecurityExit > >>>>>>> * setSparseSubscriptions(boolean): > WMQ_SparseSubscriptions=true > >>>>>>> </Quote> > >>>>>>> > >>>>>>>> Now I'm interested in these "naked" factories just for the sake > of > >>>>>>>> knowing :) > >>>>>>> You could write a small Java program that instantiates the > >> factories, > >>>>>> and > >>>>>>> then bind these factories into JNDI. The JNDI provider could a > file > >>>>>> provider > >>>>>>> so that you'll end up with a file that has a serialized connection > >>>>>> factory > >>>>>>> in there. You can then tell JMSJCA to use this JNDI file provider > to > >>>>>> read > >>>>>>> the file, deserialize the factory, and as such obtain an instance > of > >>>> the > >>>>>>> factory. This small Java program that would initially instantiate > >> the > >>>>>>> factories would simply call new > com.ibm.mq.jms.MQConnectionFactory() > >>>> and > >>>>>> set > >>>>>>> some properties on this factory. > >>>>>>> > >>>>>>> BTW, if you're going down this road, also set > >>>>>> JMSJCA.overrideissamerm=true > >>>>>>> to workaround an issue in GlassFish/WMQ where GlassFish tries to > >> join > >>>> an > >>>>>> XA > >>>>>>> resource onto a suspended XA resource. > >>>>>>> > >>>>>>> Frank > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: users-return-11999-frank.kieviet=sun.com@open- > >> esb.dev.java.net > >>>>>>>> [mailto:users-return-11999-frank.kieviet=sun.com@open- > >>>> esb.dev.java.net] > >>>>>> On > >>>>>>>> Behalf Of ioj > >>>>>>>> Sent: Monday, November 02, 2009 11:20 > >>>>>>>> To: [hidden email] > >>>>>>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>>>>>> > >>>>>>>> > >>>>>>>> Hi Frank, > >>>>>>>> > >>>>>>>> Yes, as expected, with wmq:// the JCD can connect to the queue > >>>> manager > >>>>>>>> without any problems. > >>>>>>>> > >>>>>>>> > >>>>>>>> The multi-instance queue manager feature (new in v7.0.1) is > >> important > >>>>>> to > >>>>>>>> us; at first glance that means using > >>>>>>>> MQConnectionFactory.setClientReconnectHosts(); > >>>>>>>> Can JMSJCA set properties it does not know about? I'll > investigate > >>>> this > >>>>>>>> more tomorrow. > >>>>>>>> > >>>>>>>> > >>>>>>>> Apart from that, I expected better performance; just an > uneducated > >>>>>> guess. > >>>>>>>> Now I'm interested in these "naked" factories just for the sake > of > >>>>>>>> knowing :) > >>>>>>>> > >>>>>>>> > >>>>>>>> /sysprv > >>>>>>>> > >>>>>>>> > >>>>>>>> Frank Kieviet wrote: > >>>>>>>>> Hi sysprv, > >>>>>>>>> > >>>>>>>>> I would hope that IBM would provide complete backwards > >>>> compatibility, > >>>>>> so > >>>>>>>> you > >>>>>>>>> could copy the WMQ jars (com.ibm.mqjms.jar, com.ibm.mq.jar, > >>>>>>>>> com.ibm.mqetclient.jar and dhbcore.jar if I remember correctly) > >> into > >>>>>> the > >>>>>>>> lib > >>>>>>>>> directory, and try to use a wmq://xxxx connection URL. If that > >>>> works, > >>>>>> at > >>>>>>>>> least we know how to programmatically create the "naked" > >> factories. > >>>>>> Next > >>>>>>>> we > >>>>>>>>> can figure out how to bind them into JNDI. Before we go there, > >> would > >>>>>>>> using > >>>>>>>>> the wmq:// URL work for you? Or is it something particular you > >> hope > >>>> to > >>>>>>>> get > >>>>>>>>> out of the JNDI? If so, could you elaborate on that a little > bit? > >>>>>>>>> > >>>>>>>>> Frank > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: ioj [mailto:[hidden email]] > >>>>>>>>>> Sent: Monday, November 02, 2009 10:31 > >>>>>>>>>> To: [hidden email] > >>>>>>>>>> Cc: [hidden email]; [hidden email] > >>>>>>>>>> Subject: Re: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>>>>>>>> > >>>>>>>>>> Hi! > >>>>>>>>>> > >>>>>>>>>> Yes, that's exactly what I tried to do; our developers are > chummy > >>>>>> with > >>>>>>>>>> STCMS and GF MQ; but for some applications we in ops would > rather > >>>> use > >>>>>>>>>> WMQ. Hence this. And we need WMQ >= 7.0.1 (multi-instance queue > >>>>>>>> managers). > >>>>>>>>>> Our company's merely an IBM customer; the other way I know of > to > >>>> get > >>>>>>>> WMQ > >>>>>>>>>> is the 90 day trial :) > >>>>>>>>>> I'll check with IBM on this; perhaps Sun already has some > >>>> partnership > >>>>>>>> or > >>>>>>>>>> agreement with IBM? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Yep, I'm in contact with Jason, and bug him from time to time. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I have access to test systems with WMQ and GF (CAPS only, not > >>>>>> OpenESB) > >>>>>>>>>> running on RHEL and AIX. And time too. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> No problem with moving to OpenESB-users; I just considered this > >> to > >>>> be > >>>>>>>>>> very JMSJCA-specific. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Apart from explicit WMQ7 support (which would be very nice, as > >> WMQ > >>>>>> has > >>>>>>>>>> become much more JMS-like since v6), how would one go about > >> setting > >>>>>> up > >>>>>>>>>> naked factories? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> /sysprv > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Frank Kieviet wrote: > >>>>>>>>>>> Hi sysprv, > >>>>>>>>>>> > >>>>>>>>>>> From what you're describing it looks like you're deploying the > >> IBM > >>>>>> RAR > >>>>>>>>>> into > >>>>>>>>>>> GlassFish, then bind its connection factories into JNDI, and > >> then > >>>>>> use > >>>>>>>>>> JMSJCA > >>>>>>>>>>> to look them up. > >>>>>>>>>>> > >>>>>>>>>>> If that's the case, the issue with that is that the RAR has a > >> lot > >>>> of > >>>>>>>>>>> functionality to start/stop transactions, participate in > >>>> connection > >>>>>>>>>> pooling > >>>>>>>>>>> etc. To the application, the RAR exposes only application > >>>> connection > >>>>>>>>>>> factories. In practical terms, these are non-XA connection > >>>>>> factories. > >>>>>>>> In > >>>>>>>>>>> other words, the factories that the RAR exposes to the > >> application > >>>>>> are > >>>>>>>>>>> wrappers around the "naked" connection factories, and these > >>>> wrappers > >>>>>>>> add > >>>>>>>>>> a > >>>>>>>>>>> lot of functionality. > >>>>>>>>>>> > >>>>>>>>>>> What JMSJCA needs are the "naked" connection factories. What I > >>>> mean > >>>>>>>> with > >>>>>>>>>>> that are the factories that provide a direct line of > >> communication > >>>>>>>>>> between > >>>>>>>>>>> the calling code and the JMS server, of course all using the > JMS > >>>>>> api. > >>>>>>>>>>> So, to make it work with JNDI, you would have to instantiate > the > >>>> WMQ > >>>>>>>>>> "naked" > >>>>>>>>>>> factories, bind them into JNDI (e.g. a file provider if WMQ 7 > >> did > >>>>>> not > >>>>>>>>>> any > >>>>>>>>>>> new facilities such as a built-in JNDI server), and use those > in > >>>>>>>> JMSJCA. > >>>>>>>>>>> We're looking into adding explicit support for WMQ7. First > issue > >>>> we > >>>>>>>> ran > >>>>>>>>>> into > >>>>>>>>>>> is how to get a copy of WMQ7. Do you know by any chance? > >>>>>>>>>>> > >>>>>>>>>>> BTW, are you in contact with Jason Baragry? > >>>>>>>>>>> > >>>>>>>>>>> One more thing: would you mind if we move this discussion to > the > >>>>>>>> OpenESB > >>>>>>>>>>> users list? > >>>>>>>>>>> > >>>>>>>>>>> Frank > >>>>>>>>>>> > >>>>>>>>>>> Frank Kieviet > >>>>>>>>>>> Senior Staff Engineer, SOA/BI > >>>>>>>>>>> Sun Microsystems, Monrovia, CA > >>>>>>>>>>> Tel +1 626 471 6322 > >>>>>>>>>>> Blog: http://frankkieviet.blogspot.com/ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: ioj [mailto:[hidden email]] > >>>>>>>>>>>> Sent: Monday, November 02, 2009 08:44 > >>>>>>>>>>>> To: [hidden email] > >>>>>>>>>>>> Subject: JMSJCA, CAPS 6.2, WebSphere MQ 7 > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Frank :) > >>>>>>>>>>>> > >>>>>>>>>>>> Configured a JMSJCA-driven JCD in jndi:// mode to connect to > a > >>>>>>>>>> WebSphere > >>>>>>>>>>>> MQ 7 queue; Getting this error: > >>>>>>>>>>>> > >>>>>>>>>>>> [#|2009-11-02T17:09:55.496+0100|INFO|sun- > >>>>>>>>>>>> > >> > appserver2.1|javax.enterprise.system.core.classloading|_ThreadID=18;_Threa > >>>>>>>>>>>> dName=httpWorkerThread-4848-4;dpJMSJCATest_1_0_0;|LDR5010: > >>>>>>>>>>>> All ejb(s) of [dpJMSJCATest_1_0_0] loaded successfully!|#] > >>>>>>>>>>>> > >>>>>>>>>>>> [#|2009-11-02T17:09:55.498+0100|WARNING|sun- > >>>>>>>>>>>> > >> > appserver2.1|com.stc.jmsjca.core.Activation|_ThreadID=25;_ThreadName=JMSJC > >>>>>>>>>>>> A > >>>>>>>>>>>> connect;Context=TestProjects | > >>>>>>>>>>>> > prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN;_RequestID=07fb37e9- > >>>> 63b3- > >>>>>>>>>> 4015- > >>>>>>>>>>>> a035-dcc50c47ac93;|JMSJCA-E016: > >>>>>>>>>>>> [serial-QueueReceiver(QJMSJCATEST){TestProjects | > >>>>>>>>>>>> prjJMSJCATest/svcJMSJCATest/qJMSJCATestIN} @ [jndi://]]: > >> message > >>>>>>>>>>>> delivery initiation failed (attempt #1); will retry in 1 > >> seconds. > >>>>>> The > >>>>>>>>>>>> error was: > >>>> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl > >>>>>>>>>>>> cannot be cast to javax.jms.XAQueueConnectionFactory > >>>>>>>>>>>> java.lang.ClassCastException: > >>>>>>>>>>>> com.ibm.mq.connector.outbound.QueueConnectionFactoryImpl > cannot > >>>> be > >>>>>>>> cast > >>>>>>>>>>>> to javax.jms.XAQueueConnectionFactory > >>>>>>>>>>>> at > >>>>>>>>>>>> > >> > com.stc.jmsjca.jndi.RAJNDIObjectFactory.createConnectionFactory(RAJNDIObje > >>>>>>>>>>>> ctFactory.java:208) > >>>>>>>>>>>> at > >>>>>> com.stc.jmsjca.core.SerialDelivery.start(SerialDelivery.java:74) > >>>>>>>>>>>> at > >>>>>> com.stc.jmsjca.core.Activation.asyncStart(Activation.java:552) > >>>>>>>>>>>> at > >>>>>> com.stc.jmsjca.core.Activation.access$000(Activation.java:81) > >>>>>>>>>>>> at > com.stc.jmsjca.core.Activation$1.run(Activation.java:347) > >>>>>>>>>>>> at java.lang.Thread.run(Thread.java:619) > >>>>>>>>>>>> |#] > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Details: > >>>>>>>>>>>> > >>>>>>>>>>>> I've installed and configured the WMQ 7 RA from IBM in > >> GlassFish > >>>>>>>>>>>> Enterprise v2.1 Patch 02. The IVT (installation verification > >>>> test) > >>>>>>>> app > >>>>>>>>>>>> from IBM runs fine and passes all tests. > >>>>>>>>>>>> > >>>>>>>>>>>> Next, I have the simplest message driven JCD you can think > of: > >> it > >>>>>>>> reads > >>>>>>>>>>>> a TextMessage using JMSJCA and writes the Text to the > >> server.log. > >>>>>>>> Works > >>>>>>>>>>>> fine with GlassFish MQ. > >>>>>>>>>>>> > >>>>>>>>>>>> Then I have a connector connection pool of type > >>>>>>>> QueueConnectionFactory, > >>>>>>>>>>>> using the IBM RA, configured for XA (Transaction Support: > >>>>>>>>>> XATransaction) > >>>>>>>>>>>> When I configure JMSJCA (inside GF, with the Env overrides in > >>>> CAPS > >>>>>>>> 6.x) > >>>>>>>>>>>> with: > >>>>>>>>>>>> > >>>>>>>>>>>> Connection URL: jndi:// > >>>>>>>>>>>> JMSJCA.NoXA=false > >>>>>>>>>>>> JMSJCA.QueueCF=jms/wmq/xa/qcf > >>>>>>>>>>>> > >>>>>>>>>>>> and enable the JCD, I get the message above. > >>>>>>>>>>>> > >>>>>>>>>>>> I've made sure that the MQ transaction support jar is > available > >>>> to > >>>>>>>> the > >>>>>>>>>>>> appserver etc. etc. (the IVT passes all tests incl. > >> transactions > >>>> - > >>>>>>>>>>>> though it's much simpler than a JCD with JMSJCA +) > >>>>>>>>>>>> > >>>>>>>>>>>> What's going wrong here, and how can it be fixed? > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks in advance! > >>>>>>>>>>>> /sysprv > >>>>>>>>>>>> > >>>>>>>>>>>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [hidden email] > >>> For additional commands, e-mail: [hidden email] > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [hidden email] > >> For additional commands, e-mail: [hidden email] > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [hidden email] > > For additional commands, e-mail: [hidden email] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
