Deploying MDB in a cluster...

Have any one been successful at deploying a Message Driven Bean in a
          cluster. The problem I am running in to is that on the second machine the
          MDB tries to deploy but does not find the name of the queue in the JNDI
          space. This is due to the fact that the JNDI replication has not occured
          when the second server is starting up. Later, when the JNDI replication has
          occured, the queue name DOES appear in the JNDI tree, but it's too late for
          the MDB which failed to deploy.
          Has any one gotten around this problem? Surely, there must be someone out
          there who is also trying to deploy MDB in a cluster.
          Thanks.
          -AP_
          

Have any one been successful at deploying a Message Driven Bean in a
          cluster. The problem I am running in to is that on the second machine the
          MDB tries to deploy but does not find the name of the queue in the JNDI
          space. This is due to the fact that the JNDI replication has not occured
          when the second server is starting up. Later, when the JNDI replication has
          occured, the queue name DOES appear in the JNDI tree, but it's too late for
          the MDB which failed to deploy.
          Has any one gotten around this problem? Surely, there must be someone out
          there who is also trying to deploy MDB in a cluster.
          Thanks.
          -AP_
          

Similar Messages

  • MDB in a Cluster using Local JMS Queue (not distributed)

              Can I create a MDB that receives messages from a Local JMS Queue (created on each
              node) rather than a distributed queue?
              When I try to deploy such an MDB I get the following exception:
              weblogic.management.DeploymentException: Exception:weblogic.management.ApplicationException:
              activate failed for TestLocalMDBCluster Module: TestLocalMDBCluster Error: Exception
              activating module: EJBModule(TestLocalMDBCluster,status=PREPARED) Unable to deploy
              EJB: AsyncProcessor from TestLocalMDBCluster.jar: [EJB:011046]Unable to create
              EJBRuntimeMBean. javax.management.InstanceAlreadyExistsException: mydomain:ApplicationRuntime=Node2_TestLocalMDBCluster,EJBComponentRuntime=Node2_TestLocalMDBCluster_TestLocalMDBCluster,Location=Node2,Name=Node2_TestLocalMDBCluster_TestLocalMDBCluster_AsyncProcessor_jms/myserver,ServerRuntime=Node2,Type=MessageDrivenEJBRuntime
              at com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134)
              at com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.java:2371)
              at com.sun.management.jmx.MBeanServerImpl.registerMBean(MBeanServerImpl.java:876)
              at weblogic.management.internal.RemoteMBeanServerImpl.private_registerMBean(RemoteMBeanServerImpl.java:582)
              at weblogic.management.internal.RemoteMBeanServerImpl.registerMBean(RemoteMBeanServerImpl.java:524)
              at weblogic.management.runtime.RuntimeMBeanDelegate.register(RuntimeMBeanDelegate.java:166)
              at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:122)
              at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:85)
              at weblogic.ejb20.monitoring.EJBRuntimeMBeanImpl.<init>(EJBRuntimeMBeanImpl.java:33)
              at weblogic.ejb20.monitoring.MessageDrivenEJBRuntimeMBeanImpl.<init>(MessageDrivenEJBRuntimeMBeanImpl.java:30)
              at weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.initPool(MessageDrivenBeanPoolInfoImpl.java:182)
              at weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.activate(MessageDrivenBeanPoolInfoImpl.java:245)
              at weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.activatePoolInfo(MessageDrivenBeanInfoImpl.java:474)
              at weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.deploy(MessageDrivenBeanInfoImpl.java:440)
              at weblogic.ejb20.deployer.EJBDeployer.activate(EJBDeployer.java:1327) at weblogic.ejb20.deployer.EJBModule.activate(EJBModule.java:610)
              at weblogic.j2ee.J2EEApplicationContainer.activateModule(J2EEApplicationContainer.java:3127)
              at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:2081)
              at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:2062)
              at weblogic.management.deploy.slave.SlaveDeployer$ComponentActivateTask.activateContainer(SlaveDeployer.java:2592)
              at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.doCommit(SlaveDeployer.java:2515)
              at weblogic.management.deploy.slave.SlaveDeployer$Task.commit(SlaveDeployer.java:2317)
              at weblogic.management.deploy.slave.SlaveDeployer.commitUpdate(SlaveDeployer.java:608)
              at weblogic.drs.internal.SlaveCallbackHandler$2.execute(SlaveCallbackHandler.java:35)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              Is there any way to do this?
              

    I assume you are using queues.
              I truly wonder what you are doing different. Since the
              error is occuring outside of JMS and in the EJB - before JMS is called -
              I suggest posting to the ejb newsgroup.
              Note that yours is a standard use case which distributed destinations
              are actually specifically designed for (if you
              are using customer connection factories, just
              make sure ServerAffinity is enabled on the connection factory to
              ensure that clients always connect to the local physical destination,
              configure the MDB to refer to the JNDI name of the distributed
              destination, and then target the MDB to the cluster - an MDB pool
              will then automatically be dedicated to each physical destination).
              Tom
              Mark Colwell wrote:
              > Nope. It happens every time we try the scenario no matter what the application
              > is or which cluster. It always happens if we try to deploy even just a single
              > MDB (no other beans in the jar) to a cluster where the queue specified in the
              > deployment descripter is a local queue created on each node in the cluster. When
              > the jar is deployed we get the error.
              >
              > We have a strange situation were we really need the queue to be local and not
              > distributed but existing on every node. We can create all the local queues no
              > problem but trying to then deploy the application goes boom.
              >
              > Thanks for the response!
              >
              > Cheers,
              > Mark
              >
              > Tom Barnes <[email protected].bea.com>
              > wrote:
              >
              >>Mark Colwell wrote:
              >>
              >>
              >>>Can I create a MDB that receives messages from a Local JMS Queue (created
              >>
              >>on each
              >>
              >>>node) rather than a distributed queue?
              >>
              >>Yes. In fact this is the most common use case.
              >>
              >>
              >>>When I try to deploy such an MDB I get the following exception:
              >>
              >>I don't recall seeing this exception before. It looks like a naming
              >>conflict - it appears that somehow something is already running with
              >>the same name. Are you somehow deploying the same app twice?
              >>
              >>javax.management.InstanceAlreadyExistsException:
              >>mydomain:ApplicationRuntime=Node2_TestLocalMDBCluster,
              >>EJBComponentRuntime=Node2_TestLocalMDBCluster_TestLocalMDBCluster,
              >>Location=Node2,
              >>Name=Node2_TestLocalMDBCluster_TestLocalMDBCluster_AsyncProcessor_jms/myserver,
              >>ServerRuntime=Node2,
              >>Type=MessageDrivenEJBRuntime
              >>
              >>FYI: As of one or two weeks ago, the MDB section of the
              >>EJB docs has been heavily updated. I highly recommend
              >>reading it.
              >>
              >>
              >>>weblogic.management.DeploymentException: Exception:weblogic.management.ApplicationException:
              >>>activate failed for TestLocalMDBCluster Module: TestLocalMDBCluster
              >>
              >>Error: Exception
              >>
              >>>activating module: EJBModule(TestLocalMDBCluster,status=PREPARED) Unable
              >>
              >>to deploy
              >>
              >>>EJB: AsyncProcessor from TestLocalMDBCluster.jar: [EJB:011046]Unable
              >>
              >>to create
              >>
              >>>EJBRuntimeMBean. javax.management.InstanceAlreadyExistsException: mydomain:ApplicationRuntime=Node2_TestLocalMDBCluster,EJBComponentRuntime=Node2_TestLocalMDBCluster_TestLocalMDBCluster,Location=Node2,Name=Node2_TestLocalMDBCluster_TestLocalMDBCluster_AsyncProcessor_jms/myserver,ServerRuntime=Node2,Type=MessageDrivenEJBRuntime
              >>>at com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134)
              >>>at com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.java:2371)
              >>>at com.sun.management.jmx.MBeanServerImpl.registerMBean(MBeanServerImpl.java:876)
              >>>at weblogic.management.internal.RemoteMBeanServerImpl.private_registerMBean(RemoteMBeanServerImpl.java:582)
              >>>at weblogic.management.internal.RemoteMBeanServerImpl.registerMBean(RemoteMBeanServerImpl.java:524)
              >>>at weblogic.management.runtime.RuntimeMBeanDelegate.register(RuntimeMBeanDelegate.java:166)
              >>>at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:122)
              >>>at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:85)
              >>>at weblogic.ejb20.monitoring.EJBRuntimeMBeanImpl.<init>(EJBRuntimeMBeanImpl.java:33)
              >>>at weblogic.ejb20.monitoring.MessageDrivenEJBRuntimeMBeanImpl.<init>(MessageDrivenEJBRuntimeMBeanImpl.java:30)
              >>>at weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.initPool(MessageDrivenBeanPoolInfoImpl.java:182)
              >>>at weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.activate(MessageDrivenBeanPoolInfoImpl.java:245)
              >>>at weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.activatePoolInfo(MessageDrivenBeanInfoImpl.java:474)
              >>>at weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.deploy(MessageDrivenBeanInfoImpl.java:440)
              >>>at weblogic.ejb20.deployer.EJBDeployer.activate(EJBDeployer.java:1327)
              >>
              >>at weblogic.ejb20.deployer.EJBModule.activate(EJBModule.java:610)
              >>
              >>>at weblogic.j2ee.J2EEApplicationContainer.activateModule(J2EEApplicationContainer.java:3127)
              >>>at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:2081)
              >>>at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:2062)
              >>>at weblogic.management.deploy.slave.SlaveDeployer$ComponentActivateTask.activateContainer(SlaveDeployer.java:2592)
              >>>at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.doCommit(SlaveDeployer.java:2515)
              >>>at weblogic.management.deploy.slave.SlaveDeployer$Task.commit(SlaveDeployer.java:2317)
              >>>at weblogic.management.deploy.slave.SlaveDeployer.commitUpdate(SlaveDeployer.java:608)
              >>>at weblogic.drs.internal.SlaveCallbackHandler$2.execute(SlaveCallbackHandler.java:35)
              >>>at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197) at
              >>
              >>weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              >>
              >>>Is there any way to do this?
              >>
              >
              

  • Exploded (hot) deployment  on a Weblogic cluster

    AFAIK, exploded hot deployment on a Weblogic cluster is not supported through OEPE.
    When deploying an application on a cluster, each change, no matter how small, forces you to republish these changes, ultimately causing the application to be redeployed by OEPE. Turnaround time for this (depending on the app) can take some time.
    Is there a workaround available for this ?
    I'm looking for a way to minimize the turnaround time between developing code, and actual seeing the code changes on the screen. The requirement however is that deployments should be possible on a managed instance / cluster (non AdminServer).
    Does Oracle Weblogic support such "hot deployment" capabilities from an IDE like Eclipse ? Does anybody here have such a process in place ? (perhaps using ant / maven2 tooling)

    Hi
    I  want  to  clarify that the  application has to be  deployed  to  a cluster  of  two managed  servers, amandad_Server_1 (On Windows  server hosting  console) and amandad_Server_2 which is running  in  other Windows  server.
    I deployed  the application  following  your  recdommendations and the  resulta is  as  follows:
    Windows  server (running the  console)
    1  EAR  file  was copied to  ...  \user_projects\domains\amanda_domain\servers\amandad_Server_1\stage
    2.  The application files  extractected  from the EAR files  were  copied to   \user_projects\domains\amanda_domain\servers\amandad_Server_1\tmp
    Windows  Server not  runn ing the  console
    No files  were copied to neither
    ... \user_projects\domains\amanda_domain\servers\amandad_Server_2\stage
         \user_projects\domains\amanda_domain\servers\amandad_Server_2\tmp
    Questions
    1  Windows  server  not running the console  the  files  were  not  copied....What  might  cause  this behaviour....? how to  fixi it...?
    2. Do I have  to  manaully copy  the  files  to  folders
    ...\user_projects\domains\amanda_domain\servers\amandad_Server_2\stage  
       ... \user_projects\domains\amanda_domain\servers\amandad_Server_2\tmp

  • How deploy MDB example to SAP J2EE 6.20

    Hi,
    I need to <b>deploy a message driven bean to SAPJ2ee6.20</b>, , and for that first i tried to deploy MDB example(.ear file) from SAPj2ee Installation.
    But at deployment phase, it generate exception.
    How can i do this with succes?
    Thanks a lot,

    Hi Bogdan,
    please, do <i>not</i> post the same question three times into different categories - beneath, all three categories have been wrong, this is a deployment question not concerning EP or Java directly nor 6.40 preview, so you should have posted it to "WAS general".
    <i>No</i>, please do <i>not</i> post it a fourth time... People will read it, and if there shouldn't be an answer...
    It is frustrating for people who want to help to read "it generates an exception" - yeah, <i>which one</i>?!
    Thanks for considering these hints in the future
    Detlev

  • Best Practice when deploying a single mdb into a cluster

    At a high level, we are converting all of our components to Weblogic processes that use Stateless Session Beans and Message Driven Beans. All of the weblogic processes will be clustered, and all of the topic queues will be distributed (Uniform Distributed Topics / Queues).
              We have one component that is a single MDB reading from a single queue on 1 machine. It is a requirement that the JMS messages on that queue be processed in order, and the processing of messages frequently requires that the same row in the DB be updated. Does anyone have any thoughts on the best design for that in our clustered environment?
              One possible solution we have come up with (not working):
              Possible Solution 1: Use a distributed topic and enforce a single client via client-id on the connection factory, causing a single consumer.
              1.Deploy a uniform-distributed Topic to the cluster.
              2.Create a connection factory with a client-id.
              3.Deploy a single FooMDB to the cluster.
              Problem with Solution 1: WL allows multiple consumers on Topic with same client-id
              1.Start (2) servers in cluster
              2.FooMDB running on Server_A connects to Topic
              3.FooMDB running on Server_B fails with unique id exception (yeah).
              4.Send messages - Messages are processed only once by FooMDB on Server_A (yeah).
              5.Stop Server_A.
              6.FooMDB running on Server_B connects automatically to Topic.
              7.Send messages - Messages are processed by FooMDB on Server_B (yeah).
              8.Start Server_A
              9.FooMDB successfully connects to Topic, even though FooMDB on Server_B is already connected (bad). Is this a WL bug or our config bug??
              10.Send messages - Messages are processed by both FooMDB on Server_A and Server_B (bad). Is this a WL bug or our config bug??
              Conclusion: Does anyone have any thoughts on the best design for that in our clustered environment? and if the above solution is doable, what mistake might we have made?
              Thank you in advance for your help!
              kb

    Thanks for the helpful info Tom.
              Kevin - It seems that for both the MDB, and the JMS provider, there are (manual or scripted) actions to be taken during any failure event + failure probes possibly required to launch these actions...?
              In the case of the JMS provider, the JMS destination needs to be migrated in the event of managed-server or host failure; if this host is the one that also runs the Admin server then the Admin server also needs to be restarted on a new host too, in order that it can become available to receive the migration instructions and thus update the config of the managed server which is to be newly targetted to serve the JMS destination.
              In the case of the MDB, a deployment action of some sort would need to take place on another managed-server, in the event of a failure of the managed server or the host, where the original MDB had been initally deployed.
              The JMS Destination migration actions can be totally avoided by the use of another JMS implementation which has a design philosophy of "failover" built into it (for example, Tibco EMS has totally automatic JMS failover features) and could be accessed gracefully by using Weblogic foreign JMS. The sinlge MDB deployed on one of the Weblogic managed servers in the cluster would still need some kind of (possibly scripted) redeployment action, and on top of this, there would need to be some kind of health check process to establish if this re-deployment action was actually required to be launched. It is possible that the logic and actions required just to establish the true functional health of this MDB could themsevles be as difficult as the original design requirement :-)
              All of this suggests that for the given requirement; the BEA environment is not well suited; and if no other environment or JMS provider is available at your site, then a manipulation of process itself may be required to enable it to be handled in a highly-available way which can be gracefully administered in a Weblogic cluster.
              We have not discussed the message payload design and the reasons that message order must be respected - by changing the message payload design and possibly adding additional data, this requirement "can", "in certain circumstances", be avoided.
              If you can't do that, I suggest you buy a 2 node Sun Cluster with shared HA storage and use this to monitor a simple JMS client java program that periodically checks for items on the Queue. The Tibco EMS servers could also be configured on this platform and give totally automatic failover protection for both process and host failure scenarios. With the spare money we can go to the pub.
              P.S. I don't work for Tibco or Sun and am a BIG Weblogic fan :-)

  • Error when deploying MDB : when connecting to my destination

    I am getting this followin error in my webLogic server 7.0 log:
    The Error was:
    The Message-Driven EJB attempted to connect to the JMS destination with the JNDI
    name:
    multiPub1. However, the object with the JNDI name: multiPub1 is not a JMS destination
    , or the destination found was of the wrong type (Topic or Queue).>
    <May 18, 2003 11:13:34 AM PDT> <Warning> <EJB> <010096> <The Message-Driven EJB:
    simpl
    eMDB is unable to connect to the JMS destination: multiPub1. Connection failed
    after 2
    ,592 attempts. The MDB will attempt to reconnect every 10 seconds, this log message
    wi
    ll repeat every 600 seconds until the condition clears.>
    <May 18, 2003 11:13:34 AM PDT> <Warning> <EJB> <010061> <The Message-Driven EJB:
    simpl
    eMDB is unable to connect to the JMS destination: multiPub1. The EJB container
    will au
    tomatically attempt to re-establish the connection with the JMS server. This warning
    m
    ay occur during WebLogic Cluster start-up if the JMS destination is located on
    another
    server. When the JMS server connection is re-established, the Message-Driven
    EJB will
    again receive JMS messages.
    I have the destination defined. I am working with multiple JMS providers. I am
    not using startup class. I read the white paper and am following directions. It
    can recognise my Connection Factory but not my destination. I defined the destination
    in the JNDI tree using the weblogic Admin console. I also have the destination
    defined in my SUN's JNDI provider. The bean is deployed but I keep getting this
    error.
    PLEASE HELP!
    sheela

    There are a lot of reason to caused it,but the fact reason is that your destination doesnot exist in weblogic server jndi tree.

  • MDB Durables in Cluster Servers

    Hello,
              we have two managed servers in cluster WebLogic Server8.1 SP4. We need to use MDB´s Durables whit distributed queues.
              I have read that there are problems whit distributed topics and MDB´s durables, that only works if the MDB´s have different jms-client-id in each node of cluster.
              There are the same problem whit distributed queues?, can we deployed the same MDB in cluster whit distrubuted queues?
              Thanks in advance, Lourdes Ruiz.

    Hi,
              I think you're refering to "durable topic subscriptions". The issues surrounding using "durable topic subscriptions" with distributed topics do not apply to distributed queues.
              In general, the term "durable" in JMS specifically refers to "long-lived" topic subscriptions, not to queues or persistent messages. Queues don't have the concept of "durable consumers".
              Tom

  • Deploy MDBs in Different WL Instances Subscribed to Same Topic

              Let's say I have MDBs X, Y, and Z, each needing to be deployed to a different Weblogic
              server. All need to subscribe to the same Topic. How is this done? Specifically,
              how is the Topic configured and how are the MBDs deployed?
              Thanks,
              Jim Goodwin
              

    For your reading enjoyment, I'm posting some of my
              internal notes on durable subscriber MDB's. This consolidates
              newsgroup information in one place.
              Jim Goodwin wrote:
              > "Jim Goodwin" <[email protected]> wrote:
              >
              >>Let's say I have MDBs X, Y, and Z, each needing to be deployed to a different
              >>Weblogic
              >>server. All need to subscribe to the same Topic. How is this done? Specifically,
              >>how is the Topic configured and how are the MBDs deployed?
              >>
              >>Thanks,
              >>
              >>Jim Goodwin
              >
              >
              > Bah! Nevermind. I found the information I was looking for in other threads.
              A durable topic subscriber MDB uses its name to generate its client-id.
              Since JMS enforces uniqueness on this client-id, this means that if a durable
              subscriber MDB is deployed to multiple servers only one server will be able
              to connect. Some applications want a different behavior where
              each MDB pool on each server gets its own durable subscription.
              The MDB durable subscription id, which must be unique on its topic, comes from:
              1) <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              2) if (1) is not set then the client-id
              comes from the ejb name.
              The durable subscription is uniquely identified within a cluster by a
              combination of "connection-id" and "subscription-id". Only one active
              connection may use a particular "connection-id" within a WebLogic cluster.
              The connection id comes from:
              1) The "ClientId" attribute configured on the WebLogic connection factory.
              This defaults to null. Note that if the ClientId is set on a connection
              factory, only one connection created by the factory
              may be active at a time.
              2) If (1) is not set, then, as with the subscriber-id,
              the connection-id is derived from jms-client-id descriptor attribute:
              <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              3) If (1) and (2) are not set, then, as with the subscriber-id,
              the connection-id is derived from the ejb name.
              Work-around:
              A) Create a custom connection-factory for each server:
              1) configure "JNDIName" to the same value across all servers
              ("myMDBCF" in this example)
              2) configure "ClientId" to a unique value per server
              3) enable "UserTransactionsEnabled"
              4) enable "XAConnectionFactoryEnabled"
              5) set "AcknowledgePolicy" to "ACKNOWLEDGE_PREVIOUS"
              6) target the CF at a single WebLogic server
              (Number 5 is required for non-transactional topic MDBs)
              B) In the MDB's weblogic-ejb-jar.xml descriptor, set the MDB's connection
              factory to the JNDI name of the custom connection factories configured in
              (A). Optionally, also specify the subscriber-id via the jms-client-id
              attribute.
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>exampleBean</ejb-name>
              <message-driven-descriptor>
              <connection-factory-jndi-name>myMDBCF</connection-factory-jndi-name>
              <jms-client-id>myClientID</jms-client-id>
              </message-driven-descriptor>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              C) Target the application at the same servers that have the custom connection
              factories targeted at them.
              Notes/Limitations:
              1) If the MDB is moved from one server to another, the MDB's corresponding
              connection-factory must be moved with it.
              2) This work-around will not work if the destination is not in the same
              cluster as the MDB. (The MDB can not use the local connection factory, which
              contains the connection-id, as connection factories do not work unless they
              are in the same cluster as the destination.)
              3) This work-around will not work for non-WebLogic JMS topics.
              

  • MDB/Topic/WLS cluster question

              Hi
              I was going through some WLS 8.1 docs on JMS and had a question abt Topics & WLS
              in cluster config where say I have 3 servers with say server#1 hosting the Topic
              [not a distributed destination]. I have an an ear file containing an MDB with
              no pool size limit. After deploying the ear in the cluster - lets say that each
              server on the cluster has 5 instances of the MDB [just an example] and a message
              is published on the Topic.
              Q1>Will all the 3 servers get a [one and only one] copy of that message? [my guess
              is yes]
              Q2>Only 1 instance [out of 5] of the MDB/per server will get the message - right?
              Q3> Had I had a separate deployment of the same MDB class in the EAR file for
              the same Topic - thats just going to get treated as a completely separate subscriber
              independent of the first MDB though the implementing class is the same - right?
              thanks
              Anamitra
              

              Anamitra wrote:
              > Hi
              > I was going through some WLS 8.1 docs on JMS and had a question abt Topics & WLS
              > in cluster config where say I have 3 servers with say server#1 hosting the Topic
              > [not a distributed destination]. I have an an ear file containing an MDB with
              > no pool size limit. After deploying the ear in the cluster - lets say that each
              > server on the cluster has 5 instances of the MDB [just an example] and a message
              > is published on the Topic.
              >
              > Q1>Will all the 3 servers get a [one and only one] copy of that message? [my guess
              > is yes]
              Yes.
              > Q2>Only 1 instance [out of 5] of the MDB/per server will get the message - right?
              Yes.
              > Q3> Had I had a separate deployment of the same MDB class in the EAR file for
              > the same Topic - thats just going to get treated as a completely separate subscriber
              > independent of the first MDB though the implementing class is the same - right?
              Yes.
              >
              > thanks
              > Anamitra
              >
              For a little more information, I'm attaching notes on durable
              subscriber MDBs.
              A JMS durable subscription is uniquely identified within a cluster by a combination of "connection-id" and "subscription-id". Only one active connection may use a particular "connection-id" within a WebLogic cluster.
              In WebLogic 8.1 and previous, a durable topic subscriber MDB uses its name to generate its client-id. Since JMS enforces uniqueness on this client-id, this means that if a durable subscriber MDB is deployed to multiple servers only one server will be able to connect. Some applications want a different behavior where
              each MDB pool on each server gets its own durable subscription.
              The MDB connection id, which is unique within a cluster, comes from:
              1) The "ClientId" attribute configured on the WebLogic connection factory.
              This defaults to null. Note that if the ClientId is set on a connection
              factory, only one connection created by the factory
              may be active at a time.
              2) If (1) is not set, then, as with the subscriber-id,
              the connection-id is derived from jms-client-id descriptor attribute:
              <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              3) If (1) and (2) are not set, then, as with the subscriber-id,
              the connection-id is derived from the ejb name.
              The MDB durable subscription id, which must be unique on its topic, comes from:
              1) <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              2) if (1) is not set then the client-id
              comes from the ejb name.
              The above prevents a durable topic subscriber MDB from running on multiple servers. When an instance of the MDB starts on another server, it deploys successfully, but a conflict is detected and the MDB fails to fully connect to JMS. The work-around is the following:
              A) Create a custom connection-factory for each server:
              1) configure "JNDIName" to the same value across all servers
              ("myMDBCF" in this example)
              2) configure "ClientId" to a unique value per server
              3) enable "UserTransactionsEnabled"
              4) enable "XAConnectionFactoryEnabled"
              5) set "AcknowledgePolicy" to "ACKNOWLEDGE_PREVIOUS"
              6) target the CF at a single WebLogic server
              (Number 5 is required for non-transactional topic MDBs)
              B) In the MDB's weblogic-ejb-jar.xml descriptor, set the MDB's connection
              factory to the JNDI name of the custom connection factories configured in
              (A). Optionally, also specify the subscriber-id via the jms-client-id
              attribute.
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>exampleBean</ejb-name>
              <message-driven-descriptor>
              <connection-factory-jndi-name>myMDBCF</connection-factory-jndi-name>
              <jms-client-id>myClientID</jms-client-id>
              </message-driven-descriptor>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              C) Target the application at the same servers that have the custom connection
              factories targeted at them.
              Notes/Limitations:
              1) If the MDB is moved from one server to another, the MDB's corresponding
              connection-factory must be moved with it.
              2) This work-around will not work if the destination is not in the same
              cluster as the MDB. (The MDB can not use the local connection factory, which
              contains the connection-id, as connection factories do not work unless they
              are in the same cluster as the destination.)
              3) This work-around will not work for non-WebLogic JMS topics.
              4) A copy of each message is sent to each to each server's MDB pool.
              

  • URGENT : Error Deploying MDB in 9ias 9.0.3

    Hi
    I am using OJMS and am trying to deploy SLSB and MDB with durable subscriptions to a topic. I have configured the queue table and topic properly. While trying auto deploy of OC4J i am getting the following error...
    Auto-deploying MCAppBEAN.jar (No complete previous deployment found)... Error compiling C:\Oracle9iAS\AppSvr\j2ee\home\appli
    ations\MCApplication/MCAppBEAN.jar: Syntax error in source
    Oracle9iAS (9.0.3.0.0) Containers for J2EE initialized
    It says there is error in the source but which source? It does not log any error message into any file ( or is there any file which I dont know about? ).
    When i tried to deploy the application manually ( admin.jar ) it gave me the following exception...
    com.evermind.compiler.CompilationException: Syntax error in source
    at com.evermind.compiler.FileLinkedCompilation.loadObjects(FileLinkedCompilation.java:196)
    at com.evermind.compiler.FileLinkedCompilation.run(FileLinkedCompilation.java:145)
    at java.security.AccessController.doPrivileged(Native Method)
    at com.evermind.compiler.FileLinkedCompiler.compile(FileLinkedCompiler.java:53)
    at com.evermind.server.ejb.compilation.Compilation.compileClasses(Compilation.java:463)
    at com.evermind.server.ejb.compilation.Compilation.compile(Compilation.java:323)
    at com.evermind.server.administration.ServerApplicationInstallation.finish(ServerApplicationInstallation.java:556)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:119)
    at com.evermind.server.rmi.RMICallHandler.run(RMICallHandler.java:48)
    at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:803)
    at java.lang.Thread.run(Unknown Source)
    Could any body help me with this... Is there some place where I can configure to see the error messages? Has anybody faced this error earlier?
    Thanks in Advance...

    I have discovered a strange thing. I created a new OC4J instance which I called it: Intelap
    When I deploy to the recently created instance Intelap, jdeveloper success. But when I set OC4J_home in the optional instance field, I got the previous error.
    Sergio

  • EJBCompiler Exception when trying to deploy application in a cluster

    Hi,
              I have setup a cluster environment with 2 Managed Servers. While I tried to deploy the application using the Admin console, I got the following exception on both managed servers. I have tried suggestions from different websites:
              1. adding JDK to $PATH in WebLogic startup script and the system PATH.
              http://forum.java.sun.com/thread.jspa?threadID=465456&messageID=2605081
              2. Increasing memory for javac
              http://forum.java.sun.com/thread.jspa?threadID=492907&messageID=2605123
              My application was compiled with JDK 1.4
              But still no luck.
              What am I missing here?
              Thanks.
              Teresa
              [Deployer:149034]An exception occurred for task [Deployer:149026]Deploy application opencase on edcCluster.:
              Exception:weblogic.management.ApplicationException: prepare failed for opencase-ejb.jar
              Module: opencase-ejb.jar Error: Exception preparing module: EJBModule(opencase-ejb.jar,status=NEW)
              Unable to deploy EJB: opencase-ejb.jar from opencase-ejb.jar:
              Compiler failed executable.exec
              at weblogic.ejb20.ejbc.EJBCompiler.doCompile(EJBCompiler.java:274)
              at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java:476)
              at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java:407)
              at weblogic.ejb20.deployer.EJBDeployer.runEJBC(EJBDeployer.java:493)
              at weblogic.ejb20.deployer.EJBDeployer.compileJar(EJBDeployer.java:784)
              at weblogic.ejb20.deployer.EJBDeployer.compileIfNecessary(EJBDeployer.java:700)
              at weblogic.ejb20.deployer.EJBDeployer.prepare(EJBDeployer.java:1339)
              at weblogic.ejb20.deployer.EJBModule.prepare(EJBModule.java:498)
              at weblogic.j2ee.J2EEApplicationContainer.prepareModule(J2EEApplicationContainer.java:3142)
              at weblogic.j2ee.J2EEApplicationContainer.prepareModules(J2EEApplicationContainer.java:1583)
              at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContainer.java:1227)
              at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContainer.java:1070)
              at weblogic.management.deploy.slave.SlaveDeployer$ComponentActivateTask.prepareContainer(SlaveDeployer.java:2513)
              at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.createContainer(SlaveDeployer.java:2463)
              at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.prepare(SlaveDeployer.java:2379)
              at weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(SlaveDeployer.java:866)
              at weblogic.management.deploy.slave.SlaveDeployer.prepareDelta(SlaveDeployer.java:594)
              at weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(SlaveDeployer.java:508)
              at weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallbackHandler.java:25)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
              java.io.IOException: Compiler failed executable.exec
              at weblogic.utils.compiler.CompilerInvoker.compileMaybeExit(CompilerInvoker.java:469)
              at weblogic.utils.compiler.CompilerInvoker.compile(CompilerInvoker.java:328)
              at weblogic.utils.compiler.CompilerInvoker.compile(CompilerInvoker.java:336)
              at weblogic.ejb20.ejbc.EJBCompiler.doCompile(EJBCompiler.java:270)
              at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java:476)
              at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java:407)
              at weblogic.ejb20.deployer.EJBDeployer.runEJBC(EJBDeployer.java:493)
              at weblogic.ejb20.deployer.EJBDeployer.compileJar(EJBDeployer.java:784)
              at weblogic.ejb20.deployer.EJBDeployer.compileIfNecessary(EJBDeployer.java:700)
              at weblogic.ejb20.deployer.EJBDeployer.prepare(EJBDeployer.java:1339)
              at weblogic.ejb20.deployer.EJBModule.prepare(EJBModule.java:498)
              at weblogic.j2ee.J2EEApplicationContainer.prepareModule(J2EEApplicationContainer.java:3142)
              at weblogic.j2ee.J2EEApplicationContainer.prepareModules(J2EEApplicationContainer.java:1583)
              at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContainer.java:1227)
              at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContainer.java:1070)
              at weblogic.management.deploy.slave.SlaveDeployer$ComponentActivateTask.prepareContainer(SlaveDeployer.java:2513)
              at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.createContainer(SlaveDeployer.java:2463)
              at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.prepare(SlaveDeployer.java:2379)
              at weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(SlaveDeployer.java:866)
              at weblogic.management.deploy.slave.SlaveDeployer.prepareDelta(SlaveDeployer.java:594)
              at weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(SlaveDeployer.java:508)
              at weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallbackHandler.java:25)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)

    I solved recently a similar problem. The problem arised because the
              developer had compiled the ejb.jar with JDK 5.0, and then he was trying to
              deploy it to WLS 8.1, which supports only JDK 1.4 compiled classes when
              EJBCompiling.
              <T Y> wrote in message news:[email protected]...
              > Hi,
              > I have setup a cluster environment with 2 Managed Servers. While I tried
              > to deploy the application using the Admin console, I got the following
              > exception on both managed servers. I have tried suggestions from different
              > websites:
              > 1. adding JDK to $PATH in WebLogic startup script and the system PATH.
              > http://forum.java.sun.com/thread.jspa?threadID=465456&messageID=2605081
              >
              > 2. Increasing memory for javac
              > http://forum.java.sun.com/thread.jspa?threadID=492907&messageID=2605123
              >
              > My application was compiled with JDK 1.4
              >
              > But still no luck.
              > What am I missing here?
              >
              > Thanks.
              >
              > Teresa
              >
              >
              > [Deployer:149034]An exception occurred for task [Deployer:149026]Deploy
              > application opencase on edcCluster.:
              > Exception:weblogic.management.ApplicationException: prepare failed for
              > opencase-ejb.jar
              > Module: opencase-ejb.jar Error: Exception preparing module:
              > EJBModule(opencase-ejb.jar,status=NEW)
              > Unable to deploy EJB: opencase-ejb.jar from opencase-ejb.jar:
              > Compiler failed executable.exec
              > at weblogic.ejb20.ejbc.EJBCompiler.doCompile(EJBCompiler.java:274)
              > at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java:476)
              > at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java:407)
              > at weblogic.ejb20.deployer.EJBDeployer.runEJBC(EJBDeployer.java:493)
              > at weblogic.ejb20.deployer.EJBDeployer.compileJar(EJBDeployer.java:784)
              > at
              > weblogic.ejb20.deployer.EJBDeployer.compileIfNecessary(EJBDeployer.java:700)
              > at weblogic.ejb20.deployer.EJBDeployer.prepare(EJBDeployer.java:1339)
              > at weblogic.ejb20.deployer.EJBModule.prepare(EJBModule.java:498)
              > at
              > weblogic.j2ee.J2EEApplicationContainer.prepareModule(J2EEApplicationContainer.java:3142)
              > at
              > weblogic.j2ee.J2EEApplicationContainer.prepareModules(J2EEApplicationContainer.java:1583)
              > at
              > weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContainer.java:1227)
              > at
              > weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContainer.java:1070)
              > at
              > weblogic.management.deploy.slave.SlaveDeployer$ComponentActivateTask.prepareContainer(SlaveDeployer.java:2513)
              > at
              > weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.createContainer(SlaveDeployer.java:2463)
              > at
              > weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.prepare(SlaveDeployer.java:2379)
              > at
              > weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(SlaveDeployer.java:866)
              > at
              > weblogic.management.deploy.slave.SlaveDeployer.prepareDelta(SlaveDeployer.java:594)
              > at
              > weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(SlaveDeployer.java:508)
              > at
              > weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallbackHandler.java:25)
              > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
              > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
              > java.io.IOException: Compiler failed executable.exec
              > at
              > weblogic.utils.compiler.CompilerInvoker.compileMaybeExit(CompilerInvoker.java:469)
              > at
              > weblogic.utils.compiler.CompilerInvoker.compile(CompilerInvoker.java:328)
              > at
              > weblogic.utils.compiler.CompilerInvoker.compile(CompilerInvoker.java:336)
              > at weblogic.ejb20.ejbc.EJBCompiler.doCompile(EJBCompiler.java:270)
              > at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java:476)
              > at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java:407)
              > at weblogic.ejb20.deployer.EJBDeployer.runEJBC(EJBDeployer.java:493)
              > at weblogic.ejb20.deployer.EJBDeployer.compileJar(EJBDeployer.java:784)
              > at
              > weblogic.ejb20.deployer.EJBDeployer.compileIfNecessary(EJBDeployer.java:700)
              > at weblogic.ejb20.deployer.EJBDeployer.prepare(EJBDeployer.java:1339)
              > at weblogic.ejb20.deployer.EJBModule.prepare(EJBModule.java:498)
              > at
              > weblogic.j2ee.J2EEApplicationContainer.prepareModule(J2EEApplicationContainer.java:3142)
              > at
              > weblogic.j2ee.J2EEApplicationContainer.prepareModules(J2EEApplicationContainer.java:1583)
              > at
              > weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContainer.java:1227)
              > at
              > weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationContainer.java:1070)
              > at
              > weblogic.management.deploy.slave.SlaveDeployer$ComponentActivateTask.prepareContainer(SlaveDeployer.java:2513)
              > at
              > weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.createContainer(SlaveDeployer.java:2463)
              > at
              > weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.prepare(SlaveDeployer.java:2379)
              > at
              > weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(SlaveDeployer.java:866)
              > at
              > weblogic.management.deploy.slave.SlaveDeployer.prepareDelta(SlaveDeployer.java:594)
              > at
              > weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(SlaveDeployer.java:508)
              > at
              > weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallbackHandler.java:25)
              > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
              > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)

  • Deploy jw webservice to cluster server, always point to 9081

    i have cluster server(9081, 9082, 9083), when i deploy the helloword webservice generated by jwsc http://download.oracle.com/docs/cd/E12840_01/wls/docs103/webserv/use_cases.html,
    the dynamical wsdl always point to 9081,<s2:address location="http://localhost:9081/HelloWorldImpl/HelloWorldService" /> even when i invoke the service on 9082, http://localhost:9082/HelloWorldImpl/HelloWorldService?WSDL
    i tried generate webservice by axis it works fine. i gooled, couldn't find solution. thx.

    Thanks for looking into it. Clean cache doesn't work for me. Since it works fine for you. I think the issue might related to create/deploy ear file. i don't have cluster setup on my local, so i created ear file and deployed to our DEV(unix) server thru admin console. the web-uri in application.xml generated by the jwsc contains the path examples/webservices/hello_world/HelloWorldImpl.war, instead of HelloWorldImpl.war. i have to manually updated the uri, otherwise i got "not be able to identifiy application path ......war" during install. Since Axis works fine cluster config should be ok. Do you mind share how you config the cluster and how to generate the ear file? this are the two possible places i can think of. i also tried set FrontEnd HTTP Port for each server, still didn't work.
    May i know are you tech support from weblogic? i am trying to find way to create ticket for weblogic tech support for this issue. thx.

  • Deploying MDB on WebLogic server 8.1 (SP2) with Tibco JMS

    Hi,
              I am currently facing problems to deploy and run my MDB on weblogic connecting it to Tibco JMS as the foreign jms server.
              <br>
              <b>My ejb-jar.xml:</b>
              <br>
              <message-driven>
                        <ejb-name>DeAMMsgFactors</ejb-name>
                        <ejb-class>com.db.deam.mdb.DeAMMsgFactors</ejb-class>
                        <transaction-type>Container</transaction-type>
                        <message-driven-destination>
                             <destination-type>javax.jms.Topic</destination-type>
                        </message-driven-destination>
                   </message-driven>
                   </enterprise-beans>
                   <assembly-descriptor>
                        <security-role>
                                  <role-name>soiadmin</role-name>
                   </security-role>
                   </assembly-descriptor>
              <br>
              <b>weblogic-ejb-jar.xml:</b>
              <br>
              <weblogic-enterprise-bean>
              <ejb-name>DeAMMsgFactors</ejb-name>
              <message-driven-descriptor>
              <pool>
              <max-beans-in-free-pool>20</max-beans-in-free-pool>
              <initial-beans-in-free-pool>10</initial-beans-in-free-pool>
              </pool>
              <destination-jndi-name>WLFactorsTopic</destination-jndi-name>
              <connection-factory-jndi-name>WLFactorsCF</connection-factory-jndi-name>
              <jms-polling-interval-seconds>10</jms-polling-interval-seconds>
              </message-driven-descriptor>
              <transaction-descriptor>
              <trans-timeout-seconds>100000</trans-timeout-seconds>
              </transaction-descriptor>
                   </weblogic-enterprise-bean>
                   <security-role-assignment>
              <role-name>soiadmin</role-name>
              <principal-name>jmsusername</principal-name>
                   </security-role-assignment>
              <br>
              <b>Error:</b>
              weblogic.ejb20.WLDeploymentException: [EJB:011014]The Message-Driven EJB failed while creating a JMS Connection. The err
              or was:
              javax.jms.JMSSecurityException: invalid name or password.
              javax.jms.JMSSecurityException: invalid name or password
              at com.tibco.tibjms.Tibjmsx.buildException(Tibjmsx.java:395)
              at com.tibco.tibjms.TibjmsConnection._create(TibjmsConnection.java:581)
              at com.tibco.tibjms.TibjmsConnection.<init>(TibjmsConnection.java:1743)
              at com.tibco.tibjms.TibjmsTopicConnection.<init>(TibjmsTopicConnection.java:35)
              at com.tibco.tibjms.TibjmsxCFImpl._createImpl(TibjmsxCFImpl.java:92)
              at com.tibco.tibjms.TibjmsxCFImpl._createConnection(TibjmsxCFImpl.java:121)
              at com.tibco.tibjms.TibjmsTopicConnectionFactory.createTopicConnection(TibjmsTopicConnectionFactory.java:66)
              at weblogic.ejb20.internal.JMSConnectionPoller.getConnection(JMSConnectionPoller.java:607)
              at weblogic.ejb20.internal.JMSConnectionPoller.createJMSConnection(JMSConnectionPoller.java:1783)
              at weblogic.ejb20.internal.JMSConnectionPoller.connectToJMS(JMSConnectionPoller.java:1087)
              at weblogic.ejb20.internal.JMSConnectionPoller.trigger(JMSConnectionPoller.java:970)
              at weblogic.time.common.internal.ScheduledTrigger.run(ScheduledTrigger.java:243)
              at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:229)
              at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:223)
              at weblogic.time.server.ScheduledTrigger.execute(ScheduledTrigger.java:50)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              at weblogic.ejb20.internal.JMSConnectionPoller.getConnection(JMSConnectionPoller.java:638)
              at weblogic.ejb20.internal.JMSConnectionPoller.createJMSConnection(JMSConnectionPoller.java:1783)
              at weblogic.ejb20.internal.JMSConnectionPoller.connectToJMS(JMSConnectionPoller.java:1087)
              at weblogic.ejb20.internal.JMSConnectionPoller.trigger(JMSConnectionPoller.java:970)
              at weblogic.time.common.internal.ScheduledTrigger.run(ScheduledTrigger.java:243)
              at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:229)
              at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:223)
              at weblogic.time.server.ScheduledTrigger.execute(ScheduledTrigger.java:50)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              [JMSConnectionPoller] : ** Connect attempt for: WLFactorsTopic was: unsuccessful
              <br>
              <u><b>Any help would be appreciated.</b></u>
              <br>
              Thanks,<br>
              Kiran Kumar MV.

    I was able to use MDB to receive msg from a Tibco JMS queue. This is what you have to do: using WL console,
              - set up a foreign JMS Server. Make sure you specify the following correctly: jndi initial context factory (tibjms class), tibjms server url, username/password
              - create a foreign connection factory (if you are using CMT, make sure you create a XA compliant connection factory in Tibco JMS server). It seems that you have to specify URL again when creating XA connection factory in Tibjms.
              - create a foreign destination (queue/topic)
              In ejb-jar.xml and weblogic-ejb-jar.xml,
              - use resource-ref (wrapper) to specify the foreign connection factory
              - use resource-env-ref to specify the foreign destination.
              - In MDB ejb-jar.xml, specify destination-jndi-name and connection-factory-jndi-name.
              See Message Driven Beans chapter in Programming WebLogic EJB doc.
              Good luck.

  • HowTo:Publish Msg to JMS queue deployed in a Weblogic Cluster from a client

    Hello All-
    I am new to Weblogic and need help from this forum. Forgive me for my ignorance. I am learning.
    Below is a brief about the context and the issues that we are facing:
    Background
    =======
    1. We have Oracle Service Bus (OSB) installed on top of Oracle Weblogic Server (ver 10.3). In OSB we have developed a proxy service that listens to a JMS queue for an incoming message
    2. The Weblogic environment is a cluster having 2 managed servers listening to different ports and it is front-ended by a Apache Load Balancer.
    3. Our requirement is to post an XML message from a Java client to the JMS queue which will then initiate the proxy service deployed. We are using t3 protocol to post the message from the client to the JMS queue
    Issue
    ====
    1. To post an XML message from the client, how do we give the address of the JMS queue in the clustered environment to enable failover/loadbalancing if one managed server goes down. I understand from your earlier posts in this forum that directly hitting the JMS queue on a particular managed server will not enable failover/loadbalancing in case one of them goes down
    2. Do we need to modify any config file in the Apache Proxy Plugin?
    3. Do we need to provide the address of the Apache proxy in the client to send the message?
    Kindly clarify and let me know me know if you need any additional information.
    Greatly appreciate your help!!!
    Regards,
    Dibya

    Hi Dibya,
    Please refer to : http://weblogic-wonders.com/weblogic/2010/05/13/apache-proxy-as-static-content-repository/#comment-1379
    Thanks
    Jay SenSharma

  • Problem deploying webservice application to cluster

    My web service is packaged inside an ear file generated by WLS workshop. The ear deploys and runs fine on standalone WLS 9.2.2 when deployed through console. When same ear file is deployed to cluster, the webservice does node show up on the managed nodes. Under test endpoints, WLS console shows links only to wsdl locations. WSDL is available on clicking the link. The console does not show links to webservice test client as it does on standalone installation. If I type in the expected test client location I get an HTTP 404 error. I do not see any obvious error messages during application deployment or runtime in the log file of admin server or managed nodes.
    Any help on troubleshooting this issue is appreciated. Thanks.

    The cluster address has a typo in it. The interesting part is weblogic does not report any errors / warning if the IP address in cluster address are invalid (not incorrect). So, if you give an IP address as 111.111.1111 you will get nothing in logs and app will not work but status of servers and app will be shown as active as if everything is fine.

Maybe you are looking for