Foreign JMS not enlisting XA Transactions

I'm working on implementing an XA interface layer to an implementation of a foreign JMS provider and am having a problem with enlisting XA transactions in WebLogic.
I implemented a simple JNDI that stores and retrieves serialized versions of classes in the local filesystem.
I create an XATopicConnectionFactory named ambxatcf and a Topic named ChatterTopic and store them in there.
The XATopicConnection implements XAConnection.
I put a client jar in bea/weblogic91/samples/domains/wl_server/lib/ which contains the JNDI code and all of my XA classes which call the JMS.
That gets picked up by the server on startup.
In the Web Logic Admin Console:
I create a Foreign Server under JMS Modules, ambrosiaServer.
I set the JNDI Initial Context Factory set to my JNDI InitialContext class and the JNDI Properties is the path to my JNDI filestore so that it can find the serialized objects.
I create a Foreign Destination in this server which has a Local JNDI Name: Chatter and Remote JNDI Name: ChatterTopic
And then also in this server, I create a Foreign Connection Factory, Local JNDI Name: ambxatcf and Remote JNDI Name: XATopicConnectionFactory.
Then in Deployments, I Install the jar containing my bean and Start it.
Then I run the client and the bean prints out the XATopicConnectionFactory and it's the one that came out my JNDI.
I have messages in my XATopicConnectionFactory, XATopicConnection and XATopicSession code so I know they're getting called.
What's not getting called is XATopicSession.getXAResource() or my XAResourceImpl.start() or XAResourceImpl.commit().
This happens whether I have the bean set up for bean managed or container managed transactions.
I'm testing against WebLogic 9.1.
Thanks,
Don Hermes

Hi Tom,
          Thank you for your response.
          I saw the article in the 8.1 documentation but I also found the following in the 9.1 docs.
          So, I assumed it would work.
          Was that assumption wrong?
          Thanks,
          Don
          =====================
          http://e-docs.bea.com/wls/docs91/jms/j2ee.html
          Automatically Enlisting Transactions
          This feature works for either WebLogic JMS implementations or for third-party JMS providers that support two-phase commit transactions (XA protocol). If a wrapped JMS connection sends or receives a message inside a transaction context, the JMS session being used to send or receive the message is automatically enlisted in the transaction through the XA capabilities of the JMS provider. This is the case whether the transaction was started implicitly because the JMS code was invoked inside an EJB with container-managed transactions enabled, or whether the transaction was started manually using the UserTransaction interface in a servlet or an EJB that supports bean-managed transactions.

