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?
          >>
          >
          

Similar Messages

  • HT4623 Dear AppleCare,  My iPhone 5 was bought with full price in the USA from Sprint, and I was told that it is a global phone.  But when I am back in China  using local carrier,  Can not be activated

    >
    >>Dear AppleCare,
    >>My iPhone 5 was bought with full price in the USA from Sprint, and I was told that it is a global phone.
    >>But when I am back in China  using local carrier,  Can not be activated
    >>I can't believe that !
    >>>Details:
    >>>SN:F1*******8GL
    <Personal Information Edited by Host>

    Sorry to tell you this but this is not AppleCare.
    This is a forum of users just like yourself who do their best to help other users.
    We are not able to help you with your problem

  • JMS cluster and happen JMS Queue Exception javax.naming.NameAlreadyBoundExc

    Hi,
    Sorry I not sure how to setup JMS cluster in WLS 10.3.2. We have two manager server in two machine. And will join into one cluster. After configure the JMS module & JMS server. We found it only can work in one server. And will faill in another server. And reply the error message as below :
    Any one can help to tell me why one server success. And other is fail !
    javax.naming.NameAlreadyBoundException: JMS_Queue_misdel_a is already bound; rem
    aining name ''
    at weblogic.jndi.internal.BasicNamingNode.bindHere(BasicNamingNode.java:357)
    at weblogic.jndi.internal.ServerNamingNode.bindHere(ServerNamingNode.java:140)
    at weblogic.jndi.internal.BasicNamingNode.bind(BasicNamingNode.java:317)
    at weblogic.jndi.internal.WLEventContextImpl.bind(WLEventContextImpl.jav
    ==> config for JMS
    <jms-server>
    <name>JMS_Server_cim_a</name>
    <target>ebowls05</target>
    <persistent-store xsi:nil="true"></persistent-store>
    <hosting-temporary-destinations>true</hosting-temporary-destinations>
    <temporary-template-resource xsi:nil="true"></temporary-template-resource>
    <temporary-template-name xsi:nil="true"></temporary-template-name>
    <message-buffer-size>-1</message-buffer-size>
    <expiration-scan-interval>30</expiration-scan-interval>
    </jms-server>
    <jms-server>
    <name>JMS_Server_cim_b</name>
    <target>ebowls06</target>
    <persistent-store xsi:nil="true"></persistent-store>
    <hosting-temporary-destinations>true</hosting-temporary-destinations>
    <temporary-template-resource xsi:nil="true"></temporary-template-resource>
    <temporary-template-name xsi:nil="true"></temporary-template-name>
    <message-buffer-size>-1</message-buffer-size>
    <expiration-scan-interval>30</expiration-scan-interval>
    </jms-server>
    <migratable-target>
    <name>ebowls06 (migratable)</name>
    <notes>This is a system generated default migratable target for a server. Do
    not delete manually.</notes>
    <user-preferred-server>ebowls06</user-preferred-server>
    <cluster>ebouatCluster</cluster>
    </migratable-target>
    <migratable-target>
    <name>ebowls05 (migratable)</name>
    <notes>This is a system generated default migratable target for a server. Do
    not delete manually.</notes>
    <user-preferred-server>ebowls05</user-preferred-server>
    <cluster>ebouatCluster</cluster>
    </migratable-target>
    <jms-system-resource>
    <name>JMS_ConnFactory_cim</name>
    <target>ebouatCluster</target>
    <descriptor-file-name>jms/JMS_ConnFactory_cim/JMS_ConnFactory_cim-jms.xml</d
    escriptor-file-name>
    </jms-system-resource>
    <jms-system-resource>
    <name>JMS_Queue_promis</name>
    <target>ebouatCluster</target>
    <sub-deployment>
    <name>JMS_Queue_promis@JMS_Server_cim_a</name>
    <target>JMS_Server_cim_a</target>
    </sub-deployment>
    <sub-deployment>
    <name>JMS_Queue_promis@JMS_Server_cim_b</name>
    <target>JMS_Server_cim_b</target>
    </sub-deployment>
    <descriptor-file-name>jms/JMS_Queue_promis/JMS_Queue_promis-jms.xml</descrip
    tor-file-name>
    </jms-system-resource>
    <jms-system-resource>
    <name>JMS_Template_cim</name>
    <target>ebouatCluster</target>
    <descriptor-file-name>jms/JMS_Template_cim/JMS_Template_cim-jms.xml</descrip
    tor-file-name>
    </jms-system-resource>
    <jms-system-resource>
    <name>JMS_Queue_misdel_a</name>
    <target>ebouatCluster</target>
    <sub-deployment>
    <name>JMS_Queue_misdel_a@JMS_Server_cim_a</name>
    <target>JMS_Server_cim_a</target>
    </sub-deployment>
    <sub-deployment>
    <name>JMS_Queue_misdel_a@JMS_Server_cim_b</name>
    <target>JMS_Server_cim_b</target>
    </sub-deployment>
    <descriptor-file-name>jms/JMS_Queue_misdel_a/JMS_Queue_misdel_a-jms.xml</des
    criptor-file-name>
    </jms-system-resource>
    <jms-system-resource>
    <name>JMS_Queue_misdel_b</name>
    <target>ebouatCluster</target>
    <sub-deployment>
    <name>JMS_Queue_misdel_b@JMS_Server_cim_a</name>
    <target>JMS_Server_cim_a</target>
    </sub-deployment>
    <sub-deployment>
    <name>JMS_Queue_misdel_b@JMS_Server_cim_b</name>
    <target>JMS_Server_cim_b</target>
    </sub-deployment>
    <descriptor-file-name>jms/JMS_Queue_misdel_b/JMS_Queue_misdel_b-jms.xml</des
    criptor-file-name>
    </jms-system-resource>

    1 - JMS clustering is an advanced concept, and, in most cases, uses "distributed queues". In case you haven't already, I highly recommend reading the JMS chapter of the new book "Professional Oracle WebLogic" as well as the related chapters in the JMS Programmer's Guide in the edocs.
    2 - The basic problem below is that you have two different queues that have matching JNDI names, but are in the same cluster.
    3 - The config snippet supplied below does not include the queue configuration. Queue configuration is embedded within the referenced module files.
    4 - Please ensure that you follow configuration best practices, as per: http://download.oracle.com/docs/cd/E15523_01/web.1111/e13738/best_practice.htm#CACJCGHG

  • JMS Queue Not bound

    Configured JMS communication to connect to external JMS Queue.
    When i see the status in Adapter monitor, it shows an error "Receiver channel details:<queuename> not bound".
    Would like to know , where is the problem this error is related to?
    Thnx
    Sunil

    Hi,
    First of all check all your configuration steps in the directory. i.e Receiver Determination/Interface Determination/Receiver Agreement etc
    Are you getting any error in the SXMB_MONI ?
    ALso check the RWB->Message Monitoring ->Message Display tool and check the status
    If there is no error in the above, if the error is only in the Adapter monitor, then check the Adapter configuration .
    Regards,
    moorthy

  • JMS/Queue cluster question

              Hi
              I have some very basic cluster questions on JMS Queues. Lets say Q1>I have 3 WLS
              in cluster. I create the queue in only WLS#1 - then all the other WLS (#2 and #3)
              should have a stub in their JNDI tree for the Queue which points to the Queue in
              #1 - right? Basically what I am trying to acheive is to have the queue in one server
              and all the other servers have a pointer to it - I beleive this is possible in WLS
              cluster - right??
              Q2> Is there any way a client to the queue running on a WLS can tell whether the
              Queue handle its using is local (ie in the same server) or remote. Is the API createQueue(./queuename)
              going to help here??
              Q3>Is there any way to create a Queue dynamically - I guess JMX is the answer -right?
              But I will take this question a bit further - lets say Q1 answer is yes. In this
              case if server #1 crashes - then #2 and #3 have no Queues. So if they try to create
              a replica of the Queue (as on server#1) - pointing to the same filestore - can they
              do it?? - I want only one of them to succed in creating the Queue and also the Queue
              should have all the data of the #1 Queue (1 to 1 replica).
              All I want is the concept of primary and secondary queue in a cluster. Go on using
              the primary queue - but if it fails use the 2ndry queue. Kind of HttpSession replication
              concept in clusters. My cluster purpose is more for failover rather than loadbalancing.
              TIA
              Anamitra
              

              Anamitra wrote:
              > Hi Tom
              > 7.0 is definitely an option for me. So lets take the scenarion on case of JMS cluster
              > and 7.0.
              >
              > I do not understand what u mean by HA framework?
              An HA framework is a third party product that can be used to automatically restart a failed server
              (perhaps on a new machine), and that will guarantee that the same server isn't started in two
              different places (that would be bad). There are few of these HA products, "Veritas" is one of
              them. Note that if you are using JMS file stores or transactions, both of which depend on the disk,
              you must make sure that the files are available on the new machine. One approach to this is to use
              what is known as a "dual-ported" disk.
              > If I am using a cluster of 3 WLS
              > 7.0 servers - as u have said I can create a distrubuted Queue with a fwd delay attribute
              > set to 0 if I have the consumer only in one server say server #1.
              > But still if the server #1 goes down u say that the Queues in server #2 and server
              > #3 will not have access to the messages which were stuck in the server #1 Queue when
              > it went down -right?
              Right, but is there a point in forwarding the messages to your consumer's destination if your
              application is down?
              If your application can tolerate it, you may wish to consider allowing multiple instances of it (one
              per physical destination). That way if something goes down, only those messages are out-of-business
              until the application comes back up...
              >
              >
              > Why cant the other servers see them - they all point to the same store right??
              > thanks
              > Anamitra
              >
              Again, multiple JMS servers can not share a store. Nor can multiple stores share a file. That will
              cause corruption. Multiple stores CAN share a database, but can't use the same tables in the
              database.
              Tom
              >
              > Tom Barnes <[email protected]> wrote:
              > >
              > >
              > >Anamitra wrote:
              > >
              > >> Hi
              > >> I have some very basic cluster questions on JMS Queues. Lets say Q1>I
              > >have 3 WLS
              > >> in cluster. I create the queue in only WLS#1 - then all the other WLS
              > >(#2 and #3)
              > >> should have a stub in their JNDI tree for the Queue which points to the
              > >Queue in
              > >> #1 - right?
              > >
              > >Its not a stub. But essentially right.
              > >
              > >> Basically what I am trying to acheive is to have the queue in one server
              > >> and all the other servers have a pointer to it - I beleive this is possible
              > >in WLS
              > >> cluster - right??
              > >
              > >Certainly.
              > >
              > >>
              > >> Q2> Is there any way a client to the queue running on a WLS can tell whether
              > >the
              > >> Queue handle its using is local (ie in the same server) or remote. Is
              > >the API createQueue(./queuename)
              > >> going to help here??
              > >
              > >That would do it. This returns the queue on the CF side of the established
              > >Connection.
              > >
              > >>
              > >> Q3>Is there any way to create a Queue dynamically - I guess JMX is the
              > >answer -right?
              > >> But I will take this question a bit further - lets say Q1 answer is yes.
              > >In this
              > >> case if server #1 crashes - then #2 and #3 have no Queues. So if they
              > >try to create
              > >> a replica of the Queue (as on server#1) - pointing to the same filestore
              > >- can they
              > >> do it??
              > >> - I want only one of them to succed in creating the Queue and also the
              > >Queue
              > >> should have all the data of the #1 Queue (1 to 1 replica).
              > >
              > >No. Not possible. Corruption city.
              > >Only one server may safely access a store at a time.
              > >If you have an HA framework that can ensure this atomicity fine, or are
              > >willing
              > >to ensure this manually then fine.
              > >
              > >>
              > >>
              > >> All I want is the concept of primary and secondary queue in a cluster.
              > >Go on using
              > >> the primary queue - but if it fails use the 2ndry queue. Kind of HttpSession
              > >replication
              > >> concept in clusters. My cluster purpose is more for failover rather than
              > >loadbalancing.
              > >
              > >If you use 7.0 you could use a distributed destination, with a high weight
              > >on the destination
              > >you want used most. Optionally, 7.0 will automatically forward messages
              > >from distr. dest
              > >members that have no consumers to those that do.
              > >
              > >In 6.1 you can emulate a distributed destination this way (from an upcoming
              > >white-paper):
              > >Approximating Distributed Queues in 6.1
              > >
              > >If you wish to distribute the destination across several servers in a cluster,
              > >use the distributed
              > >destination features built into WL 7.0. If 7.0 is not an option, you can
              > >still approximate a simple
              > >distributed destination when running JMS servers in a &#8220;single-tier&#8221;
              > configuration.
              > > Single-tier indicates
              > >that there is a local JMS server on each server that a connection factory
              > >is targeted at. Here is a
              > >typical scenario, where producers randomly pick which server and consequently
              > >which part of the
              > >distributed destination to produce to, while consumers in the form of MDBs
              > >are pinned to a particular
              > >destination and are replicated homogenously to all destinations:
              > >
              > >· Create JMS servers on multiple servers in the cluster. The servers will
              > >collectively host the
              > >distributed queue &#8220;A&#8221;. Remember, the JMS servers (and WL servers) must
              > >be named differently.
              > >
              > >· Configure a queue on each JMS server. These become the physical destinations
              > >that collectively become
              > >the distributed destination. Each destination should have the same name
              > >"A".
              > >
              > >· Configure each queue to have the same JNDI name &#8220;JNDI_A&#8221;, and also
              > take
              > >care to set the destination&#8217;s
              > >&#8220;JNDINameReplicated&#8221; parameter to false. The &#8220;JNDINameReplicated&#8221;
              > parameter
              > >is available in 7.0, 6.1SP3
              > >or later, or 6.1SP2 with patch CR061106.
              > >
              > >· Create a connection factory, and target it at all servers that have a
              > >JMS server with &#8220;A&#8221;.
              > >
              > >· Target the same MDB pool at each server that has a JMS server with destination
              > >&#8220;A&#8221;, configure its
              > >destination to be &#8220;JNDI_A&#8221;. Do not specify a connection factory URL
              > when
              > >configuring the MDB, as it can
              > >use the server&#8217;s default JNDI context that already contains the destination.
              > >
              > >· Producers look up the connection factory, create a connection, then a
              > >session as usual. Then producers
              > >look up the destination by calling javax.jms.QueueSession.createQueue(String).
              > > The parameter to
              > >createQueue requires a special syntax, the syntax is &#8220;./<queue name>&#8221;,
              > so
              > >&#8220;./A&#8221; works in this example.
              > >This will return a physical destination of the distributed destination that
              > >is local to the producer&#8217;s
              > >connection. This syntax is available on 7.0, 6.1SP3 or later, and 6.1SP2
              > >with patch CR072612.
              > >
              > >This design pattern allows for high availability, as if one server goes
              > >down, the distributed destination
              > >is still available and only the messages on that one server become unavailable.
              > > It also allows for high
              > >scalability as speedup is directly proportional to the number of servers
              > >on which the distributed
              > >destination is deployed.
              > >
              > >
              > >
              > >>
              > >> TIA
              > >> Anamitra
              > >
              > >
              > ><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
              > ><html>
              > >Anamitra wrote:
              > ><blockquote TYPE=CITE>Hi
              > ><br>I have some very basic cluster questions on JMS Queues. Lets say Q1>I
              > >have 3 WLS
              > ><br>in cluster. I create the queue in only WLS#1 - then all the other WLS
              > >(#2 and #3)
              > ><br>should have a stub in their JNDI tree for the Queue which points to
              > >the Queue in
              > ><br>#1 - right?</blockquote>
              > >Its not a stub. But essentially right.
              > ><blockquote TYPE=CITE>Basically what I am trying to acheive is to have
              > >the queue in one server
              > ><br>and all the other servers have a pointer to it - I beleive this is
              > >possible in WLS
              > ><br>cluster - right??</blockquote>
              > >Certainly.
              > ><blockquote TYPE=CITE>
              > ><br>Q2> Is there any way a client to the queue running on a WLS can tell
              > >whether the
              > ><br>Queue handle its using is local (ie in the same server) or remote.
              > >Is the API createQueue(./queuename)
              > ><br>going to help here??</blockquote>
              > >That would do it. This returns the queue on the
              > >CF side of the established Connection.
              > ><blockquote TYPE=CITE>
              > ><br>Q3>Is there any way to create a Queue dynamically - I guess JMX is
              > >the answer -right?
              > ><br>But I will take this question a bit further - lets say Q1 answer is
              > >yes. In this
              > ><br>case if server #1 crashes - then #2 and #3 have no Queues. So if they
              > >try to create
              > ><br>a replica of the Queue (as on server#1) - pointing to the same filestore
              > >- can they
              > ><br>do it?? <br>
              > >- I want only one of them to succed in creating the Queue and also the
              > >Queue
              > ><br>should have all the data of the #1 Queue (1 to 1 replica).</blockquote>
              > >No. Not possible. Corruption city.
              > ><br>Only one server may safely access a store at a time.
              > ><br>If you have an HA framework that can ensure this atomicity fine, or
              > >are willing
              > ><br>to ensure this manually then fine.
              > ><blockquote TYPE=CITE>
              > ><p>All I want is the concept of primary and secondary queue in a cluster.
              > >Go on using
              > ><br>the primary queue - but if it fails use the 2ndry queue. Kind of HttpSession
              > >replication
              > ><br>concept in clusters. My cluster purpose is more for failover rather
              > >than loadbalancing.</blockquote>
              > >If you use 7.0 you could use a distributed destination, with a high weight
              > >on the destination
              > ><br>you want used most. Optionally, 7.0 will automatically
              > >forward messages from distr. dest
              > ><br>members that have no consumers to those that do.
              > ><p><i>In 6.1 you can emulate a distributed destination this way (from an
              > >upcoming white-paper):</i>
              > ><br><i>Approximating Distributed Queues in 6.1</i><i></i>
              > ><p><i>If you wish to distribute the destination across several servers
              > >in a cluster, use the distributed destination features built into WL 7.0.
              > >If 7.0 is not an option, you can still approximate a simple distributed
              > >destination when running JMS servers in a &#8220;single-tier&#8221; configuration.
              > >Single-tier indicates that there is a local JMS server on each server that
              > >a connection factory is targeted at. Here is a typical scenario,
              > >where producers randomly pick which server and consequently which part
              > >of the distributed destination to produce to, while consumers in the form
              > >of MDBs are pinned to a particular destination and are replicated homogenously
              > >to all destinations:</i><i></i>
              > ><p><i>· Create JMS servers on multiple servers in the cluster.
              > >The servers will collectively host the distributed queue &#8220;A&#8221;. Remember,
              > >the JMS servers (and WL servers) must be named differently.</i><i></i>
              > ><p><i>· Configure a queue on each JMS server. These become
              > >the physical destinations that collectively become the distributed destination.
              > >Each destination should have the same name "A".</i><i></i>
              > ><p><i>· Configure each queue to have the same JNDI name &#8220;JNDI_A&#8221;,
              > >and also take care to set the destination&#8217;s &#8220;JNDINameReplicated&#8221;
              > parameter
              > >to false. The &#8220;JNDINameReplicated&#8221; parameter is available in
              > >7.0, 6.1SP3 or later, or 6.1SP2 with patch CR061106.</i><i></i>
              > ><p><i>· Create a connection factory, and target it at all servers
              > >that have a JMS server with &#8220;A&#8221;.</i><i></i>
              > ><p><i>· Target the same MDB pool at each server that has a JMS server
              > >with destination &#8220;A&#8221;, configure its destination to be &#8220;JNDI_A&#8221;.
              > >Do not specify a connection factory URL when configuring the MDB, as it
              > >can use the server&#8217;s default JNDI context that already contains the destination.</i><i></i>
              > ><p><i>· Producers look up the connection factory, create a connection,
              > >then a session as usual. Then producers look up the destination by
              > >calling javax.jms.QueueSession.createQueue(String). The parameter
              > >to createQueue requires a special syntax, the syntax is &#8220;./<queue name>&#8221;,
              > >so &#8220;./A&#8221; works in this example. This will return a physical
              > >destination of the distributed destination that is local to the producer&#8217;s
              > >connection. This syntax is available on 7.0, 6.1SP3 or later,
              > >and 6.1SP2 with patch CR072612.</i><i></i>
              > ><p><i>This design pattern allows for high availability, as if one server
              > >goes down, the distributed destination is still available and only the
              > >messages on that one server become unavailable. It also allows
              > >for high scalability as speedup is directly proportional to the number
              > >of servers on which the distributed destination is deployed.</i>
              > ><br><i></i>
              > ><br><i></i>
              > ><blockquote TYPE=CITE>
              > ><br>TIA
              > ><br>Anamitra</blockquote>
              > ></html>
              > >
              > >
              

  • Stop MDB from listening to a JMS queue

    Hello,
    From time to time we would like to stop the processing done in our application.
    The processing is started by onMessage() in MDB. Is it possible to tell the MDB
    to stop listening
    to the JMS queue or stop the delivery of messages by JMS ? We do not intent to
    stop the processing of messages that have already started by only to stop processing
    of further messages (the ones still in the JMS queue).
    We are using 6.1SP3.
    Any help is appreciated.
    Eric Poupaert,
    Approach Belgium SA.

    If you can tune the number of messages that should be sent to the MDB to 0, that would
    temporarily stop the MDB from consuming messages. Thsi is the "Messages maximum"
    parameter on ur connectionfactory. WL6 doesnt support changing this value to 0 but there
    were some newsgroup discussions last year that it might be supported in a future
    release. Maybe its fixed in 8?
    Eric Poupaert wrote:
    Hello,
    From time to time we would like to stop the processing done in our application.
    The processing is started by onMessage() in MDB. Is it possible to tell the MDB
    to stop listening
    to the JMS queue or stop the delivery of messages by JMS ? We do not intent to
    stop the processing of messages that have already started by only to stop processing
    of further messages (the ones still in the JMS queue).
    We are using 6.1SP3.
    Any help is appreciated.
    Eric Poupaert,
    Approach Belgium SA.

  • Error while using webmethod JMS provider with JNDI

    Hi,
    I am using webmethod JMS provider (not SAP JMS) with JNDI to connect to webmethod with XI. Central J2EE adapter engine is used and the comm chaneel is configured in with appropriate Provider JNDI Server address, initial context factory, Name of queue connection factory etc. 
    While activated the adapter short log shows: Adapter has not provided any status information about this channel"
    In the detailed log following error message is displayed: "Obtained connection factory: null#"
    #1.5 #001A4BAC31000052000001520000152200045090BF28DACA#1214482519514#com.sap.aii.adapter.jms.core.connector.JndiConnectorImpl##com.sap.aii.adapter.jms.core.connector.JndiConnectorImpl.createConnectionFactory()#J2EE_GUEST#0##n/a##8b16bd50437911ddc9f2001a4bac3100#SAPEngine_Application_Thread[impl:3]_16##0#0#Path##Plain###Entering method#
    #1.5 #001A4BAC31000052000001530000152200045090BF28DB65#1214482519514#com.sap.aii.adapter.jms.core.connector.JndiConnectorImpl##com.sap.aii.adapter.jms.core.connector.JndiConnectorImpl.createConnectionFactory()#J2EE_GUEST#0##n/a##8b16bd50437911ddc9f2001a4bac3100#SAPEngine_Application_Thread[impl:3]_16##0#0#Debug##Plain###Looking up connection factory under name NAIP_XIQueueConnectionFactory#
    #1.5 #001A4BAC31000052000001540000152200045090BF28E42E#1214482519516#com.sap.aii.adapter.jms.core.connector.JndiConnectorImpl##com.sap.aii.adapter.jms.core.connector.JndiConnectorImpl.createConnectionFactory()#J2EE_GUEST#0##n/a##8b16bd50437911ddc9f2001a4bac3100#SAPEngine_Application_Thread[impl:3]_16##0#0#Debug##Plain###Obtained connection factory: null#
    #1.5 #001A4BAC31000052000001550000152200045090BF28E4B3#1214482519516#com.sap.aii.adapter.jms.core.connector.JndiConnectorImpl##com.sap.aii.adapter.jms.core.connector.JndiConnectorImpl.createConnectionFactory()#J2EE_GUEST#0##n/a##8b16bd50437911ddc9f2001a4bac3100#SAPEngine_Application_Thread[impl:3]_16##0#0#Path##Plain###Exiting method#
    #1.5 #001A4BAC31000052000001560000152200045090BF28E528#1214482519516#com.sap.aii.adapter.jms.core.connector.ConnectorImpl##com.sap.aii.adapter.jms.core.connector.ConnectorImpl.executeConnectionFactoryInvocations()#J2EE_GUEST#0##n/a##8b16bd50437911ddc9f2001a4bac3100#SAPEngine_Application_Thread[impl:3]_16##0#0#Path##Plain###Entering method#
    #1.5 #001A4BAC31000052000001570000152200045090BF28E5A9#1214482519517#com.sap.aii.adapter.jms.core.connector.ConnectorImpl##com.sap.aii.adapter.jms.core.connector.ConnectorImpl.executeConnectionFactoryInvocations()#J2EE_GUEST#0##n/a##8b16bd50437911ddc9f2001a4bac3100#SAPEngine_Application_Thread[impl:3]_16##0#0#Info##Java###Sucessfully executed CF invocations for connection factory object: for profile: #2#<null>#ConnectionProfile of channel: CC_RCV_JMS_SAPJNDIon node: 3010950 having object id: e4413a5265a436459e271d5e0dd4859b#
    #1.5 #001A4BAC31000052000001580000152200045090BF28E64E#1214482519517#com.sap.aii.adapter.jms.core.connector.ConnectorImpl##com.sap.aii.adapter.jms.core.connector.ConnectorImpl.executeConnectionFactoryInvocations()#J2EE_GUEST#0##n/a##8b16bd50437911ddc9f2001a4bac3100#SAPEngine_Application_Thread[impl:3]_16##0#0#Path##Plain###Exiting method#
    #1.5 #001A4BAC31000052000001590000152200045090BF28E6CA#1214482519517#com.sap.aii.adapter.jms.core.connector.ConnectorImpl##com.sap.aii.adapter.jms.core.connector.ConnectorImpl.buildConnection()#J2EE_GUEST#0##n/a##8b16bd50437911ddc9f2001a4bac3100#SAPEngine_Application_Thread[impl:3]_16##0#0#Path##Plain###Entering method#
    #1.5 #001A4BAC310000520000015A0000152200045090BF28E741#1214482519517#com.sap.aii.adapter.jms.core.common.StringUtils##com.sap.aii.adapter.jms.core.common.StringUtils.isBlank(String str)#J2EE_GUEST#0##n/a##8b16bd50437911ddc9f2001a4bac3100#SAPEngine_Application_Thread[impl:3]_16##0#0#Path##Plain###Entering method#
    #1.5 #001A4BAC310000520000015B0000152200045090BF28E7C3#1214482519517#com.sap.aii.adapter.jms.core.connector.ConnectorImpl##com.sap.aii.adapter.jms.core.connector.ConnectorImpl.buildConnection()#J2EE_GUEST#0##n/a##8b16bd50437911ddc9f2001a4bac3100#SAPEngine_Application_Thread[impl:3]_16##0#0#Debug##Plain###Creating connection...#
    #1.5 #001A4BAC310000520000015C0000152200045090BF28EB51#1214482519518#com.sap.aii.adapter.jms.core.channel.AdapterImpl##com.sap.aii.adapter.jms.core.channel.AdapterImpl.addOrReplaceChannel(Channel cpaChannel)#J2EE_GUEST#0##n/a##8b16bd50437911ddc9f2001a4bac3100#SAPEngine_Application_Thread[impl:3]_16##0#0#Warning##Java###Catching #1#java.lang.NullPointerException
    at com.sap.aii.adapter.jms.core.connector.ConnectorImpl.buildConnection(ConnectorImpl.java:198)
    at com.sap.aii.adapter.jms.core.connector.ConnectorImpl.doConnect(ConnectorImpl.java:166)
    at com.sap.aii.adapter.jms.core.connector.JndiConnectorImpl.doConnect(JndiConnectorImpl.java:186)
    at com.sap.aii.adapter.jms.core.connector.ConnectorImpl.connect(ConnectorImpl.java:151)
    at com.sap.aii.adapter.jms.core.channel.ChannelImpl.doStart(ChannelImpl.java:235)
    at com.sap.aii.adapter.jms.core.channel.ChannelImpl.start(ChannelImpl.java:154)
    at com.sap.aii.adapter.jms.core.channel.AdapterImpl.doAddUpdateChannel(AdapterImpl.java:404)
    at com.sap.aii.adapter.jms.core.channel.AdapterImpl.addOrReplaceChannel(AdapterImpl.java:376)
    at com.sap.aii.adapter.jms.core.channel.ChannelLifecycleCallbackImpl$1.run(ChannelLifecycleCallbackImpl.java:51)
    at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
    at java.security.AccessController.doPrivileged(Native Method)
    at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:102)
    at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:172)
    #1.5 #001A4BAC310000520000015D0000152200045090BF28EC6A#1214482519518#com.sap.aii.adapter.jms.core.channel.AdapterImpl##com.sap.aii.adapter.jms.core.channel.AdapterImpl.addOrReplaceChannel(Channel cpaChannel)#J2EE_GUEST#0##n/a##8b16bd50437911ddc9f2001a4bac3100#SAPEngine_Application_Thread[impl:3]_16##0#0#Error##Plain###[[ChannelName:CC_RCV_JMS_SAPJNDI,ChannelId: e4413a5265a436459e271d5e0dd4859b]] Error adding/updating channel.#
    #1.5 #001A4BAC310000520000015E0000152200045090BF28ECF8#1214482519518#com.sap.aii.adapter.jms.core.channel.AdapterImpl##com.sap.aii.adapter.jms.core.channel.AdapterImpl.addOrReplaceChannel(Channel cpaChannel)#J2EE_GUEST#0##n/a##8b16bd50437911ddc9f2001a4bac3100#SAPEngine_Application_Thread[impl:3]_16##0#0#Path##Plain###Exiting method#
    #1.5 #001A4BAC310000520000015F0000152200045090BF28ED76#1214482519519#com.sap.aii.adapter.jms.core.channel.ChannelLifecycleCallbackImpl##com.sap.aii.adapter.jms.core.channel.ChannelLifecycleCallbackImpl.channelAdded().run()#J2EE_GUEST#0##n/a##8b16bd50437911ddc9f2001a4bac3100#SAPEngine_Application_Thread[impl:3]_16##0#0#Path##Plain###Exiting method#
    #1.5 #001A4BAC3100005F000000660000152200045090BF65478A#1214482523474#com.sap.aii.adapter.jms.core.channel.ChannelLifecycleCallbackImpl#sap.com/com.sap.xi.mdt#com.sap.aii.adapter.jms.core.channel.ChannelLifecycleCallbackImpl.channelAdded(Channel channel)#AAAAAAAAA#108##n/a##002ee500437911dd99cf001a4bac3100#SAPEngine_Application_Thread[impl:3]_29##0#0#Path##Plain###Exiting method#
    Please let me know anyone has come accross the problem or has idea how to solve it. Thanks.

    Hi,
    Ask ur basis admin to restart JMS adpater From Vis administrator and try again to activate the comm channel.
    Hope this will solve ur problem and once again check connection fatcory and Queue name provided by Webmethod admin.
    Regards,
    Srini

  • JMS Queue

    Can anyone help me on this error:
    Serverjava.lang.ClassCastException: com.evermind.server.jms.EvermindConnectionFactory
    I got the above exception while trying to connect to JMS server (in OC4J 9.0.4) with the following code:
    ctx = new InitialContext();
    qconFactory = (QueueConnectionFactory) ctx.lookup("jms/ConnectionFactory");
    I am using standard jms Queue interfaces and classes.
    This is the jms.xml setup in OC4J 9.0.4:
    <queue name="Locker"
    location="Locker">
    <description>Queue for DB Lock</description>
    </queue>
    <queue-connection-factory
    name="jms/QueueConnectionFactory"
    location="jms/QueueConnectionFactory" />

    Sorry. It is my mistake.
    I used the wrong name of JMS connection factory:
    qconFactory = (QueueConnectionFactory) ctx.lookup("jms/ConnectionFactory");
    It should be like this:
    qconFactory = (QueueConnectionFactory) ctx.lookup("jms/QueueConnectionFactory");
    Because my jms.xml setting is using :
    <queue-connection-factory name="QueueConnectionFactory"
    location="jms/QueueConnectionFactory"/>

  • MDBs in 9.1 continue to consume JMS queues even after being deleted

    <b>We have an MDB application that reads a batch message off of a JMS queue, archives it in a database, parses the batch message into individual messages and writes them onto other JMS queues to be consumed by another application. Everything was running fine in Weblogic 8.1.5. However, due to problems with XA drivers and the MSDTC(predictable SQL server crashes), we decided to upgrade to Weblogic 9.1 to take advantage of the LLR option.</b>
              <b>First, we had an issue where our MDBs were causing the following exception:</b>
              <i>####<May 26, 2006 7:42:12 PM EDT> <Error> <JMX> <ist-clft2> <wltest1> <ExecuteThread: '1' for queue: 'default'> <<WLS Kernel>> <> <> <1148686932991> <BEA-149500> <An exception occurred while registering the MBean null.
              java.lang.IllegalArgumentException: Registered more than one instance with the same objectName : com.bea:ServerRuntime=wltest1,MessageDrivenEJBRuntime=RhapsodyMDB_DMBModule!JMSServer4@DMB_BEAN_QUEUE,Name=RhapsodyMDB_DMBModule!JMSServer4@DMB_BEAN_QUEUE,ApplicationRuntime=DataBrokerEAR1_2,Type=EJBPoolRuntime,EJBComponentRuntime=DataBrokerEJB new:[email protected] existing weblogic.ejb.container.monitoring.EJBPoolRuntimeMBeanImpl@7db003
                   at weblogic.management.jmx.ObjectNameManagerBase.registerObject(ObjectNameManagerBase.java:146)
                   at weblogic.management.mbeanservers.internal.WLSObjectNameManager.lookupObjectName(WLSObjectNameManager.java:133)
                   at weblogic.management.jmx.modelmbean.WLSModelMBeanFactory.registerWLSModelMBean(WLSModelMBeanFactory.java:86)
                   at weblogic.management.mbeanservers.internal.RuntimeMBeanAgent$1.registered(RuntimeMBeanAgent.java:104)
                   at weblogic.management.provider.internal.RegistrationManagerImpl.invokeRegistrationHandlers(RegistrationManagerImpl.java:205)
                   at weblogic.management.provider.internal.RegistrationManagerImpl.register(RegistrationManagerImpl.java:85)
                   at weblogic.management.runtime.RuntimeMBeanDelegate.register(RuntimeMBeanDelegate.java:320)
                   at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:257)
                   at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:222)
                   at weblogic.ejb.container.monitoring.EJBPoolRuntimeMBeanImpl.<init>(EJBPoolRuntimeMBeanImpl.java:32)
                   at weblogic.ejb.container.monitoring.MessageDrivenEJBRuntimeMBeanImpl.<init>(MessageDrivenEJBRuntimeMBeanImpl.java:49)
                   at weblogic.ejb.container.manager.MessageDrivenManager.initialize(MessageDrivenManager.java:503)
                   at weblogic.ejb.container.manager.MessageDrivenManager.setup(MessageDrivenManager.java:120)
                   at weblogic.ejb.container.manager.MessageDrivenManager.setup(MessageDrivenManager.java:146)
                   at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl.createMDManager(MessageDrivenBeanInfoImpl.java:1481)
                   at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl.createDDMDManagers(MessageDrivenBeanInfoImpl.java:1378)
                   at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl.onDDMembershipChange(MessageDrivenBeanInfoImpl.java:1285)
                   at weblogic.jms.common.CDS$DD2Listener.listChange(CDS.java:454)
                   at weblogic.jms.common.CDSServer$DDHandlerChangeListener.statusChangeNotification(CDSServer.java:167)
                   at weblogic.jms.dd.DDHandler.callListener(DDHandler.java:318)
                   at weblogic.jms.dd.DDHandler.callListeners(DDHandler.java:344)
                   at weblogic.jms.dd.DDHandler.run(DDHandler.java:282)
                   at weblogic.jms.common.SerialScheduler.run(SerialScheduler.java:37)
                   at weblogic.work.ExecuteRequestAdapter.execute(ExecuteRequestAdapter.java:21)
                   at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:145)
                   at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
              >
              ####<May 26, 2006 7:42:13 PM EDT> <Info> <EJB> <ist-clft2> <wltest1> <ExecuteThread: '1' for queue: 'default'> <<WLS Kernel>> <> <> <1148686933069> <BEA-010060> <The Message-Driven EJB: RhapsodyMDB has connected/reconnected to the JMS destination: weblogic.jms.DMB_BEAN_QUEUE.></i>
              <b>
              Generally this happend after there were cluster communication issues. Multi-cast messages were lost and our MDB reconnects to the JMS queues as indicated by the below log:</b>
              <i>####<May 30, 2006 5:19:06 PM EDT> <Info> <EJB> <AMTC-RAP-STG3> <RAPBEA1S> <[ACTIVE] ExecuteThread: '54' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1149023946040> <BEA-010060> <The Message-Driven EJB: DataBrokerMDB has connected/reconnected to the JMS destination: weblogic.jms.PHINMS_DMB_QUEUE.>
              ####<May 30, 2006 5:19:10 PM EDT> <Info> <Cluster> <AMTC-RAP-STG3> <RAPBEA1S> <[ACTIVE] ExecuteThread: '22' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1149023950228> <BEA-000112> <Removing RAPBEA3S jvmid:720875810499147484S:cmts-rap-bea3:[7005,-1,-1,-1,-1,-1,-1]:DMBstg:RAPBEA3S from cluster view due to timeout.>
              ####<May 30, 2006 5:19:11 PM EDT> <Info> <Cluster> <AMTC-RAP-STG3> <RAPBEA1S> <[STANDBY] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1149023951009> <BEA-000115> <Lost 2 multicast message(s).>
              ####<May 30, 2006 5:19:11 PM EDT> <Info> <Cluster> <AMTC-RAP-STG3> <RAPBEA1S> <[ACTIVE] ExecuteThread: '22' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1149023951040> <BEA-000111> <Adding RAPBEA3S with ID 720875810499147484S:cmts-rap-bea3:[7005,-1,-1,-1,-1,-1,-1]:DMBstg:RAPBEA3S to cluster: DMBstg_cluster view.></i>
              <b>
              This would cause the queues to eventually have hundreds of consumers and cause the server to fail.
              Basically, it seems as though the MDBs that are supposed to stop continue and attempt to process, while new threads connect to the JMS queues.
              I tried undeploying our application and deleted it from the configuration. However there were consumers still on the respective queues and when I sent messages, I got an error indicating a "Class Not Found exception" due to the fact that the EJB was undeployed and deleted from the configuration, however the MDB component was not and continued to listen for messages. In 8.1.5, as soon as the application was undeployed, there were zero consumers on the JMS queues.
              I have read the posts about a soon to be released fix that would have the MDBs connect only to the queues locally and not go out the the cluster. Would this fix my issue?
              Is there something in the deployment descriptor to configure that will cause it to disconnect and now spawn so many consumers to the JMS queues?
              Why is it that the number of MDB consumers on the JMS queues stayed static in 8.1.5, but they are erratic in 9.1 even after I set our 9.1 server to use the 8.1.5 execute queue policy. Help would be much appreciated.</b>

    I recommend contacting customer support. There's a known problem with MDBs listening to distributed destinations that are local to the same cluster as the MDB, you're problem may be related (the clue is that the stack trace contains jms.dd.DDHandler.callListeners()). The problem is that the MDB connects to all physical queues in a distributed destination rather than just the local queue.
              Tom

  • Always selecting the local JMS in a cluster, is it possible? (in 6.1)

    Hi,
              A 6.1 cluster has a JMS server running on each node. The JMS client
              code has a component to do the fail over "manually": it tries one
              node, if that doesn't work it tries the next and so on. The
              destination names are different (and replicated in the JNDI tree).
              If everything is ok, all requests go the first server (meaning network
              traffic). Is there an elegant way to always try with the local JMS
              server before the remote ones, without minimum configuration
              dependency (i.e. no system properties passed at start-up telling what
              JMS servers to use and so on)
              Perhaps something using JMSDestinationRuntimeMBean and
              JMSServerRuntimeMBean?
              Oh, just noticed JMSRuntimeMBean.html.getJMSServers(), this might do
              it. I'll post it nonetheless in case other people have better ideas.
              Thanks.
              

    Thanks again.
              In fact, if I use the server/queue syntax, I can use the queue name
              (the Name attrribute) not the JNDI name. This in case these names can
              be the same in a cluster deployment (with replicated JNDI names
              different). I'll check soon.
              Regarding the connection factory, I wonder whether WL doesn't do its
              otherwise typical performance improvements and return a local
              connection if there is one (as it already does with remote
              interfaces). I couldn't find a reference to such an optimization in
              the JMS documentation, though.
              On Wed, 17 Apr 2002 09:37:59 -0400, Tom Barnes
              <[email protected]> wrote:
              >email wrote:
              >
              >> Thank you. The second option looks better than the first because it
              >> allows using destinations on other JMS servers (by interrogating an
              >> MBean to get the JMS servers in the cluster).
              >
              >The second option only works if the connection is already connected
              >to the correct server. If you use mbeans, you can glean the URL
              >of the correct server by obtaining the IP and address of the remote
              >server from the ServerMBean - the "target" of the JMSServerMBean.
              >
              >An issue with this feature is the connection factory - which round-robins the
              >location of connection in certain cases. Currently the only way to ensure the
              >connection
              >factory does not do this is to target it at a single server. I suppose one
              >could duplicate the connection factory and target each duplicate at
              >a different server, but that requires giving each one a different name.
              >This may not be an issue with server-side contexts, I will investigate.
              >
              >
              >> It's useful to know
              >> about JNDINameReplicated, but that way accessing a remote destination
              >> will not be possible at all.
              >>
              >
              >I think you could write a small a startup class to look up the queue in the
              >local context and register the queue in a
              >replicated context with a different JNDI name. This way the destination
              >is advertised both ways. Fairly sure this would work.
              >
              >>
              >> BTW, a related question on reliability: accessing a remote destination
              >> if the local is down means there is a local problem with the JMS
              >> server or the queue, but the container is fine. Now, how likely is
              >> this in practice? Having the container up but the JMS subsystem down.
              >>
              >
              >Parts (or all) of JMS can fail due to configuration
              >errors -- commonly JNDI name collisions of destinations and/or factories,
              >failure to set the target, or using the same server name or jms server name
              >on two different servers.
              >
              >If you are using a file-store, boot failures occur with things
              >like file-store not found, or relatively catastrophic failures like
              >out-of-memory.
              >
              >If you are using a JDBC store, there is a dependency on the database being up.
              >
              >
              >>
              >> Indeed, 7.0 would solve it but that's several months ahead if I
              >> understand correctly:)
              >>
              >
              >Not months. Weeks. A very few weeks. I'm not sure what is officially
              >announced
              >so I can't get more specific.
              >
              >>
              >> Thanks again.
              >>
              >> On Tue, 16 Apr 2002 14:48:02 -0400, Tom Barnes
              >> <[email protected]> wrote:
              >>
              >> >Consider the new "JNDINameReplicated" configuration parm on the
              >> >destination. Ensure each server running 6.0SP2 with patch CR061106, or
              >> >6.1SP3 (not out yet) and later, or 7.0. Configure each queue to have the
              >> >same JNDI name, and also take care to set the destination’s new
              >> >“JNDINameReplicated” parameter to false. This turns off name
              >> >replications, so the JNDI name of the dest is only visible on the server
              >> >local to the context.
              >> >
              >> >Consider naming all destinations the same and looking them up the dest via
              >> >session.createQueue("./queuename"), this is a new syntax that restricts
              >> >the lookup to the same server as the one the JMS connection is talking
              >> >to. The normal syntax is "servername/queuename". This feature is
              >> >slated for 6.1SP3, no guarantees, (or try ask customer support to get this
              >> >feature in early as a patch, no guarantees there either), or 7.0.
              >> >
              >> >Consider not rolling your own and using 7.0, which has a rich distributed
              >> >destination feature built in.
              >> >
              >> >Tom
              >> >
              >> >email wrote:
              >> >
              >> >> Hi,
              >> >>
              >> >> A 6.1 cluster has a JMS server running on each node. The JMS client
              >> >> code has a component to do the fail over "manually": it tries one
              >> >> node, if that doesn't work it tries the next and so on. The
              >> >> destination names are different (and replicated in the JNDI tree).
              >> >>
              >> >> If everything is ok, all requests go the first server (meaning network
              >> >> traffic). Is there an elegant way to always try with the local JMS
              >> >> server before the remote ones, without minimum configuration
              >> >> dependency (i.e. no system properties passed at start-up telling what
              >> >> JMS servers to use and so on)
              >> >>
              >> >> Perhaps something using JMSDestinationRuntimeMBean and
              >> >> JMSServerRuntimeMBean?
              >> >>
              >> >> Oh, just noticed JMSRuntimeMBean.html.getJMSServers(), this might do
              >> >> it. I'll post it nonetheless in case other people have better ideas.
              >> >>
              >> >> Thanks.
              >> >
              >
              

  • Single MDB on a clustered JMS queues(2)

    I have 2 JMS servers in a cluster and each server has a JMS queue, which forms the distributed destination. Now I need a MDB to listen on both these queues. Is it possible?
    Thanks
    -Ankur

    Yes - thats the usual purpose of distributed queues, to allow consumers to consume from the distributed queue (wherever its hosted).
    Though distributed destinations are JMS provider specific so do check your providers documentation on using distributed queues. In some providers, like ActiveMQ, distributed queues look and act just like regular queues so they just work from inside a JMS client or MDB.
    James
    http://logicblaze.com/

  • Looking up a distributed queue with two persistent stores using two JMS Svr

    I am trying to do the following:
    1. Setup a distributed queue, i have two servers which are part of the cluster:
    Server A: t3://localhost:7003
    Server B: t3://localhost:7005
    I go in and create two jms servers:
    JMS Server JA: Target on Server A
    JMS Server JB: Target on Server B
    Now as the jms servers need to use a seperate persistent store for each one of them i create two persistent stores.
    2. Now from my MDB which is deployed on another server i lookup the queue using
    t3://localhost:7003,localhost:7005 as the provider url
    My problem is that i always end up listening to the messages on the first jms server and never get to read the messages on jms server JB as i guess i am able to connect to JMS Server JA so i never try and connect to JB? What to do about this?
    Edited by: user4828945 on Mar 23, 2009 2:32 PM

    Allocation of consumers wouldn't take into account the number of messages on the queue - they'd be allocated randomly. The scenario you're proposing shouldn't happen though - WebLogic Server takes into account whether a member has consumers when sending to a distributed destination, but otherwise, assuming that Queue 1 and Queue 2 both have consumers, then distribution of load will be equal. It's not the amount of consumers that determine how many messages get sent to a distributed destination member - it's whether it has members at all.
    Assuming that did occur initially though, you'd expect processing to be a little bit more intensive on the server with the queue holding 30 messages. It would pretty quickly even up though.
    From that point forward, it would be somewhere between difficult and impossible to get to the second scenario, where you have an unequal number of messages in each distributed destination member, unless the work being sent with each message to an MDB can vary significantly in how long it would take to process.
    Assuming (and it's a big if) you could get to that scenario, then the MDBs wouldn't switch over - they stay connected to a particular distributed destination member. And it's their connection to a member as a consumer that controls how WebLogic Server load balances messages (assuming default configuration) so that's part of what makes it unlikely to get there.
    From going back to first principles in the documentation, it seems like your best result would actually be from deploying the MDB to the cluster - that way, there's no remote connections to JMS queues, and you get a pool of MDBs on each server instance.
    Ref here: http://e-docs.bea.com/wls/docs81/ejb/message_beans.html

  • Injecting JMS Queue / Destination into MDB fails

    I am trying to inject a Destination into an EJB3 MDB using
        @Resource(name = "queue/abc/Responses")
        private Destination m_responseQueue;In the ejb-jar.xml file I declare the following
          <message-driven>
                <ejb-name>JobRequestListener</ejb-name>
                <ejb-class>com.abc.backend.jobs.JobRequestListener</ejb-class>
                <message-destination-link>JobRequests</message-destination-link>
                <!--Inherited From AbstractManagedBean -->
                <resource-ref>
                    <res-ref-name>jms/ConnectionFactory</res-ref-name>
                    <res-type>javax.jms.ConnectionFactory</res-type>
                    <res-auth>Container</res-auth>
                </resource-ref>
                <!--Local Resources -->
                <message-destination-ref>
                    <message-destination-ref-name>queue/abc/Responses</message-destination-ref-name>
                    <message-destination-type>javax.jms.Queue</message-destination-type>
                    <message-destination-usage>Produces</message-destination-usage>
                    <message-destination-link>Responses</message-destination-link>
                </message-destination-ref>
            </message-driven>and in weblogic-ejb-jar.xml I add
        <weblogic-enterprise-bean>
            <ejb-name>JobRequestListener</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>queue/abc/JobRequests</destination-jndi-name>
            </message-driven-descriptor>
            <transaction-descriptor>
                <trans-timeout-seconds>315</trans-timeout-seconds>
            </transaction-descriptor>
            <!--Inherited From AbstractManagedBean -->
            <resource-description>
                <res-ref-name>jms/ConnectionFactory</res-ref-name>
                <jndi-name>jms/ABCConnectionFactory</jndi-name>
            </resource-description>
            <!--Local Resources -->        
            <resource-description>
                <res-ref-name>queue/abc/Responses</res-ref-name>
                <jndi-name>queue/abc/Responses</jndi-name>
            </resource-description>
        </weblogic-enterprise-bean>Initially I didn't have the resource-description in the weblogic-ejb-jar.xml file, but even after adding it I am still getting the following exception during deployment
    [EJB:011026]The EJB container failed while creating the java:/comp/env namespace for
    this EJB deployment. weblogic.deployment.EnvironmentException:
    [EJB:010176]The resource-env-ref 'queue/abc/Responses' declared in the ejb-jar.xml
    descriptor or annotation has no JNDI name mapped to it. The resource-ref must
    be mapped to a JNDI name using the resource-description element of the
    weblogic-ejb-jar.xml descriptor or corresponding annotation.
         at weblogic.ejb.container.deployer.EnvironmentBuilder.addResourceEnvReferences(EnvironmentBuilder.java:639)
         at weblogic.ejb.container.deployer.EJBDeployer.setupEnvironmentContext(EJBDeployer.java:247)
         at weblogic.ejb.container.deployer.EJBDeployer.setupEnvironmentFor(EJBDeployer.java:1014)
         at weblogic.ejb.container.deployer.EJBDeployer.setupBeanInfos(EJBDeployer.java:908)
         at weblogic.ejb.container.deployer.EJBDeployer.prepare(EJBDeployer.java:1188)
         at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:425)By injecting a Queue rather then a destination I can work around this issue, however I would prefer to use a Destination as this allows me to change the behavior of my application without making code changes. It seems like a bug in 10.3 to me.
    Edited by: ejb3workshop on Sep 1, 2009 1:44 PM
    Edited by: ejb3workshop on Sep 1, 2009 1:59 PM
    Edited by: ejb3workshop on Sep 2, 2009 3:11 PM

    Because JMS resources by the very nature are "undependable", I think it is usually not advisable to inject JMS resources into an EJB except for MDB source destinations. The problem with injection of JMS resources is that if the JMS resource is not available at the point the EJB is originally deployed/initialized, the EJB deployment/initializaition will fail (except for MDBs, which will still deploy if the source is down, and will automatically retry internally). This is goodness for many types of resources, but since JMS resources are not necessarily always available by their very nature (down for maintenance, in the middle of a migration, initializing later in the boot, etc), most messaging applications should be specifically designed to be robustly handle the failure case during runtime.
    Anyhow, EJB3 does not require descriptors.
    I haven't fully vetted the following samples, but I think they should be pretty close to correct.
    Sample MDB code:
    // MDB will still deploy even if the source destination is down (the container will keep retrying internally).
    @MessageDriven(mappedName = "Server1Q1",
                            activationConfig = {@ActivationConfigProperty(
                                                          propertyName = "connectionFactoryJndiName",
                                                          propertyValue = "Server1CF")})
    public class MyMDB implements MessageListener {
      @EJB
      private MyStateless myStateless;
      @TransactionAttribute(TransactionAttributeType.REQUIRED)
      public void onMessage(Message message) {
        System.out.println("Got the message, version 5: "+message);
        myStateless.completeWorkOrder();
    Sample injected JMS resources - no resource descriptors needed:
    @Stateless(mappedName="StatelessBean")
    public class MyStatelessBean implements MyStateless {
      int ctr;
      @Resource(mappedName="mdbq2")
      private Queue queue1;
      @Resource(mappedName="cfadmin2")
      private QueueConnectionFactory connectionFactory2;
    Sample pseudo-code for non-injected JMS resources, no resource descriptors needed:
    Eg, instead of
    @Resource(mappedName="cfadmin")
    private QueueConnectionFactory cf;
    Do this:
      // note the semi-colon!  turns off injection, note the type field -- required
      // I'm not sure of exact syntax
      //cfadmin is assumed to be the JNDI name if the
      // JNDI name isn't specified in another parameter... 
      @Resource(mappedName="cfadmin", type="javax.jms.QueueConnectionFactory");  
      // this is not injected now
      // cache cf for re-use (performance)
      private QueueConnectionFactory cf;
      @Resource
      private SessionContext sctx;  // inject the session ctx
    And in the source code itself, do this:
       int tryCount == 3; 
       while (cf != null) {
         try { 
           // not quite sure if this is the righ syntax, but I think "java:/comp/env" prefix
           // isn't needed for the new EJB3.0 session context
           cf = sctx.lookup("cfadmin");  //cfadmin is mappedname for resource above
         } catch (NNN n) {  // don't know the exact exception
           if (--tryCount == 0) throw n;
           sleep 3 seconds  // don't want to retry in a tight loop
    Tom

  • Using a  foreign WLS JMS queue (no bridge)

              Hi,
              We have a configuration from which we communicate from WLS 7 to a foreign MQ via
              JMS. This works well and we have loaded the foreign MQ jms objects into WLS JNDI
              using a statup class (as the whitepaper available describes) and we look them
              up successfully.
              However, we now have a siutation where we briefly need to switch our application
              to point to a WLS JMS queue on another remote WLS server. Is there an easy way
              to load foreign (maybe remote would be a better word in this case) WLS JMS QCF's
              and destinations into my local WLS JNDI so that I can treat them the same way
              as my MQ objects?
              I can't seem to find any information on how to do this as all information seems
              to point towards the messaging bridge (we can't use this as the bridge changes
              the message JMSMessageID and screws our correlation mechanism up).
              I know we could just look the foreign objects up by using the JNDI environment
              of the remote WLS machine but this would mean changing code and this I can't to
              do (as all our code uses the local default WLS JNDI).
              Any ideas would be gratefully received.
              Cheers,
              Jay.
              

    WLS JMS and MQ JMS handle their JNDI objects a little differently, so I can
              see how this can be confusing. An MQ JMS "ConnectionFactory" or
              "Destination" object is like a little configuration file that tells you
              where the queue manager or queue is, so you can serialize it and look it up
              later and use it to find the queue manager.
              A WLS JMS ConnectionFactory or Destination object is a reference to an
              object on a running server. So, you connect to the server and look them up,
              and then you can use it for messaging. You don't have to store these objects
              in a separate place, like MQ makes you do. But it means that the WLS JNDI
              objects have to be looked up from a running server, and if the server
              restarts, you have to look them up again.
              Doing what you're asking is definitely trickier in 7.0. One thing you could
              do is, again using a servlet or an EJB, connect to the remote JMS cluster
              and look up the objects at the time you want to make the switch. (If the
              remote cluster is down, you'll have to retry from time to time.) If the
              remote cluster is down, you won't be able to look up those objects, but then
              again, if it were down you wouldn't be able to send messages there anyway.
              Using 8.1 would be less complicated, but this method should also work.
              greg
              "Jay Green" <[email protected]> wrote in message
              news:[email protected]...
              >
              > Thanks Greg. When I was searching the BEA website I read about the
              facility in
              > 8.1. Unfortunatley, as you point out, it doesn't help me much with WLS
              7.0.
              >
              > My first thought was to copy my exisiting MQ startup class but I couldn't
              work
              > out how to do this for the remote WLS jms objects as the standard jms
              classes
              > (for QCF etc) don't have methods that allow me to define the foreign WLS
              jms
              > host IP address etc. I checked the WLS 7 API and the jms package didn't
              seem
              > to offer anything to help me do this (as IBM do for MQ). Any ideas?
              >
              > Apologies if I'm being a bit slow here!
              >
              > "Greg Brail" <[email protected]> wrote:
              > >WLS 8.1 includes a feature called "Foreign JMS Providers" that lets you
              > >configure (using the console or config.xml) a link between a JMS JNDI
              > >object
              > >in your WLS servers' tree, and a JNDI object in another provider -- which
              > >could be WLS JMS, or a foreign vendor.
              > >
              > >Using this feature, your application could just look up the local JNDI
              > >objects in the local WLS tree, and then the server in turn performs the
              > >lookup from the actual JNDI provider using the parameters you put in
              > >the
              > >console (or config.xml). So, when you make a change in the console, new
              > >JNDI
              > >lookups will go to the new place.
              > >
              > >Unfortunately, this doesn't help you with 7.0. You could always
              > >programmitically update the local JNDI tree the way you're doing in your
              > >startup class, but instead do it from a servlet or an EJB.
              > >
              > > greg
              > >
              > >"Jay Green" <[email protected]> wrote in message
              > >news:[email protected]...
              > >>
              > >> Hi,
              > >>
              > >> We have a configuration from which we communicate from WLS 7 to a
              foreign
              > >MQ via
              > >> JMS. This works well and we have loaded the foreign MQ jms objects
              > >into
              > >WLS JNDI
              > >> using a statup class (as the whitepaper available describes) and we
              > >look
              > >them
              > >> up successfully.
              > >>
              > >> However, we now have a siutation where we briefly need to switch our
              > >application
              > >> to point to a WLS JMS queue on another remote WLS server. Is there
              > >an easy
              > >way
              > >> to load foreign (maybe remote would be a better word in this case)
              > >WLS JMS
              > >QCF's
              > >> and destinations into my local WLS JNDI so that I can treat them the
              > >same
              > >way
              > >> as my MQ objects?
              > >> I can't seem to find any information on how to do this as all
              information
              > >seems
              > >> to point towards the messaging bridge (we can't use this as the bridge
              > >changes
              > >> the message JMSMessageID and screws our correlation mechanism up).
              > >>
              > >> I know we could just look the foreign objects up by using the JNDI
              > >environment
              > >> of the remote WLS machine but this would mean changing code and this
              > >I
              > >can't to
              > >> do (as all our code uses the local default WLS JNDI).
              > >>
              > >> Any ideas would be gratefully received.
              > >>
              > >> Cheers,
              > >>
              > >> Jay.
              > >
              > >
              >
              

  • MDB,MDB container or JMS adapter stops processing messages from JMS queue

    Hi guys,
    we have created a component using Enterprise Java Beans, let's say a product catalog, deployed it on a Glassfish v2 instance, and connected it to a legacy system using JMS and Sun MQ v4.1 as messaging system. The catalog component thus starts one MDB that listens on a JMS queue, let's say a queue named catalog_business_events_in, and waits for incoming messages, i.e. in our case update events. The problem is, that in general this approach works well, but sometimes the MDBs/JMS adapter stops for some reason fetching and processing messages from the JMS queue. We don't know why - no exceptions, etc.. Seems to be a Glassfish EJB container, JMS adapter or Sun MQ configuration issue. It seems to be that our component is not the problem.
    The messages are compressed/uncompressed by Sun MQ automatically. We actually have 2 Sun MQ instances in clustered mode running to have some kind of failover - no HA cluster, yet. Sun MQ instances are accessed from Glassfish instances running in different Glassfish clusters - so we have a dedicated Sun MQ cluster not a Sun MQ instance per Glassfish instance. Each Glassfish instance is configured such that it knows both Sun MQ instances to allow automatic failover.
    Has someone an idea, why the MDBs/ MDB container/ JMS adapter - stops processing messages? We are kind of puzzled as it happens more often now and apparently when traffic is (very) low not high!
    Thanks for your help.
    Cheers,
    Martin
    Edited by: east1979 on Jan 13, 2009 8:06 AM

    Hi Manoj,
    I have a very similar if not identical issue,
    Error while running realtime jobs that read from JMS tables via JMS MQ adapter:
    15/11/12 09:10:08  JMS GET OPERATION ERROR : TIMEOUT.UNABLE TO RECEIVE RESPONSE FROM THE INVOKED DATA SERVICES SERVICE.ADAPTER OPERA
    TION TO CONTINUE.
    15/11/12 09:10:15  Communication Error. See real time job log for details.
    Dump available:
    https://sapmats.wdf.sap.corp/download/download.cgi?id=5C0KZAHA3RSXBJW3ABLMUUT2P5UUKWO2TM3EJDM5W2HGDZUDID
    Version of DS:14.0.3.273
    Any comments?
    Thansk and kind Regards,
    Kenneth

Maybe you are looking for

  • Memory speed 5900 XT

    Why I can't overclock the memory clock of my GFX 5900XT at more than 740Mhz... When the card memory is set at more than 740Mhz some triangles appear in the screen while 3Dmark 03 or some games are running. What i need.... a better power supply or som

  • CANNOT DOWLOAD I TUNES WITH WINDOWS VISTA HELP!!!!!!!!!!!!!!

    I hav e just tried to download i tunes to use my new i pod and have way through the download i receive this message iNTERNET EXPLORER CANNOT DOWNLOAD ITUNESSETUP.EXE FROMAPPLDNLD.APPLE.COM.EDGE SUITE.NET. tHE CONNECTION WITH THE SERVER WAS RESET. Ple

  • System preferences won't work

    only opens to auto fill

  • How to change schedule line fields when save sales documents in va01/va02

    Hi, every Experts, I want to change schedule line when save the sales documents in va01 or va02, such as change delivery block or schedule line category. of course, can use user exit USEREXIT_SAVE_DOCUMENT_PREPARE, but I do not know to use this user

  • CRM Support Package Manager - Add transport request to queue

    Hi, I'm applying CRM Support Packages with SP_MANAGER on the production system. I already applied these SP on the development system, I performed an SPAU adjustment, selected the corresponding transport request to use it on the production system, but