Similar Messages

  • Could not enlist in transaction

    Hi All
    wls70 --> tux8.0
    some times I get the following errors
    ==##[2004-07-08 08:43:57.516]##== HomeReceiver#[281] exception: interboss.util.InterException:
    -180001****??tuxedo????****TPESYSTEM(12):0:0:TPED_MINVAL(0):QMNONE(0):0:ERROR:
    Could not enlist in transaction
    at weblogic.wtc.gwt.TuxedoConnection.<init>(TuxedoConnection.java:120)
    at weblogic.wtc.gwt.TuxedoConnectionFactory.getTuxedoConnection(TuxedoConnectionFactory.java:32)
    at interboss.util.ConnTuxedo.wtcTransCall(ConnTuxedo.java:42)
    at interboss.util.ConnTuxedo.wtcTransCall(ConnTuxedo.java:24)
    at interboss.busi.CashPay.runClass(CashPay.java:129)
    at interboss.servlet.HomeReceiver.Process(HomeReceiver.java:156)
    at interboss.servlet.HomeReceiver.doPost(HomeReceiver.java:286)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1058)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:401)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:306)
    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5445)
    at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:780)
    at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3105)
    at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2588)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)

    Hi,
    Can you provide a little context here? This error occurs when WTC tries to enlist
    itself in the WLS transaction and receives a SystemException. What is starting
    the transaction?
    Regards,
    Todd
    "dong" <[email protected]> wrote:
    >
    Hi All
    wls70 --> tux8.0
    some times I get the following errors
    ==##[2004-07-08 08:43:57.516]##== HomeReceiver#[281] exception: interboss.util.InterException:
    -180001****??tuxedo????****TPESYSTEM(12):0:0:TPED_MINVAL(0):QMNONE(0):0:ERROR:
    Could not enlist in transaction
    at weblogic.wtc.gwt.TuxedoConnection.<init>(TuxedoConnection.java:120)
    at weblogic.wtc.gwt.TuxedoConnectionFactory.getTuxedoConnection(TuxedoConnectionFactory.java:32)
    at interboss.util.ConnTuxedo.wtcTransCall(ConnTuxedo.java:42)
    at interboss.util.ConnTuxedo.wtcTransCall(ConnTuxedo.java:24)
    at interboss.busi.CashPay.runClass(CashPay.java:129)
    at interboss.servlet.HomeReceiver.Process(HomeReceiver.java:156)
    at interboss.servlet.HomeReceiver.doPost(HomeReceiver.java:286)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1058)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:401)
    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:306)
    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5445)
    at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:780)
    at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3105)
    at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2588)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)

  • Foreign JMS and Enlisting Transactions?

    I'm working on implementing an XA interface layer to an implementation of a foreign JMS provider and am having a problem with enlisting XA transactions in WebLogic.
              I implemented a simple JNDI that stores and retrieves serialized versions of classes in the local filesystem.
              I create an XATopicConnectionFactory named ambxatcf and a Topic named ChatterTopic and store them in there.
              The XATopicConnection implements XAConnection.
              I put a client jar in bea/weblogic91/samples/domains/wl_server/lib/ which contains the JNDI code and all of my XA classes which call the JMS.
              That gets picked up by the server on startup.
              In the Web Logic Admin Console:
              I create a Foreign Server under JMS Modules, ambrosiaServer.
              I set the JNDI Initial Context Factory set to my JNDI InitialContext class and the JNDI Properties is the path to my JNDI filestore so that it can find the serialized objects.
              I create a Foreign Destination in this server which has a Local JNDI Name: Chatter and Remote JNDI Name: ChatterTopic
              And then also in this server, I create a Foreign Connection Factory, Local JNDI Name: ambxatcf and Remote JNDI Name: XATopicConnectionFactory.
              Then in Deployments, I Install the jar containing my bean and Start it.
              Then I run the client and the bean prints out the XATopicConnectionFactory and it's the one that came out my JNDI.
              I have messages in my XATopicConnectionFactory, XATopicConnection and XATopicSession code so I know they're getting called.
              What's not getting called is XATopicSession.getXAResource() or my XAResourceImpl.start() or XAResourceImpl.commit().
              This happens whether I have the bean set up for bean managed or container managed transactions.
              I'm testing against WebLogic 9.1.
              Thanks,
              Don Hermes

    Hi Tom,
              Thank you for your response.
              I saw the article in the 8.1 documentation but I also found the following in the 9.1 docs.
              So, I assumed it would work.
              Was that assumption wrong?
              Thanks,
              Don
              =====================
              http://e-docs.bea.com/wls/docs91/jms/j2ee.html
              Automatically Enlisting Transactions
              This feature works for either WebLogic JMS implementations or for third-party JMS providers that support two-phase commit transactions (XA protocol). If a wrapped JMS connection sends or receives a message inside a transaction context, the JMS session being used to send or receive the message is automatically enlisted in the transaction through the XA capabilities of the JMS provider. This is the case whether the transaction was started implicitly because the JMS code was invoked inside an EJB with container-managed transactions enabled, or whether the transaction was started manually using the UserTransaction interface in a servlet or an EJB that supports bean-managed transactions.

  • JMS not contributing in transactions

    Hello,
              I am facing currently a problem with JMS and a stateless sessionbean
              with Trx=RequiresNew. The sessionbean is deployed in its own WLS
              instance. The second WLS has a TopicConnectionFactory setup with User
              Transactions Enabled=false and XAConnection Factory Enabled=false.
              The method causing troubles in the session bean basically looks as
              follows:
              public void process() {
              try {
              doSomething();
              catch (Exception e) {
              publishToJMS("Problem Occurred");
              throw new EKBException("Problem occured",e);
              The problem is, that in case of an exception, the publish is somehow
              rolledback (with a timeout during rollback exception), even that the
              ConnectionFactory does not have the XA/UserTrx attributes set to true.
              Is is contributing to the transaction - I verified this by suspending
              the transaction with the
              weblogic.transaction.TxHelper.getTransactionManager().forceSuspend()/forceResume()
              calls and then everything is working fine.
              This is on WLS6.1SP3 Windows and Solaris.
              Thanks for any help
              Juerg
              

              Tom,
              But when I use a transacted session, the message will not be published in case
              of a rollback.
              This is not what I want. Our JMS system is here for publishing alerts and audits
              and in case of a
              problem I want to publish an alert and then throw an EJBException, so probably
              using
              suspend/resume is the better way. I am really surprised that it does not work
              with User
              Transactions Enabled=false and XAConnection Factory Enabled=false. Is this a bug?
              Thanks
              Juerg
              Tom Barnes <[email protected]> wrote:
              >A transacted session will not work with the XA JMS API - the XA JMS API
              >ignores the transacted flag. Just don't use the "createXAxxxx"
              >variants and you'll be fine in WL. If you care about
              >performance, a transacted session is more costly than a
              >non-transacted non-transactional session so the suspend/resume
              >will do you better.
              >
              >Tom
              >
              >Juerg Staub wrote:
              >> Hi Tom,
              >>
              >> To use a transacted session do I just need to set XAConnection Factory
              >Enabled=true
              >> and call createTopicSession(true,Session.AUTO_ACKNOWLEDGE) or are there
              >any other
              >> steps involved?
              >> I postin from home at the moment, so I will post the config.xml and
              >the code snippet
              >> tomorrow.
              >>
              >> Thanks
              >>
              >> Juerg
              >>
              >> Tom Barnes <[email protected]> wrote:
              >>
              >>>I do not know what is going on. If you like, post your
              >>>config.xml and perhaps the code snippets for looking up the CF
              >>>and creating the connection and I will take a quick look.
              >>>In the mean-time you can
              >>>use suspend/resume, or a transacted session (just remember
              >>>to call session.commit)...
              >>>
              >>>Tom
              >>>
              >>>Juerg Staub wrote:
              >>>
              >>>>Hi Tom,
              >>>>
              >>>>Thanks for your reply.
              >>>>
              >>>>Tom Barnes <[email protected]> wrote:
              >>>>
              >>>>
              >>>>>Are you sure the JNDI name of the connection factory the SSB is using
              >>>>>is the same as the JNDI name for the CF configured with false/false?
              >>>>
              >>>>
              >>>>Yes I am.
              >>>>
              >>>>
              >>>>
              >>>>>Make sure that the publisher is not use a
              >>>>>"transacted" session. (Make sure first parameter
              >>>>>to createTopicSession() is false.)
              >>>>>
              >>>>
              >>>>
              >>>>I use topicConnection.createTopicSession(false,Session.AUTO_ACKNOWLEDGE).
              >>>
              >>>>I see in the console that both WLS have inflight transactions....
              >>>>
              >>>>What else could be wrong?
              >>>>
              >>>>Juerg
              >>>>
              >>>>
              >>>>
              >>>>
              >>>>
              >>>>
              >>>>
              >>>>
              >>>>
              >>>>
              >>>>>Tom
              >>>>>
              >>>>>Juerg Staub wrote:
              >>>>>
              >>>>>
              >>>>>>Hello,
              >>>>>>
              >>>>>>I am facing currently a problem with JMS and a stateless sessionbean
              >>>>>>with Trx=RequiresNew. The sessionbean is deployed in its own WLS
              >>>>>>instance. The second WLS has a TopicConnectionFactory setup with
              >User
              >>>>>>Transactions Enabled=false and XAConnection Factory Enabled=false.
              >>>>>>
              >>>>>>The method causing troubles in the session bean basically looks
              >as
              >>>>>>follows:
              >>>>>>
              >>>>>>
              >>>>>>public void process() {
              >>>>>>
              >>>>>> try {
              >>>>>> doSomething();
              >>>>>> catch (Exception e) {
              >>>>>> publishToJMS("Problem Occurred");
              >>>>>> throw new EKBException("Problem occured",e);
              >>>>>> }
              >>>>>>
              >>>>>>
              >>>>>>The problem is, that in case of an exception, the publish is somehow
              >>>>>>rolledback (with a timeout during rollback exception), even that
              >the
              >>>>>>ConnectionFactory does not have the XA/UserTrx attributes set to
              >true.
              >>>>>>Is is contributing to the transaction - I verified this by suspending
              >>>>>>the transaction with the
              >>>>>>weblogic.transaction.TxHelper.getTransactionManager().forceSuspend()/forceResume()
              >>>>>>calls and then everything is working fine.
              >>>>>>
              >>>>>>This is on WLS6.1SP3 Windows and Solaris.
              >>>>>>
              >>>>>>
              >>>>>>Thanks for any help
              >>>>>>
              >>>>>>Juerg
              >>>>>
              >>
              >
              

  • Foreign JMS Providers with WebLogic Server does not close connection

              Hello All,
              We tried to use wlsmqseries.zip classes (specially JNDI Mapper) for integrating
              WebLogic Server with MQ so that we can incorporate XA transactions. We use LDAP
              context factory to bind MQ.
              We found a number of LDAP connections are getting opened by JNDIMapper, but it's
              not getting closed.
              Can some one give some clue to this ?
              Also any suggestion to serve the current purpose is welcome.
              Thanks,
              Sudarson
              

    What version are you using? "wlsmqseries.zip" does enlisting of MQ JMS
              sessions in XA transactions, but WLS 8.1 does that for you out of the box.
              If you're using 8.1, it would be better to use the new 8.1 features for
              foreign JMS providers.
              A place to start is the "Using WebLogic JMS with EJBs and Servlets" section
              of the JMS programming documentation for 8.1, and there have been many other
              posts on this newsgroup with details. (There also appear to be quite a few
              customers using this feature in their own systems, judging from the number
              of posts.)
              greg
              "sudarson" <[email protected]> wrote in message
              news:40bf05ea$1@mktnews1...
              >
              > Reposting the message. Awaiting response from newsgroup or BEA
              > Thanks,
              > Sudarson
              > "sudarson" <[email protected]> wrote:
              > >
              > >Hello All,
              > >
              > >We tried to use wlsmqseries.zip classes (specially JNDI Mapper) for
              integrating
              > >WebLogic Server with MQ so that we can incorporate XA transactions. We
              > >use LDAP
              > >context factory to bind MQ.
              > >
              > >We found a number of LDAP connections are getting opened by JNDIMapper,
              > >but it's
              > >not getting closed.
              > >
              > >Can some one give some clue to this ?
              > >
              > >Also any suggestion to serve the current purpose is welcome.
              > >
              > >Thanks,
              > >Sudarson
              >
              

  • MDB not connecting to Foreign JMS destination

    I'm running WL 9.2 MP3 on Windows machine. I'm deploying a rudimentary MDB congured against as Foreign Service JMS provider against MQ V6.0 with local queue running on the same local machine.
              I'm using Maven2 to build all the sub-projects - including my ejb project and enterprise application project. The EAR file deploys successfully without any errors (one minor warning about lack of explicity transactionsi in onMessage() method...). I don't see any errors but my MDB Connection Status is "disconnected" - I've enabled Debug for key sections under default and weblogic sections - still not errors of any kind but it does not connect! What can I do to find the problem?!
              Here is my EJB definition:
              public class AnotherBean extends GenericMessageDrivenBean implements
                        MessageDrivenBean, MessageListener {
                   private static final long serialVersionUID = 1L;
                   /* When the bean is activated, this method will be invoked
                   * @see javax.jms.MessageListener#onMessage(javax.jms.Message)
                   public void onMessage(Message msg) {
                        System.out.println("\n=========================================");
                        System.out.println("=> Message received!");
                        if (msg instanceof TextMessage) {
                             try {
                                  System.out.println("=> Message: "
                                            + ((TextMessage) msg).getText());
                             } catch (JMSException e) {
                                  e.printStackTrace();
                        // Place the message on to the reply queue (WLReplyQueue)
                        System.out.println("=========================================");
              Here is my ejb-jar.xml:
              <ejb-jar
              xmlns="http://java.sun.com/xml/ns/j2ee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd"
              version="2.1">
              <enterprise-beans>
              <message-driven>
              <ejb-name>AnotherBean</ejb-name>
              <ejb-class>com.ibm.myclient.gems.ejb.AnotherBean</ejb-class>
              <transaction-type>Container</transaction-type>
              <activation-config>
              <activation-config-property>
              <activation-config-property-name>destinationType</activation-config-property-name>
              <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
              </activation-config-property>
              </activation-config>
              </message-driven>
              </enterprise-beans>
              </ejb-jar>
              Here is my weblogic-ejb-jar.xml:
              <weblogic-ejb-jar
              xmlns="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">
              <weblogic-enterprise-bean>
              <ejb-name>AnotherBean</ejb-name>
              <message-driven-descriptor>
              <destination-jndi-name>jms/WLReceiverQueue</destination-jndi-name>
              <connection-factory-jndi-name>jms/WLReceiverQCF</connection-factory-jndi-name>
              </message-driven-descriptor>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              WL JMS module is setup like this:
              <weblogic-jms xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schema
              Location="http://www.bea.com/ns/weblogic/920 http://www.bea.com/ns/weblogic/920.xsd">
              <foreign-server name="MQTestForeignServer">
              <default-targeting-enabled>true</default-targeting-enabled>
              <foreign-destination name="ReceiverDetails">
              <local-jndi-name>jms/WLReceiverQueue</local-jndi-name>
              <remote-jndi-name>MQSenderQueue</remote-jndi-name>
              </foreign-destination>
              <foreign-destination name="ReplyDetails">
              <local-jndi-name>jms/WLReplyQueue</local-jndi-name>
              <remote-jndi-name>MQReceiverQueue</remote-jndi-name>
              </foreign-destination>
              <foreign-connection-factory name="ReceiverCF">
              <local-jndi-name>jms/WLReceiverQCF</local-jndi-name>
              <remote-jndi-name>MQSenderQCF</remote-jndi-name>
              </foreign-connection-factory>
              <foreign-connection-factory name="ReplyCF">
              <local-jndi-name>jms/WLReplyQCF</local-jndi-name>
              <remote-jndi-name>MQReceiverQCF</remote-jndi-name>
              </foreign-connection-factory>
              <initial-context-factory>com.sun.jndi.fscontext.RefFSContextFactory</initial-context-factory>
              <connection-url>file:/ C:/JNDI-Directory</connection-url>
              </foreign-server>
              </weblogic-jms>

    Thanks for the tips - I solved the problem. I first recreated my .bindinds file making sure that both QCF objects are in there (it turned out that only ONE of them was there and not the other). Next, I also removed an extra space " " from the URL reference in the Foreign JMS service setup in the console:
              was like this initially:
              <connection-url>file:/ C:/JNDI-Directory</connection-url>
              and I changed it to this - removing single space after first "/":
              <connection-url>file:/C:/JNDI-Directory</connection-url>
              Restarted the whole thing and it worked! Thanks again.

  • Setting up Foreign JMS Dest. to MQ: JMS Destination not found

    I'm trying to set up a foreign JMS destination to an MQ queue. There are several steps you have to get right for this to work. I thought I did them all correctly, but when I deploy the app with an MDB that references the JNDI name, it says (in the console) that the destination with the particular JNDI name could not be found.
              I first used JMSAdmin to create the JNDI data in the provider URL file location. I created the qcf and the queue. I've displayed my results that I set with that, and it all looks fine. One thing that I'm unsure about with this, however, is that the document on using JMSAdmin doesn't make it clear exactly which field in the "queue" definition is the JNDI name, and which is the MQ queue name. My guess is that the value of the "q" field is the JNDI name, and the value of the "queue" field is the MQ queue name. I'm not certain.
              I then created the foreign JMS info in the WebLogic console. I first created the foreign JMS server, using the "RefFSContextFactory" class, and my file location for the provider URL.
              I then created the foreign JMS ConnectionFactory, specifying my JNDI name in both the "local" and "remote" fields. I don't know what the difference is between those two. I did NOT enter a value in the "User Name" or "Password" fields. I don't know whether that's an issue.
              I then created the foreign JMS destination. I set the "local" and "remote" JNDI values to the JNDI value I set in the "q" field in JMSAdmin.
              I then defined an app using an MDB, with the "destination-jndi-name" set to the same value I set in the "q" field.
              When I deployed the app, I saw an error message on the console saying that when deploying the EJB module, the JNDI name (that I had specified in the "q" field) could not be found.

    David,
              first you should check, whether the JNDI-Entry is deployed. You can
              check this by displaying the jndi-tree on the weblogic console. to do
              this, right click on the server entry and select "view jndi tree".
              the point with the jndi-tree you entered as "local jndi destination"
              should be violet.
              in the definitions of foreign jms-destinations and connection factories
              you always set:
              remote jndi name: the entry which you made in JMSADMIN
              local jndi name: the jndi entry you want to use inside weblogic.
              hope this helps,
              Klaas
              David Karr schrieb:
              > I'm trying to set up a foreign JMS destination to an MQ queue. There are several steps you have to get right for this to work. I thought I did them all correctly, but when I deploy the app with an MDB that references the JNDI name, it says (in the console) that the destination with the particular JNDI name could not be found.
              >
              > I first used JMSAdmin to create the JNDI data in the provider URL file location. I created the qcf and the queue. I've displayed my results that I set with that, and it all looks fine. One thing that I'm unsure about with this, however, is that the document on using JMSAdmin doesn't make it clear exactly which field in the "queue" definition is the JNDI name, and which is the MQ queue name. My guess is that the value of the "q" field is the JNDI name, and the value of the "queue" field is the MQ queue
              > name. I'm not certain.
              >
              > I then created the foreign JMS info in the WebLogic console. I first created the foreign JMS server, using the "RefFSContextFactory" class, and my file location for the provider URL.
              >
              > I then created the foreign JMS ConnectionFactory, specifying my JNDI name in both the "local" and "remote" fields. I don't know what the difference is between those two. I did NOT enter a value in the "User Name" or "Password" fields. I don't know whether that's an issue.
              >
              > I then created the foreign JMS destination. I set the "local" and "remote" JNDI values to the JNDI value I set in the "q" field in JMSAdmin.
              >
              > I then defined an app using an MDB, with the "destination-jndi-name" set to the same value I set in the "q" field.
              >
              > When I deployed the app, I saw an error message on the console saying that when deploying the EJB module, the JNDI name (that I had specified in the "q" field) could not be found.

  • Foreign JMS and XA

    Hi everybody,
              Is anybody successfully using remote IBM MQseries 5.3 server as
              Foreign JMS in WLS 8.1sp2?
              We're observing some strange behavior in this case. Here is our setup:
              WLS and IBM MQ server deployed on separate boxes.
              WLS version 8.1sp2 running on Windows 2000/Intel
              IBM MQ version 5.3 running on Solaris/SPARC
              We're using "WebSphere MQ classes for Java, version 5.303 - j5303-L030225"
              and "WebSphere MQ Extended Transactional Client Feature, version 5.300 -
              j5303-L030122"
              MQ files added in WLS POST_CLASSPATH variable in WLS starup script.
              Foreign JMS server configured in WLS via fscontext JNDI.
              MDB bean deployed with Transaction attribute "Required".
              Everything seems to work fine, if we're posting message to MQ queue MDB
              receives it and process successfully (just print message content to the
              console for now).
              Problem: In WLS console, under Server->Monitoring->JTA->Monitor inflight
              transactions we can constantly see one transaction enlisted for our MDB
              bean with following details:
              =====================================================
              Transaction ID: BEA1-00DFC5EB4B7B7F28EDB9
              Coordinator: mydomain+myserver
              Name: JMSMessagePoller.xxx.xxx.MyMessageProcessorMdb
              Status: Active
              Seconds Active: 17
              Resources:
              weblogic.ejb20.JMSConnectionPoller.xxx.xxx.MyMessageProcessorMdb=started
              Properties
              (key=value):
              weblogic.transaction.name=JMSMessagePoller.xxx.xxx.MyMessageProcessorMdb
              =====================================================
              This transaction seems to be Active for 30 seconds and then rolled back
              (no error messages on WLS console displayed).On JTA statistics page in
              WLS console "Total Rolled Back" counter keeps increneting with every
              rollback.
              Does anybody observerd similar problem? May be it's normal behaviour but
              I'm kind of worrying about those transactions and constant rollback. I'd
              appreciate any feedback.
              Sincerely,
              Dmitri Maximovich
              

    Hi Dmitri,
              The shutdown "suspend" failure has nothing to do with transactions
              or JMS. It looks like the failure is due to a
              java.util.ConcurrentModificationException during undeployment
              which indicates a bug in WL - something is not getting
              synchronized that should be.
              As for MQ, their new extended client supports remote XA, which I think
              is the reason for the product in the first place. Even so, I
              still recommend testing to make sure that its messages
              participate in transactions. (Actually, I recommend such testing
              for any transactional app, including those built on WL JMS.)
              Tom
              Dmitri Maximovich wrote:
              > Hi Tom,
              >
              > Thanks for info, that's a relief. Unfortunately there is no hints in WLS
              > documentation that it's normal, that's why we were worried about it.
              >
              > Now there is one more issue, which I believe is related. You see with
              > those 'in-flight' transactions graceful shutdown of WLS doesn't quite
              > work. There is suspicious exception thrown and after that WLS is still
              > running in some state but console is not available anymore. Please see
              > console messages attached (sorry for long post). at the time of shutdown
              > there is no messages in the queue(s) so as far as I can tell those
              > 'pending transactions' mentioned is those from foreign JMS wrappers.
              >
              > I'd appreciate any comments on that. We have case opened with BEA about
              > this but so far they cannot reproduce it in their lab. That's why I
              > start wondering if we're doing something wrong here, like using remote
              > MQ server for example, may be you not supposed to (I remember there was
              > an issue before with IBM MQ that XA support required binding mode, I was
              > kind of hope that it's not the case anymore)?
              >
              > <Mar 3, 2004 1:47:56 PM EST> <Notice> <WebLogicServer> <BEA-000365>
              > <Server state changed to SUSPENDING>
              > <Mar 3, 2004 1:47:56 PM EST> <Info> <Deployer> <BEA-149236> <Preparing
              > to suspend.>
              > <Mar 3, 2004 1:47:56 PM EST> <Info> <Deployer> <BEA-149237> <Ready to
              > suspend.>
              > <Mar 3, 2004 1:47:56 PM EST> <Info> <WebService> <BEA-220028> <Web
              > Service reliable agents are suspended.>
              > <Mar 3, 2004 1:47:56 PM EST> <Notice> <JTA> <BEA-110476> <The server has
              > detected pending transactions during graceful shutdown. The server will
              > wait for the pending transactions to complete before suspending the RMI
              > service. A force shutdown command can be issued to shutdown the server
              > immediately.>
              > <Mar 3, 2004 1:48:26 PM EST> <Info> <Management> <BEA-141080> <A request
              > has been received to force shut down of the server.>
              > <Mar 3, 2004 1:48:26 PM EST> <Alert> <WebLogicServer> <BEA-000228> <The
              > disabling of server logins has been requested by <WLS Kernel>>
              > <Mar 3, 2004 1:48:26 PM EST> <Alert> <WebLogicServer> <BEA-000229>
              > <Server logins have been disabled.>
              > <Mar 3, 2004 1:48:26 PM EST> <Info> <WebService> <BEA-220028> <Web
              > Service reliable agents are suspended.>
              > <Mar 3, 2004 1:48:26 PM EST> <Info> <EJB> <BEA-010084> <The
              > message-driven beans are being suspended. This may take a minute or two.>
              > <Mar 3, 2004 1:48:32 PM EST> <Info> <EJB> <BEA-010085> <The
              > message-driven beans have all been suspended.>
              > <Mar 3, 2004 1:48:32 PM EST> <Info> <EJB> <BEA-010084> <The
              > message-driven beans are being suspended. This may take a minute or two.>
              > <Mar 3, 2004 1:48:32 PM EST> <Info> <EJB> <BEA-010085> <The
              > message-driven beans have all been suspended.>
              > [MessageDrivenBeanPoolInfoImpl] : Couldn't unregister MBean
              > javax.management.InstanceNotFoundException:
              > mydomain:ApplicationRuntime=myserver_otis-dasl-ejb,EJBComponentRuntime=myserver_otis-dasl-ejb_otis-dasl-ejb.jar,Location=myserver,Name=myserver_otis-dasl-ejb_otis-dasl-ejb.jar_com.cibcwm.go.otis.dasl.submission.DASLSubmissionMdb_wls.mqs.dasl.dev.adp.reply3,ServerRuntime=myserver,Type=EJBTransactionRuntime
              >
              > at
              > com.sun.management.jmx.MBeanServerImpl.getMBean(MBeanServerImpl.java:1680)
              > at
              > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1524)
              > at
              > weblogic.management.internal.RemoteMBeanServerImpl.private_invoke(RemoteMBeanServerImpl.java:947)
              >
              > at
              > weblogic.management.internal.RemoteMBeanServerImpl.invoke(RemoteMBeanServerImpl.java:908)
              >
              > at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:946)
              > at
              > weblogic.management.internal.MBeanProxy.invokeForCachingStub(MBeanProxy.java:481)
              >
              > at
              > weblogic.management.runtime.EJBTransactionRuntimeMBean_Stub.preDeregister(EJBTransactionRuntimeMBean_Stub.java:433)
              >
              > at
              > weblogic.management.internal.MBeanHomeImpl.internalDeleteMBean(MBeanHomeImpl.java:996)
              >
              > at
              > weblogic.management.internal.MBeanHomeImpl.privateDeleteMBean(MBeanHomeImpl.java:982)
              >
              > at
              > weblogic.management.internal.MBeanHomeImpl.access$000(MBeanHomeImpl.java:74)
              >
              > at
              > weblogic.management.internal.MBeanHomeImpl$2.run(MBeanHomeImpl.java:948)
              > at
              > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              >
              > at
              > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              > at
              > weblogic.management.internal.MBeanHomeImpl.deleteMBeanWithKernelID(MBeanHomeImpl.java:944)
              >
              > at
              > weblogic.management.internal.MBeanHomeImpl.deleteMBean(MBeanHomeImpl.java:939)
              >
              > at
              > weblogic.management.internal.MBeanHomeImpl.deleteMBean(MBeanHomeImpl.java:933)
              >
              > at
              > weblogic.management.runtime.RuntimeMBeanDelegate.unregister(RuntimeMBeanDelegate.java:140)
              >
              > at
              > weblogic.ejb20.monitoring.EJBRuntimeMBeanImpl.unregisterDependents(EJBRuntimeMBeanImpl.java:58)
              >
              > at
              > weblogic.ejb20.monitoring.MessageDrivenEJBRuntimeMBeanImpl.unregisterDependents(MessageDrivenEJBRuntimeMBeanImpl.java:50)
              >
              > at
              > weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.unInitPool(MessageDrivenBeanPoolInfoImpl.java:208)
              >
              > at
              > weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.onUndeploy(MessageDrivenBeanPoolInfoImpl.java:121)
              >
              > at
              > weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.onUndeploy(MessageDrivenBeanInfoImpl.java:628)
              >
              > at weblogic.ejb20.internal.BaseEJBHome.undeploy(BaseEJBHome.java:203)
              > at
              > weblogic.ejb20.internal.MessageDrivenEJBHome.undeploy(MessageDrivenEJBHome.java:260)
              >
              > at
              > weblogic.ejb20.deployer.EJBDeployer.deactivate(EJBDeployer.java:1802)
              > at weblogic.ejb20.deployer.EJBModule.doDeactivate(EJBModule.java:865)
              > at weblogic.ejb20.deployer.EJBModule.deactivate(EJBModule.java:712)
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivateModule(J2EEApplicationContainer.java:3161)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivate(J2EEApplicationContainer.java:2186)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivate(J2EEApplicationContainer.java:2131)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.stop(J2EEApplicationContainer.java:1915)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainerFactory.removeDeployedApplications(J2EEApplicationContainerFactory.java:761)
              >
              > at
              > weblogic.j2ee.J2EEApplicationService.shutdown(J2EEApplicationService.java:115)
              >
              > at
              > weblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.shutdownHelper(DeploymentManagerServerLifeCycleImpl.java:257)
              >
              > at
              > weblogic.application.ApplicationService.prepareToSuspend(ApplicationService.java:46)
              >
              > at
              > weblogic.t3.srvr.SubsystemManager.prepareToSuspend(SubsystemManager.java:168)
              >
              > at weblogic.t3.srvr.T3Srvr.prepareToSuspend(T3Srvr.java:1085)
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread.prepareToSuspend(ServerLifeCycleWorkerThread.java:51)
              >
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread$1.run(ServerLifeCycleWorkerThread.java:35)
              >
              > at
              > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              >
              > at
              > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread.run(ServerLifeCycleWorkerThread.java:32)
              >
              > --------------- nested within: ------------------
              > weblogic.management.ManagementException: An error has occurred during
              > preDeregister().
              > nullmydomain:ApplicationRuntime=myserver_otis-dasl-ejb,EJBComponentRuntime=myserver_otis-dasl-ejb_otis-dasl-ejb.jar,Location=myserver,Name=myserver_otis-dasl-ejb_otis-dasl-ejb.jar_com.cibcwm.go.otis.dasl.submission.DASLSubmissionMdb_wls.mqs.dasl.dev.adp.reply3,ServerRuntime=myserver,Type=EJBTransactionRuntime
              > - with nested exception:
              > [javax.management.InstanceNotFoundException:
              > mydomain:ApplicationRuntime=myserver_otis-dasl-ejb,EJBComponentRuntime=myserver_otis-dasl-ejb_otis-dasl-ejb.jar,Location=myserver,Name=myserver_otis-dasl-ejb_otis-dasl-ejb.jar_com.cibcwm.go.otis.dasl.submission.DASLSubmissionMdb_wls.mqs.dasl.dev.adp.reply3,ServerRuntime=myserver,Type=EJBTransactionRuntime]
              >
              > at
              > weblogic.management.runtime.RuntimeMBeanDelegate.unregister(RuntimeMBeanDelegate.java:148)
              >
              > at
              > weblogic.ejb20.monitoring.EJBRuntimeMBeanImpl.unregisterDependents(EJBRuntimeMBeanImpl.java:58)
              >
              > at
              > weblogic.ejb20.monitoring.MessageDrivenEJBRuntimeMBeanImpl.unregisterDependents(MessageDrivenEJBRuntimeMBeanImpl.java:50)
              >
              > at
              > weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.unInitPool(MessageDrivenBeanPoolInfoImpl.java:208)
              >
              > at
              > weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.onUndeploy(MessageDrivenBeanPoolInfoImpl.java:121)
              >
              > at
              > weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.onUndeploy(MessageDrivenBeanInfoImpl.java:628)
              >
              > at weblogic.ejb20.internal.BaseEJBHome.undeploy(BaseEJBHome.java:203)
              > at
              > weblogic.ejb20.internal.MessageDrivenEJBHome.undeploy(MessageDrivenEJBHome.java:260)
              >
              > at
              > weblogic.ejb20.deployer.EJBDeployer.deactivate(EJBDeployer.java:1802)
              > at weblogic.ejb20.deployer.EJBModule.doDeactivate(EJBModule.java:865)
              > at weblogic.ejb20.deployer.EJBModule.deactivate(EJBModule.java:712)
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivateModule(J2EEApplicationContainer.java:3161)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivate(J2EEApplicationContainer.java:2186)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivate(J2EEApplicationContainer.java:2131)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.stop(J2EEApplicationContainer.java:1915)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainerFactory.removeDeployedApplications(J2EEApplicationContainerFactory.java:761)
              >
              > at
              > weblogic.j2ee.J2EEApplicationService.shutdown(J2EEApplicationService.java:115)
              >
              > at
              > weblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.shutdownHelper(DeploymentManagerServerLifeCycleImpl.java:257)
              >
              > at
              > weblogic.application.ApplicationService.prepareToSuspend(ApplicationService.java:46)
              >
              > at
              > weblogic.t3.srvr.SubsystemManager.prepareToSuspend(SubsystemManager.java:168)
              >
              > at weblogic.t3.srvr.T3Srvr.prepareToSuspend(T3Srvr.java:1085)
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread.prepareToSuspend(ServerLifeCycleWorkerThread.java:51)
              >
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread$1.run(ServerLifeCycleWorkerThread.java:35)
              >
              > at
              > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              >
              > at
              > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread.run(ServerLifeCycleWorkerThread.java:32)
              >
              > <Mar 3, 2004 1:48:33 PM EST> <Info> <Management> <BEA-141082>
              > <ServerRuntime:java.util.ConcurrentModificationException>
              > <Mar 3, 2004 1:48:33 PM EST> <Info> <Management> <BEA-141082>
              > <ServerRuntime:java.util.ConcurrentModificationException
              > at
              > java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:552)
              > at java.util.LinkedList$ListItr.next(LinkedList.java:488)
              > at
              > weblogic.ejb20.deployer.EJBDeployer.deactivate(EJBDeployer.java:1801)
              > at weblogic.ejb20.deployer.EJBModule.doDeactivate(EJBModule.java:865)
              > at weblogic.ejb20.deployer.EJBModule.deactivate(EJBModule.java:712)
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivateModule(J2EEApplicationContainer.java:3161)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivate(J2EEApplicationContainer.java:2186)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivate(J2EEApplicationContainer.java:2131)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.stop(J2EEApplicationContainer.java:1915)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainerFactory.removeDeployedApplications(J2EEApplicationContainerFactory.java:761)
              >
              > at
              > weblogic.j2ee.J2EEApplicationService.shutdown(J2EEApplicationService.java:115)
              >
              > at
              > weblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.shutdownHelper(DeploymentManagerServerLifeCycleImpl.java:257)
              >
              > at
              > weblogic.application.ApplicationService.prepareToSuspend(ApplicationService.java:46)
              >
              > at
              > weblogic.t3.srvr.SubsystemManager.prepareToSuspend(SubsystemManager.java:168)
              >
              > at weblogic.t3.srvr.T3Srvr.prepareToSuspend(T3Srvr.java:1085)
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread.prepareToSuspend(ServerLifeCycleWorkerThread.java:51)
              >
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread$1.run(ServerLifeCycleWorkerThread.java:35)
              >
              > at
              > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              >
              > at
              > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread.run(ServerLifeCycleWorkerThread.java:32)
              >
              > >
              > <Mar 3, 2004 1:48:35 PM EST> <Critical> <WebLogicServer> <BEA-000217>
              > <Failed to fully suspend the server due to:
              > java.util.ConcurrentModificationException
              > java.util.ConcurrentModificationException
              > at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
              > at java.util.HashMap$KeyIterator.next(HashMap.java:818)
              > at
              > weblogic.j2ee.J2EEApplicationContainerFactory.removeDeployedApplications(J2EEApplicationContainerFactory.java:751)
              >
              > at
              > weblogic.j2ee.J2EEApplicationService.shutdown(J2EEApplicationService.java:115)
              >
              > at
              > weblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.shutdownHelper(DeploymentManagerServerLifeCycleImpl.java:257)
              >
              > at
              > weblogic.application.ApplicationService.forceSuspend(ApplicationService.java:82)
              >
              > at
              > weblogic.t3.srvr.SubsystemManager.forceSuspend(SubsystemManager.java:184)
              > at weblogic.t3.srvr.T3Srvr.forceSuspend(T3Srvr.java:1097)
              > at
              > weblogic.t3.srvr.ServerRuntime.uprotectedForceShutdown(ServerRuntime.java:629)
              >
              > at weblogic.t3.srvr.ServerRuntime.access$300(ServerRuntime.java:83)
              > at weblogic.t3.srvr.ServerRuntime$4.run(ServerRuntime.java:563)
              > at
              > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              >
              > at
              > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              > at weblogic.t3.srvr.ServerRuntime.forceShutdown(ServerRuntime.java:559)
              > at weblogic.t3.srvr.ServerRuntime.shutdown(ServerRuntime.java:547)
              > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              > at
              > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
              >
              > at
              > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
              >
              > at java.lang.reflect.Method.invoke(Method.java:324)
              > at
              > weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:711)
              >
              > at
              > weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:690)
              >
              > at
              > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1557)
              > at
              > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1525)
              > at
              > weblogic.management.internal.RemoteMBeanServerImpl.private_invoke(RemoteMBeanServerImpl.java:947)
              >
              > at
              > weblogic.management.internal.RemoteMBeanServerImpl.invoke(RemoteMBeanServerImpl.java:908)
              >
              > at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:946)
              > at
              > weblogic.management.internal.MBeanProxy.invokeForCachingStub(MBeanProxy.java:481)
              >
              > at
              > weblogic.management.runtime.ServerRuntimeMBean_Stub.shutdown(ServerRuntimeMBean_Stub.java:1184)
              >
              > at
              > weblogic.server.ServerLifeCycleRuntime$ShutdownRequest.execute(ServerLifeCycleRuntime.java:585)
              >
              > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
              > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              > >
              > <Mar 3, 2004 1:48:35 PM EST> <Debug> <Management> <BEA-141132> <Dynamic
              > invocation while executing action shutdown on
              > mydomain:Location=myserver,Name=myserver,Type=ServerRuntime MBean
              > instance failed. The method shutdown with signature [int, boolean] was
              > invoked with parameters as [30, true].
              > java.util.ConcurrentModificationException
              > at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
              > at java.util.HashMap$KeyIterator.next(HashMap.java:818)
              > at
              > weblogic.j2ee.J2EEApplicationContainerFactory.removeDeployedApplications(J2EEApplicationContainerFactory.java:751)
              >
              > at
              > weblogic.j2ee.J2EEApplicationService.shutdown(J2EEApplicationService.java:115)
              >
              > at
              > weblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.shutdownHelper(DeploymentManagerServerLifeCycleImpl.java:257)
              >
              > at
              > weblogic.application.ApplicationService.forceSuspend(ApplicationService.java:82)
              >
              > at
              > weblogic.t3.srvr.SubsystemManager.forceSuspend(SubsystemManager.java:184)
              > at weblogic.t3.srvr.T3Srvr.forceSuspend(T3Srvr.java:1097)
              > at
              > weblogic.t3.srvr.ServerRuntime.uprotectedForceShutdown(ServerRuntime.java:629)
              >
              > at weblogic.t3.srvr.ServerRuntime.access$300(ServerRuntime.java:83)
              > at weblogic.t3.srvr.ServerRuntime$4.run(ServerRuntime.java:563)
              > at
              > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              >
              > at
              > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              > at weblogic.t3.srvr.ServerRuntime.forceShutdown(ServerRuntime.java:559)
              > at weblogic.t3.srvr.ServerRuntime.shutdown(ServerRuntime.java:547)
              > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              > at
              > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
              >
              > at
              > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
              >
              > at java.lang.reflect.Method.invoke(Method.java:324)
              > at
              > weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:711)
              >
              > at
              > weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:690)
              >
              > at
              > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1557)
              > at
              > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1525)
              > at
              > weblogic.management.internal.RemoteMBeanServerImpl.private_invoke(RemoteMBeanServerImpl.java:947)
              >
              > at
              > weblogic.management.internal.RemoteMBeanServerImpl.invoke(RemoteMBeanServerImpl.java:908)
              >
              > at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:946)
              > at
              > weblogic.management.internal.MBeanProxy.invokeForCachingStub(MBeanProxy.java:481)
              >
              > at
              > weblogic.management.runtime.ServerRuntimeMBean_Stub.shutdown(ServerRuntimeMBean_Stub.java:1184)
              >
              > at
              > weblogic.server.ServerLifeCycleRuntime$ShutdownRequest.execute(ServerLifeCycleRuntime.java:585)
              >
              > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
              > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              > >
              >
              > Tom Barnes wrote:
              >
              >> Hi Dmitri,
              >>
              >> This is normal behavior.
              >> The internal rollbacks are a side effect of WL MDBs
              >> necessarily starting a transaction before they (internally)
              >> post a synchronous
              >> receive on the remote foreign JMS server. If the synchronous receive
              >> receives nothing, the tx is rolled back, and another
              >> synch receive is posted with a new tx. (When interacting with
              >> foreign vendors, tx MDBs usually must post synchronous receives
              >> in order to infect the received message - there is no
              >> standard JMS API for infecting asynchronously received messages
              >> with a user transaction.)
              >>
              >> Tom
              >>
              >> Dmitri Maximovich wrote:
              >>
              >>> Hi everybody,
              >>>
              >>> Is anybody successfully using remote IBM MQseries 5.3 server as
              >>> Foreign JMS in WLS 8.1sp2?
              >>> We're observing some strange behavior in this case. Here is our setup:
              >>>
              >>> WLS and IBM MQ server deployed on separate boxes.
              >>> WLS version 8.1sp2 running on Windows 2000/Intel
              >>> IBM MQ version 5.3 running on Solaris/SPARC
              >>>
              >>> We're using "WebSphere MQ classes for Java, version 5.303 -
              >>> j5303-L030225"
              >>> and "WebSphere MQ Extended Transactional Client Feature, version
              >>> 5.300 - j5303-L030122"
              >>>
              >>> MQ files added in WLS POST_CLASSPATH variable in WLS starup script.
              >>>
              >>> Foreign JMS server configured in WLS via fscontext JNDI.
              >>>
              >>> MDB bean deployed with Transaction attribute "Required".
              >>>
              >>> Everything seems to work fine, if we're posting message to MQ queue
              >>> MDB receives it and process successfully (just print message content
              >>> to the console for now).
              >>>
              >>> Problem: In WLS console, under Server->Monitoring->JTA->Monitor
              >>> inflight transactions we can constantly see one transaction enlisted
              >>> for our MDB bean with following details:
              >>>
              >>> =====================================================
              >>> Transaction ID: BEA1-00DFC5EB4B7B7F28EDB9
              >>> Coordinator: mydomain+myserver
              >>> Name: JMSMessagePoller.xxx.xxx.MyMessageProcessorMdb
              >>> Status: Active
              >>> Seconds Active: 17
              >>> Resources:
              >>> weblogic.ejb20.JMSConnectionPoller.xxx.xxx.MyMessageProcessorMdb=started
              >>> Properties
              >>> (key=value):
              >>> weblogic.transaction.name=JMSMessagePoller.xxx.xxx.MyMessageProcessorMdb
              >>> =====================================================
              >>>
              >>> This transaction seems to be Active for 30 seconds and then rolled
              >>> back (no error messages on WLS console displayed).On JTA statistics
              >>> page in WLS console "Total Rolled Back" counter keeps increneting
              >>> with every rollback.
              >>>
              >>> Does anybody observerd similar problem? May be it's normal behaviour
              >>> but I'm kind of worrying about those transactions and constant
              >>> rollback. I'd appreciate any feedback.
              >>>
              >>> ---
              >>> Sincerely,
              >>> Dmitri Maximovich
              >>
              >>
              >>
              

  • MDB behavior with Foreign JMS Provider

              I am experiencing some MDB behavior which I do not quite understand. I would appreciate
              if someone could tell me what might be happening.
              An application on WebLogic 8.1 SP1 (also tried it with SP2) has MDB's which listen
              on a MQ Queue. If I put a large XML message on the MQ Queue (say around 600 KB),
              the onMessage execution is very random, For the large messages only 1 MDB gets
              invoked and the other messages just sit on the MQ Queue. Even though I have defined
              an weblogic execute queue for the MDB's and they have 15 threads allocated.
              The other messages get picked up after the first one gets completed. The problem
              is the whole transaction (which is XA) can take a while (upto 10 minutes). This
              is not intended, but for some reason it takes that long.
              Also, while monitoring the MDB execute queues, I noticed that none of the threads
              from that queue are performing the work and a thread dump shows that the weblogic.ejb20.internal.JMSPoller
              thread has invoked the MDB and is currently waiting for the database to finish
              some processing.
              When the message size is smaller, the MDB's fire concurrently and are executed
              on the MDB execute queue.
              Thanks,
              Ketan.
              

    When we're using MDBs against a foreign JMS provider with XA, the EJB
              container tries to reduce the number of threads that are blocked waiting for
              a message. You should see lots of threads working when there are lots of
              messages on the queue, a few threads (or only one) working when the queue is
              empty or nearly so, and there should be some ramp-up and ramp-down time in
              between. It sounds like the ramp-up takes longer in your case because
              receiving the very first message takes a long time.
              If this behavior is causing big problems for you, you might want to contact
              product support and file an enhancement request.
              greg
              "Ketan" <[email protected]> wrote in message
              news:[email protected]...
              >
              > Here is some more information regarding this issue.
              >
              > When I place sufficiently large messages (such that the parsing and
              processing
              > of these messages takes longer than it does for normal size messages), I
              notice
              > the following behavior.
              >
              > Lets say I put 6 large messages on the MQ Queue. The server immediately
              picks
              > up 1 message and starts processing it. The other 5 messages are sitting on
              the
              > MQ Queue, while the MDB execute queue has all 15 idle threads.
              >
              > After the processing of the message is done, 2 messages get picked up.
              This time,
              > 1 thread in the MDB execute queue gets the message and the other is
              processed
              > by the JMSPoller thread. After these 2 messages are processed, 3 Messages
              get
              > picked up and this time 2 messages are on the MDB execute queue and 1 is
              processed
              > by the JMSPoller.
              >
              > So based on this the question is ..Is this the expected behavior? I was
              under
              > the impression that the poller would simply dispatch messages to the
              execute queue,
              > and as a result, I was expecting all the messages would get picked up from
              the
              > MQ queue pretty fast and would not have to wait for 1 or more MDB's to
              finish
              > processing.
              >
              > I would really appreciate any suggestions anyone may have for me.
              >
              > Again the environment is WLS 8.1 SP2, MQ 5.3
              >
              > thanks,
              > Ketan
              

  • [EJB:010112] - error with WLI8.1 Event Generator for foreign JMS/MQ provider

    I'm getting following error in weblogic server log when starting a JMS Event generator
    to a foreign JMS(MQ5.3) Queue.
    <May 4, 2004 4:44:35 PM PDT> <Warning> <EJB> <BEA-010096> <The Message-Driven
    EJ
    B: mqQueueEventGen is unable to connect to the JMS destination: WAL1021852D_Test
    JMSQueue. Connection failed after 2 attempts. The MDB will attempt to reconnect
    every 10 seconds. This log message will repeat every 600 seconds until the condi
    tion clears.>
    <May 4, 2004 4:44:35 PM PDT> <Warning> <EJB> <BEA-010061> <The Message-Driven
    EJ
    B: mqQueueEventGen is unable to connect to the JMS destination: WAL1021852D_Test
    JMSQueue. The Error was:
    [EJB:010112]The Message Driven Bean 'mqQueueEventGen' is transacted, but the pro
    vider defined in the EJB is not transacted. Provider should be transacted if onM
    essage method in MDB is transacted.>
    My WLI8.1.2 is patched with CR131686_812.zip to support event generator for foreign
    JMS destinations. The foreign JMS/MQ provider is configured properly. QueueSend/Receive
    were tested fine with JMS java code using local JNDI names of foreign JMS objects.
    So we know that foreign Queue is active and accessiable from webLogic.
    Anyone run into this? Solution?
    Thanks,
    Scott

    Hi Scott,
    I need a transaction from the MDB since I am not using an EJb to pursue the action.
    Hence I need to retain the <trans-attribute>Required</trans-attribute> at the
    MDB.
    Have any answers?
    Pradip
    "Scott Yen" <[email protected]> wrote:
    >
    It's resolved.
    The MDB automatically created by JMS Event Generator defaults to be deployed
    with
    “transacted”. That requires the foreign JMS provider to be “XA”.
    The deployment descriptor is created as <domain-directory>/WLIJmsEG_<event_gen_name>.jar
    e.g. C:\bea812\user_projects\domains\jmsInterop\WLIJmsEG_mqQueueEventGen.jar
    Since MQ in the localhost and remote SLUDV18 are not XA-enabled, we had
    to manually
    change the <container-transaction> section in ejb-jar.xml:
    From :
    <trans-attribute>Required</trans-attribute>
    To:
    <trans-attribute>NotSupported</trans-attribute>
    "Scott Yen" <[email protected]> wrote:
    I'm getting following error in weblogic server log when starting a JMS
    Event generator
    to a foreign JMS(MQ5.3) Queue.
    <May 4, 2004 4:44:35 PM PDT> <Warning> <EJB> <BEA-010096> <The Message-Driven
    EJ
    B: mqQueueEventGen is unable to connect to the JMS destination: WAL1021852D_Test
    JMSQueue. Connection failed after 2 attempts. The MDB will attempt to
    reconnect
    every 10 seconds. This log message will repeat every 600 seconds until
    the condi
    tion clears.>
    <May 4, 2004 4:44:35 PM PDT> <Warning> <EJB> <BEA-010061> <The Message-Driven
    EJ
    B: mqQueueEventGen is unable to connect to the JMS destination: WAL1021852D_Test
    JMSQueue. The Error was:
    [EJB:010112]The Message Driven Bean 'mqQueueEventGen' is transacted,
    but the pro
    vider defined in the EJB is not transacted. Provider should be transacted
    if onM
    essage method in MDB is transacted.>
    My WLI8.1.2 is patched with CR131686_812.zip to support event generator
    for foreign
    JMS destinations. The foreign JMS/MQ provider is configured properly.
    QueueSend/Receive
    were tested fine with JMS java code using local JNDI names of foreign
    JMS objects.
    So we know that foreign Queue is active and accessiable from webLogic.
    Anyone run into this? Solution?
    Thanks,
    Scott

  • Foreign JMS vs. Remote MDB

    Hi,
              I have a JMS scenario that I'm hoping to get some input on. The system architecture is as follows:
              One WebLogic 8.1 SP5 domain with a JMS server
              One WebLogic 9.2 MP1 domain with no JMS server
              We'd like to consume a JMS message that's sitting on a queue in the 8.1 domain by code running on the 9.2 domain.
              Without configuring a JMS server in the 9.2 domain (which we'd like to avoid), the two obvious options are:
              1. An MDB running on the 9.2 server that connects to a queue on the 8.1 server
              2. An MDB running on the 9.2 server that connects to a foreign JMS server locally which in turn is linked to the 8.1's JMS server
              Does anyone have any suggestions, experience from this or a similar scenario?
              The main areas that I'd be interested in are:
              - Inter domain compatability
              - Any problems with Transactions, XA
              Many thanks,
              Eoin

    Hi,
              I think your approach is fine - inter-version compatibility is supported for both JMS and XA. You'll need to ensure that all 9.1 and 8.1 WL domain names are unique, ditto for all 8.1 WL server names, 8.1 WL store names, plus 8.1 JMS server names (even across different domains).
              "1" and "2" are essentially the same in that "Foreign JMS" is simply a mapping from the local JNDI naming service to a remote JMS service . "2" tends to be preferable as it can simplify administration once configured. For more information, see the "Integrating Remote JMS Providers" FAQ linked off of this page: "http://edocs.bea.com/wls/docs92/messaging.html".
              FYI There are advantages in using 9.x and later JMS - not only does it have a broader set of features, but it also has more sophisticated message management (use the console to pause/resume dests, view individual messages, etc), and significantly higher performance. Also, 9.x MDBs do a better job of connecting to remote 9.x distributed destinations than 8.1 MDBs - as they automatically ensure that all component destinations get serviced.
              Tom

  • Foreign JMS server connection issue.

    Hi All,
    We are migrating a JMS application from websphere 6.1 to weblogic 10.3. The message queue resides in a TIBCO EMS server.
    We are trying to configure the foreign JMS server through JMS Module in the admin console. We are getting the following error will deploying the application.
    +<May 4, 2009 12:32:52 AM PDT> <Warning> <EJB> <BEA-010061> <The Message-Driven EJB: TxnMessageSubscriber is unable to connect to the JMS destination: weblogic.bbmdb-txn.jms/system+
    module-0-jms.xml. The Error was:
    Can not get distribute destination information. The destination JNDI name is weblogic.bbmdb-txn.jms/systemmodule-0-jms.xml, the provider URL is null>
    we have provided the connection URL in "JNDI Connection URL" column in the foreign server setup page.
    Is there any other thing that need to be configured?

    I m facing the same problem, we are using Weblogic Server 10.3.
    We have defined a cluster on one Weblogic server and have created one managed server in the cluster machine and the other managed server in another machine.
    We are using Foreign JMS and I m getting the error as follow:
    ####<Jun 19, 2009 3:30:53 PM IST> <Warning> <EJB> <iflexpkw513> <Managed1> <[STANDBY] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1245405653881> <BEA-010061> <The Message-Driven EJB: TestJMSALSB is unable to connect to the JMS destination: fcssi/FCSSI. The Error was:
    Can not get distribute destination information. The destination JNDI name is fcssi/FCSSI, the provider URL is null>
    Not able to understand what is the problem here...
    ejb-jar.xml :
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
    <ejb-jar id="ejb-jar_ID">
    <enterprise-beans>
    <message-driven>
    <ejb-name>TestJMSALSB</ejb-name>
    <ejb-class>samplemdb.TestJMSALSB</ejb-class>
    <transaction-type>Container</transaction-type>
    <message-driven-destination id="MessageDrivenDestination_1169302343246">
         <destination-type>javax.jms.Queue</destination-type>
    </message-driven-destination>
    </message-driven>
    </enterprise-beans>
    </ejb-jar>
    weblogic-ejb-jar.xml :
    <?xml version="1.0" encoding="UTF-8"?>
    <weblogic-ejb-jar
    xmlns="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">
    <weblogic-enterprise-bean>
    <ejb-name>TestJMSALSB</ejb-name>
    <message-driven-descriptor>
    <destination-jndi-name>fcssi/FCSSI</destination-jndi-name>
    <connection-factory-jndi-name>iflex/fcssiQCF</connection-factory-jndi-name>
    </message-driven-descriptor>
    </weblogic-enterprise-bean>
    </weblogic-ejb-jar>
    Can anyone provide some help on this.....

  • MDB for Foreign JMS server

    I am trying to access MQ que with Message Driven bean in weblogic 8.1.
              I have defined Foreign JMS server in weblogic pointing to MQ JNDI name.
              I am not sure what to define in "weblogic-ejb-jar.xml" and "ejb-jar.xml" to refer to que connection factory and que.
              Error message that I am getting while deploying is as follows:
              <The Message-Driven EJB: MesssageHandlerBean is unable to connect to the JMS destination: jms.MediaQueue. The Error was:
              [EJB:011010]The JMS destination with the JNDI name: jms.MediaQueue could not be found. Please ensure that the JNDI name in the weblogic-ejb-jar.xml is correct, and the JMS destination has been deployed.>
              Looks like it weblogic is not able to identify JNDI name that I have defined in foreign server for remote que.
              Please let me know how i can reference foreign JMS server JNDI names.
              Thanks a bunch for help.
              Please find attached configuration files.
              weblogic-ejb-jar.xml
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>MesssageHandlerBean</ejb-name>
              <message-driven-descriptor>
              <destination-jndi-name>
              jms.MediaQueue
              </destination-jndi-name>
              <initial-context-factory>
              com.sun.jndi.fscontext.RefFSContextFactory
              </initial-context-factory>
              <provider-url>file://localhost/d:/mqm</provider-url>
              <connection-factory-jndi-name>
              jms.MediaQcf
              </connection-factory-jndi-name>
              </message-driven-descriptor>
              <jndi-name>MesssageHandlerBean</jndi-name>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              ejb-jar.xml
              <enterprise-beans>      
              <message-driven>
              <ejb-name>MesssageHandlerBean</ejb-name>
              <ejb-class>com.ejb.MesssageHandlerBean</ejb-class>
              <transaction-type>Container</transaction-type>
              <message-driven-destination>
              <destination-type>javax.jms.Queue</destination-type>
              </message-driven-destination>
              </message-driven>
              </enterprise-beans>
              weblogic "config.xml" for foeign JMS server.
              <ForeignJMSServer ConnectionURL="file://localhost/d:/mqm" InitialContextFactory="com.sun.jndi.fscontext.RefFSContextFactory"
              JNDIProperties="" Name="MQJMS Server" Targets="cgServer">
              <ForeignJMSConnectionFactory LocalJNDIName="jms.MediaQcf"
              Name="MQ JMS Connection Factory" PasswordEncrypted=""
              RemoteJNDIName="jms/lMediaQcf" Username=""/>
              <ForeignJMSDestination LocalJNDIName="jms.MediaQueue"
              Name="MQJMS Destination" RemoteJNDIName="jms/IMediaQueue"/>
              </ForeignJMSServer>
              Message was edited by:
              [email protected]
              Message was edited by:
              [email protected]

    Thanks for going over the problem it is resolved now by changing weblogic-ejb-jar.xml. To point to weblogic initial context factory. Since weblogic has a foreign server defined so MDB is able to read from MQ que.
              Thanks
              Akash
              <weblogic-enterprise-bean> <ejb-name>MesssageHandlerBean</ejb-name> <message-driven-descriptor> <destination-jndi-name>jms.MediaQueue</destination-jndi-name> <initial-context-factory> weblogic.jndi.WLInitialContextFactory</initial-context-factory> <provider-url>t3://localhost:7001</provider-url> <connection-factory-jndi-name>jms.MediaQcf</connection-factory-jndi-name> </message-driven-descriptor> <jndi-name>MesssageHandlerBean</jndi-name> </weblogic-enterprise-bean>

  • MDB problem with Foreign JMS MQ

    Hi,
    I have MDB 2.1 and i am trying to deploy in weblogic 10.2 app server. Below is my ejb-jar.xml and weblogic.jar xml config. I have a foreign JMS configured and i have destination and connection factory configured too. I was able to post a message to the queue successfully, but my MDB is not getting executed I am getting below exception during the startup of application. I can see other EJBs in the JNDI but not my MDBs. Please advice and your help is very much appreciated.
    Warning Message:
    <Jun 1, 2010 10:24:04 AM CDT> <Warning> <EJB> <BEA-010061> <The Message-Driven EJB: IFIPNCDistributorMDB is unable to connect to the JMS destination: jms/MyQueue. The Error was:
    Can not get distribute destination information. The destination JNDI name is jms/MyQueue, the provider URL is file:/C:/JNDI-Directory>
    weblogic-ejb-jar.xml
    <weblogic-enterprise-bean>
    <ejb-name>MDB</ejb-name>
    <message-driven-descriptor>
    <pool>
    <max-beans-in-free-pool>4</max-beans-in-free-pool>
    <initial-beans-in-free-pool>4</initial-beans-in-free-pool>
    </pool>
    <destination-jndi-name>jms/IFIPNCQueue</destination-jndi-name>
    <initial-context-factory>com.sun.jndi.fscontext.RefFSContextFactory</initial-context-factory>
    <provider-url>file:/C:/JNDI-Directory</provider-url>
    <connection-factory-jndi-name>jms/MyQCF</connection-factory-jndi-name>
    </message-driven-descriptor>
    <reference-descriptor>
    <resource-description>
    <res-ref-name>MyQCF</res-ref-name>
    <jndi-name>jms/MyQCF</jndi-name>
    </resource-description>
    <resource-description>
    <res-ref-name>MyQueue</res-ref-name>
    <jndi-name>jms/MyQueue</jndi-name>
    </resource-description>
    </reference-descriptor>
    <jndi-name>MDB</jndi-name>
    </weblogic-enterprise-bean>
    ejb-jar.xml
    <message-driven id="MDB">
                   <ejb-name>MDB</ejb-name>
                   <ejb-class>com.IFIPNCDistributorMDB</ejb-class>               
                   <transaction-type>Bean</transaction-type>               
                   <message-driven-destination>
                        <destination-type>javax.jms.Queue</destination-type>
                   </message-driven-destination>
                   <resource-ref>
              <res-ref-name>jms/QCF</res-ref-name>
              <res-type>javax.jms.QueueConnectionFactory</res-type>
              <res-auth>Application</res-auth>
              <res-sharing-scope>Unshareable</res-sharing-scope>
         </resource-ref>
         <resource-ref>
              <res-ref-name>jms/MyQueue</res-ref-name>
              <res-type>javax.jms.Queue</res-type>
              <res-auth>Application</res-auth>
              <res-sharing-scope>Unshareable</res-sharing-scope>
              </resource-ref>
              </message-driven>
    Thank You,
    VJ

    Can you setup as in this example:
    Foreign JMS_
    <foreign-server name=”ForeignServer”>
    <default-targeting-enabled>true</default-targeting-enabled>
    <foreign-destination name=”A”>
    <local-jndi-name>A</local-jndi-name>
    <remote-jndi-name>queue/A</remote-jndi-name>
    </foreign-destination>
    <foreign-connection-factory name=”FConf”>
    <local-jndi-name>FConf</local-jndi-name>
    <remote-jndi-name>ConnectionFactory</remote-jndi-name>
    <username>esbuser</username>
    <password-encrypted>{3DES}90sIZwo6Llr9r73p+VXkvQ==</password-encrypted>
    </foreign-connection-factory>
    <initial-context-factory>com.sun.jndi.fscontext.RefFSContextFactory</initial-context-factory>
    <connection-url>file:/C:/JNDI-Directory</connection-url>
    </foreign-server>
    weblogic-ejb-jar.xml_
    <?xml version=’1.0′ encoding=’UTF-8′?>
    <web:weblogic-ejb-jar xmlns:web=”http://www.bea.com/ns/weblogic/weblogic-ejb-jar”>
    <web:weblogic-enterprise-bean>
    <web:ejb-name>RequestEJB-2518965873970113789–2352f820.127bd3f293c.-7fdb</web:ejb-name>
    <web:message-driven-descriptor>
    <web:pool>
    <web:max-beans-in-free-pool>1000</web:max-beans-in-free-pool>
    <web:initial-beans-in-free-pool>1</web:initial-beans-in-free-pool>
    </web:pool>
    <web:destination-jndi-name>A</web:destination-jndi-name>
    <web:connection-factory-jndi-name>FConf</web:connection-factory-jndi-name>
    </web:message-driven-descriptor>
    <web:transaction-descriptor>
    <web:trans-timeout-seconds>600</web:trans-timeout-seconds>
    </web:transaction-descriptor>
    <web:resource-description>
    <web:res-ref-name>jms/ConnectionFactory</web:res-ref-name>
    <web:jndi-name>FConf</web:jndi-name>
    </web:resource-description>
    <web:resource-description>
    <web:res-ref-name>jms/QueueName</web:res-ref-name>
    <web:jndi-name>A</web:jndi-name>
    </web:resource-description>
    </web:weblogic-enterprise-bean>
    </web:weblogic-ejb-jar>
    Note, local JNDI names in the foreign jms server should be used for destination-jndi and conection-factory-jndi. No need to specify provider URL in deployment descriptors. Instead it is specified at the foreign jms setup.
    Also you should use the same resource-reference names in both ejb-jar & weblogic-ejb-jar.xml's., In above example resource-reference section of ejb-jar should look like:
    <resource-ref>
    <res-ref-name>jms/ConnectionFactory</res-ref-name>
    <res-type>javax.jms.QueueConnectionFactory</res-type>
    <res-auth>Application</res-auth>
    <res-sharing-scope>Unshareable</res-sharing-scope>
    </resource-ref>
    <resource-ref>
    <res-ref-name>jms/QueueName</res-ref-name>
    <res-type>javax.jms.Queue</res-type>
    <res-auth>Application</res-auth>
    <res-sharing-scope>Unshareable</res-sharing-scope>
    </resource-ref>

  • Foreign JMS Server Persistance\Retry in case Remote JMS Provider goes down

    Hi All
    I would need more clarity on this. How does the Foreign JMS Server behave in case the remote JMS provider goes down. Does it take the message from the Publishing Proxy Service and retries\persists the JMS Message till the remote provide is up?
    Please let us know. This would effect our design as retrial is very important here. Thanks

    If you want to provide guaranteed delivery with automatic retries when using remote JMS implementations, there are multiple ways to implement it:
    1. While reading from a foreign JMS destination
    Create a Foreign JMS server using transactional drivers (use XA in case of JMS). The messages remain on remote server JMS queue and OSB proxy polls the message directly on remote server. So if Remote Server is down OSB will not be able to read the message. Once remote server is up OSB will pick up the message (as long as foreign JMS server provides persistence and maintains the messages in the queue during a server restart). In case of error in OSB foreign queue can do retry if it provides a retry mechanism.
    2. While writing the message to a foreign JMS destination
    a. Use a foreign JMS server using transactional connection. Put the retry mechanism in OSB Business service which writes to the foreign JMS/MQ queue. In case of failure Business Service can retry based on configuration. If you want to provide guaranteed delivery then create a local JMS queue to store the messages. So when remote destination is down for a long time undelivered messages will be rolled back to the local queue. You can put retry mechanism on the local queue.
    b. Use a messaging bridge which will write the messages to the remote destination. You can configure retry delivery rules in messaging bridge so once busienss service writes the message to the bridge, a SAF agent will ensure the delivery to remote destination whenever it is up.

Maybe you are looking for

  • Open Docs while period end closing..

    Hi All, I just need to knw that,  is it necessary that while performing the period end closing all the documents (sales and purchase) need to be closed.? what if i have a no of purchase and sales orders open.

  • Getting only one coloum in alv grid

    hi ,      i m facing a very strange problem. in my report i m getting exect data in my final table but when i m going to show it, it is showing only first coloum. well problem is coming in field catalog merge, it is not appending the whole coloum hea

  • How to Handle Special Characters in PI7.1

    Hi Team, I need to handle some special characters like <,>,& etc.. from WS Adapter to CRM in PI 7.1. http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/9420 [original link is broken] By using the above blog i had implemented the Java Code as public

  • Deployment '18600003' to target 'Production' encountered a system level dep

    Hi Experts, Please help me in resolving the error while i am doing full deployment from BCC to staging / production server instances , i am getting below error. It would be great if u help me resolving this error. <Dec 5, 2012 1:48:26 AM PST> <Notice

  • N95 crashes when reconnecting BT handsfree device

    Hi Everyone... i've been using the N95 since early Apr and the problem starts about 1.5months ago.. the phone used to hangs and restarts itself 3-4 times a day when i answer a call, but off late, it's been restarting once i re-connect my BT handsfree