JMS Distributed Destination Topic - how to avoid MDB to recieve duplicates

HELP!!
I have spent a lot of time looking for an option to move jms on a cluster, finally I can do this using distributed destination, I have two memmbers(Topic) in the distributed destination topic, but when both of them are active, the Message Driven Bean which is deployed on cluster recieves 2 messages instead of 1, anyone please help me to change this to have only one message instead of 2 !!!!!

Make it a Queue or don't deploy the MDB to the cluster. You are seeing
          expected behavior. I have the same situation with a Topic and I deploy my
          MDB to one node in the cluster and have it configured to consume the local
          physical Topic.
          Bill
          "Manav Sehgal" <[email protected]> wrote in message
          news:18024883.1107530318601.JavaMail.root@jserv5...
          > HELP!!
          > I have spent a lot of time looking for an option to move jms on a
          > cluster, finally I can do this using distributed destination, I have two
          > memmbers(Topic) in the distributed destination topic, but when both of
          > them are active, the Message Driven Bean which is deployed on cluster
          > recieves 2 messages instead of 1, anyone please help me to change this to
          > have only one message instead of 2 !!!!!

Similar Messages

JMS Distributed Destinations as proxy service endpoints

We have a cluster of 2 ALSB servers with a proxy service deployed
listening on a JMS queue which is a distributed destination (DD) on a
WLS 8.1 system.
The JMS DD is spread across 4 JMS servers and 4 JVM's.
When ALSB starts up - we only get consumers on 2 of the 4 DD members,
which makes sense as a JMS proxy service is essentially an MDB, and this
is normal MDB/distributed destination behaviour - it will bind to the
queue member where it first makes the connection to the JVM.
How do I make sure my messages are consumed from all 4 DD queue members?
There is a JMS option to forward messages to queues with consumers if no
consumers exist - is that the way to do it?
Someone must have come across this before and I'd be grateful for any
advice.
Also - how do you reduce the consumers on the JMS queue - seems to
default to 16. Perhaps you don't.
Thanks,
Pete

Meghan Pietila wrote:
Update: I see your exchange with Tom over on the JMS forum, Pete. We just switched everything to WLS 9.2, so maybe the ALSB internal extension will work for us. It's not working by default, so possibly it's something that must be activated... I'll follow up with BEA.
http://forums.bea.com/thread.jspa?threadID=570001317
I'd still like to hear what you end up working with, if you don't mind sharing once it's running. :)
MeghanI only have 8.1 as an option - a JMS proxy service is essentially an
MDB, and if you deploy an MDB in the same way, it will only bind to a
single destination, so it's actually behaving as I would expect.
The forward delay on the queue probably won't be an issue for us, as
we're not talking about high volumes and large messages, but for some
sites there will be alot of moving around queues, access jms filestore
etc which you could do without.
I reckon the trick is (as Tom mentioned) to bind to individual
distributed queue members from the proxy service somehow.
I'll let you know what I find out.
Pete

JMS distributed destination

In Bea's WLS 7.0 JMS: "Looking up Distributed Topics" and "Deploying Message-Drive
Beans on a Distributed Topic" :
http://e-docs.bea.com/wls/docs70/jms/implement.html#1260828
This sound like each message(topic) gets sent to all members of a distributed
topic.
Then in the same doc for LB, a couple paragraphs down we have a conflict explaination:
"In the round-robin algorithm, WebLogic JMS maintains an ordering of physical
destinations within the distributed destination. The messaging load is distributed
across the physical destinations one at a time in the order that they are defined
in the WebLogic Server configuration (config.xml) file. "
If a topcs sent to a distributed topic will be sent to all physical destinations,
why we need LB here. Or the LB is applied to distributed Queue only.
Please comments.
THX.
-John

Rob,
Not a expert I must admit, but the link provided by you states "A distributed destination is a set of destinations (queues or topics) that are accessible as a single, logical destination to a client. A distributed destination has the following characteristics:
It is referenced by its own JNDI name."
You can actually configure JMS adapters using JNDI so I think this should be possible. More info here,
http://help.sap.com/saphelp_nw04/helpdata/en/c1/739c4186c2a409e10000000a155106/content.htm
Do let us know if this helps and works!
Regards
Bhavesh

How i can implement in 6.0 the JMS Distributed Destination feature of 7.0 ?

          Hi all,
          Peace,
          Juan Alonso.


Hi Juan,
          Check out the jms performance whitepaper posted on dev2dev, or find
          attached to post:
          http://newsgroups.bea.com/cgi-bin/dnewsweb?utag=&group=weblogic.developer.interest.jms&xrelated=9372&cmd_thread_last.x=42&cmd_thread_last.y=8
          It contains a section on emulating 7.0 distributed queues in 6.1.
          Also check out the newsgroup thread on "Approximating Distributed Queues
          In 6.1".
          http://newsgroups.bea.com/cgi-bin/dnewsweb?cmd=article&group=weblogic.developer.interest.jms&item=9415&utag=
          It extends the above whitepaper to cover topics...
          I think you may need 6.1, an easy upgrade from 6.0.
          Tom
          Juan Alonso wrote:
          > Hi all,
          >
          > Peace,
          >
          > Juan Alonso.

Distributed destination with MQ as Foreign Provider

Hi
          Messages arrive in a set of clustered MQ Series Queues. MDBs process the messages (We use MQ as the Foreign JMS Provider). Can I set up a distributed destination (JMS Queues) in WebLogic and use those clustered MQ queues as the Foreign Provider ? I would like the MQ Series clustering to provide the redundancy/availability of the MQ Series system and the JMS distributed destination to provide high availability for the MDBs that are hosted in a set of clustered WebLogic server instances.
          Thanks

Hi          > Messages arrive in a set of clustered MQ Series
          > Queues. MDBs process the messages (We use MQ as the
          > Foreign JMS Provider). Can I set up a distributed
          > destination (JMS Queues) in WebLogic and use those
          > clustered MQ queues as the Foreign Provider ?
          No. WL distributed destinations consist only of a set of physical WL destinations. The WL distributed destination code does not support non-WL destinations.
          > I would
          > like the MQ Series clustering to provide the
          > redundancy/availability of the MQ Series system and
          > the JMS distributed destination to provide high
          > availability for the MDBs that are hosted in a set of
          > clustered WebLogic server instances.
          If MQ Series exposes its distributed destination via the standard JMS API, then the MDBs will automatically run as MQ distributed dest clients. This is a function of MQ, not WL -- WL MDBs simply use the standard JMS API of the vendor's supplied client to get their messages.
          But note that WL MDBs use a single connection per MDB pool/deployment. Some clustering implementations (MQ?) require using multiple connections...
          >
          > Thanks

JMS Failover with Distributed Destinations in 7.0

          How does JMS failover with distributed destinations in WL 7.0?
          In an environment using file stores for persistent messages, can a working server
          automatically pick up unprocessed and persisted messages from a failed server?
          If so, what's the best way to set this up?
          Or, is this completely manual? In other words, we have to bring up a new server
          pointing to the location of the file store from the failed server?


          It appears that two JMSServers cannot share the same file store and, I'm assuming,
          two file stores cannot be using the same directory for persistence.
          So the HA you're talking about is something like Veritas automatically restarting
          a server (or starting a new one) to process the messages in the persistent queue
          that were unprocessed at the time of failure with the file store residing on some
          sort of HA disk array.
          The key point is that a message once it arrives at a server must be processed
          by that server or, in the case of failure of that server, must be processed by
          a server similarly configured to the one that failed so that it picks up the unprocessed
          messages. The message can't be processed by another server in the cluster.
          Or, is there some trick that could be employed to copy from the file store of
          the failed server and repost the messages to the still operating servers?
          "Zach" <[email protected]> wrote:
          >Unless you have some sort of HA framework/hardware, this is a manual
          >operation. You either point to the existing persistent storage (shared
          >storage or JDBC connection pool), or you move the physical data.
          >
          >_sjz.
          >
          >"Jim Cross" <[email protected]> wrote in message
          >news:[email protected]...
          >>
          >>
          >> How does JMS failover with distributed destinations in WL 7.0?
          >>
          >> In an environment using file stores for persistent messages, can a
          >working
          >server
          >> automatically pick up unprocessed and persisted messages from a failed
          >server?
          >> If so, what's the best way to set this up?
          >>
          >> Or, is this completely manual? In other words, we have to bring up
          >a new
          >server
          >> pointing to the location of the file store from the failed server?
          >
          >

How WLS makes one JMSServer leave or join a distributed destination?

HI,
          According to the WLS documents for Distributed Destination:
          When one member becomes unavalibale due a server failure, traffic is then redirected toward other avaliable destination members in the set.
          Currently, I created two queues and defined two JMS Servers (JMSServer1, JMSServer2). These two JMS Servers are in same distributed destination (JMSDes1).
          My question is
          1) when the JMSServer1 is shutdown, How WLS marked it unavaliable? And How WLS makes it leave the JMSDes1? (If you can know where I can find the documents, it will be greate).
          2) After the JMSServer1 is recycled and is active, how WLS markes it avaliable and makes it join the JMSDes1 again?
          Thanks for any help.

HI,
          According to the WLS documents for Distributed Destination:
          When one member becomes unavalibale due a server failure, traffic is then redirected toward other avaliable destination members in the set.
          Currently, I created two queues and defined two JMS Servers (JMSServer1, JMSServer2). These two JMS Servers are in same distributed destination (JMSDes1).
          My question is
          1) when the JMSServer1 is shutdown, How WLS marked it unavaliable? And How WLS makes it leave the JMSDes1? (If you can know where I can find the documents, it will be greate).
          2) After the JMSServer1 is recycled and is active, how WLS markes it avaliable and makes it join the JMSDes1 again?
          Thanks for any help.

WebLogic 10.3 jms Uniform Distributed Destination

We are running WL Server 10.3 on Suse 11.0. I have created a Cluster, Servers, JMS Servers, Connection Factory and a Distributed Destination. On the Connection Factory, I have the "Server Affinity" checkbox unchecked. Server/Cluster all look good. I am using the jmsfullclient.jar for the test.
When attempting to access the distributed destination, I get the following error on the second message. If I were to turn on "Session Affinity" in the Cluster, the problem does not arise but I lose the value of the distributed destination. Any suggestions and assistance would be appreciated.:
weblogic.jms.common.JMSException: No failover destination.
     at weblogic.jms.dispatcher.DispatcherAdapter.convertToJMSExceptionAndThrow(DispatcherAdapter.java:110)
     at weblogic.jms.dispatcher.DispatcherAdapter.dispatchSyncNoTran(DispatcherAdapter.java:61)
     at weblogic.jms.client.JMSProducer.toFEProducer(JMSProducer.java:1275)
     at weblogic.jms.client.JMSProducer.deliveryInternal(JMSProducer.java:783)
     at weblogic.jms.client.JMSProducer.sendInternal(JMSProducer.java:541)
     at weblogic.jms.client.JMSProducer.sendWithListener(JMSProducer.java:394)
     at weblogic.jms.client.JMSProducer.send(JMSProducer.java:384)
     at weblogic.jms.client.WLProducerImpl.send(WLProducerImpl.java:970)
     at com.overstock.util.Example.main(Example.java:44)
Caused by: weblogic.jms.common.JMSException: No failover destination.
     at weblogic.jms.frontend.FEProducer.pickNextDestination(FEProducer.java:750)
     at weblogic.jms.frontend.FEProducer.sendRetryDestination(FEProducer.java:1092)
     at weblogic.jms.frontend.FEProducer.send(FEProducer.java:1399)
     at weblogic.jms.frontend.FEProducer.invoke(FEProducer.java:1460)
     at weblogic.messaging.dispatcher.Request.wrappedFiniteStateMachine(Request.java:961)
     at weblogic.messaging.dispatcher.DispatcherServerRef.invoke(DispatcherServerRef.java:276)
     at weblogic.messaging.dispatcher.DispatcherServerRef.handleRequest(DispatcherServerRef.java:141)
     at weblogic.messaging.dispatcher.DispatcherServerRef.access$000(DispatcherServerRef.java:34)
     at weblogic.messaging.dispatcher.DispatcherServerRef$2.run(DispatcherServerRef.java:111)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Caused by: weblogic.messaging.dispatcher.DispatcherException: could not find Server null
     at weblogic.messaging.dispatcher.DispatcherManager.dispatcherCreate(DispatcherManager.java:176)
     at weblogic.messaging.dispatcher.DispatcherManager.dispatcherFindOrCreate(DispatcherManager.java:58)
     at weblogic.jms.dispatcher.JMSDispatcherManager.dispatcherFindOrCreate(JMSDispatcherManager.java:219)
     at weblogic.jms.dispatcher.JMSDispatcherManager.dispatcherFindOrCreateChecked(JMSDispatcherManager.java:230)
     at weblogic.jms.frontend.FEProducer.findDispatcher(FEProducer.java:825)
     at weblogic.jms.frontend.FEProducer.sendRetryDestination(FEProducer.java:995)
     ... 9 more
Caused by: javax.naming.NameNotFoundException: Unable to resolve 'weblogic.messaging.dispatcher.S:null'. Resolved 'weblogic.messaging.dispatcher'; remaining name 'S:null'
     at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:1139)
     at weblogic.jndi.internal.BasicNamingNode.lookupHere(BasicNamingNode.java:252)
     at weblogic.jndi.internal.ServerNamingNode.lookupHere(ServerNamingNode.java:182)
     at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:206)
     at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:214)
     at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:214)
     at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:214)
     at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:254)
     at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:380)
     at javax.naming.InitialContext.lookup(InitialContext.java:392)
     at weblogic.messaging.dispatcher.DispatcherManager.dispatcherCreate(DispatcherManager.java:172)
     ... 14 more
My client code is extremely basic and is the following:
public class Example {
public static void main(String args[]) {
String providerUrl = "t3://localhost:7003,localhost:7005";
Hashtable<String, String> ht = new Hashtable<String, String>();
ht.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
ht.put(Context.PROVIDER_URL, providerUrl);
InitialContext ctx = null;
try {
ctx = new InitialContext(ht);
ConnectionFactory connFactory = (ConnectionFactory) ctx
.lookup("connectionfactory");
Destination dest = (Destination) ctx.lookup("distributedqueue");
Connection conn = null;
Session session = null;
MessageProducer p = null;
try {
conn = connFactory.createConnection();
conn.start();
System.out.println("Thread:" + Thread.currentThread().getId() + " got a connection "
+ conn.hashCode());
session = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);
p = session.createProducer(dest);
System.out.println("Thread:" + Thread.currentThread().getId() + " started a connection");
for (int i = 0; i < 1000; i++) {
p.send(session.createTextMessage());
System.out.println("FinishedRunning:" + Thread.currentThread().getId());
catch (JMSException e) {
e.printStackTrace();
finally {
if (p != null) {
try {
p.close();
catch (JMSException e) {
e.printStackTrace();
if (session != null) {
try {
session.close();
catch (JMSException e) {
e.printStackTrace();
if (conn != null) {
try {
conn.close();
catch (JMSException e) {
e.printStackTrace();
catch (Exception e) {
e.printStackTrace();
Edited by: svachary on Jan 8, 2009 1:01 PM

Hi,
I would suggest you to go through these 2 links which you give all the details about UDD
Topic:Steps to Configure Uniform Distributed Queue (UDQ) on Weblogic Server
http://middlewaremagic.com/weblogic/?p=3747
Topic:JMS Demo using WebLogic Uniform Distributed Queue (UDQ)
http://middlewaremagic.com/weblogic/?page_id=1976
Tips to solve UDQ issues
- Make sure the Server Affinity Enabled parameter should be un-checked (disable) which under the [ Connection factory –> Configuration (tab) –> Load Balance (sub-tab)]
- Disable the Server Affinity Enabled parameter for the connection factory whish is been used by your UDQ.
- All the managed servers are in the same cluster.
- If the managed serves are in different boxes make sure the listing address is given correctly which is under [ Machine –> Configuration (tab) –> Node Manager (sub-tab) ]
- Test if you are able to PING the servers on different boxes and make sure that there is no network issues and you are able to communicate with the servers.
Hope this helps you.
Regards,
Ravish Mody
http://middlewaremagic.com/weblogic/
Come, Join Us and Experience The Magic…

How do you get distributed destinations to work ?

          Hi all,
          I'm trying to getting to work Distributed JMS Destinations. But
          still without success. This is the sitation:
          Node1---->JMS Server1------>Queue1 [Distributed destination1]
          Node2---->JMS Server2------>Queue2 [Distributed destination1]
          I have a cluster with 2 Nodes.
          I have created 2 JMS Servers each one targetted on one Node.
          Then I have created 2 Queues and added them to a Distributed Destination as member.
          Now I start the QueueSender (pointing to the Distributed Destination's JNDI)
          I start 2 QueueReceivers (pointing to the JNDI of the 2 Queues).
          The problem is that when one of the two nodes, let's say Node1, fails
          messages aren't dispatched to the JMS Server2.
          So I wonder: Is it possible that if one of the 2 JMS Server fails
          the message is redirected to the other JMS Server ?
          Thanks a lot
          Francesco


Receivers only load-balance once - when
          they are first created. The JMS Performance
          Guide explores the implications of this.
          Keep in mind that the distributed destination
          feature was optimized for the case where
          receivers (generally MDBs) run on the same
          servers as the distributed destination
          instances, which simply load balances each
          receiver to its local destination instance.
          Otherwise, if the receivers
          are not co-located with distributed destination
          instances, load-balancing
          configuration requires special care to prevent
          physical destinations from not getting served
          by receivers.
          One solution for the latter problem, as you
          already wrote below, is to receive directly from the
          physical destinations - which removes the
          load balancing decision all-together.
          Francesco wrote:
          > Hi,
          > thanks a lot for your clean answers.
          > Ps has anybody got an answer about my last question (That is, should I lookup
          > the JNDI
          > of the single Queue or of the Distributed Destination in order to get distributed
          > destination to work ?)
          > Thanks a lot
          > Francesco
          >
          > Tom Barnes <[email protected].bea.com>
          > wrote:
          >
          >>It is normal for a sender to get an exception
          >>when its connection's host server goes down.
          >>The client connection's host server does
          >>not change for the life of the connection,
          >>and does not automatically fail-over.
          >>Even when the client's connection host stays up
          >>but the JMSServer hosting the current
          >>distributed destination instance goes down, the sender
          >>may still get an exception. Such an exception
          >>can indicate that there is ambiguity as to
          >>whether or not the JMS server received the
          >>message from the send().
          >>
          >>The standard way to handle
          >>such exceptions is to re-establish the connection,
          >>session, and producer on the client (usually
          >>using the exact same code that initialized
          >>these resources to start with.)
          >>
          >>In addition, it is highly recommended
          >>for the client to register exception listeners
          >>on both the connection and on the WLSession.
          >>
          >>Tom
          >>
          >>Francesco wrote:
          >>
          >>
          >>>"Barry Myles" <[email protected]> wrote:
          >>>
          >>>
          >>>>Hi Francesco
          >>>>
          >>>>Try creating a connection factory that has Load balanced ticked and
          >>
          >>server
          >>
          >>>>affinity
          >>>>unticked
          >>>>
          >>>>now make sure that the distributed destinations load balancing property
          >>>>is set
          >>>>to Round Robin
          >>>>
          >>>>
          >>>>
          >>>>>I start 2 QueueReceivers (pointing to the JNDI of the 2 Queues).
          >>>>
          >>>>Also when the QueueRecievers are running do you see one consumer attached
          >>>>to each
          >>>>physical queue?
          >>>>
          >>>>HTH
          >>>>
          >>>>
          >>>>"Francesco" <[email protected]> wrote:
          >>>>
          >>>>
          >>>>>Hi all,
          >>>>>I'm trying to getting to work Distributed JMS Destinations. But
          >>>>>still without success. This is the sitation:
          >>>>>
          >>>>>Node1---->JMS Server1------>Queue1 [Distributed destination1]
          >>>>>Node2---->JMS Server2------>Queue2 [Distributed destination1]
          >>>>>
          >>>>>I have a cluster with 2 Nodes.
          >>>>>I have created 2 JMS Servers each one targetted on one Node.
          >>>>>Then I have created 2 Queues and added them to a Distributed Destination
          >>>>>as member.
          >>>>>
          >>>>>Now I start the QueueSender (pointing to the Distributed Destination's
          >>>>>JNDI)
          >>>>>I start 2 QueueReceivers (pointing to the JNDI of the 2 Queues).
          >>>>>
          >>>>>The problem is that when one of the two nodes, let's say Node1, fails
          >>>>>messages aren't dispatched to the JMS Server2.
          >>>>>
          >>>>>So I wonder: Is it possible that if one of the 2 JMS Server fails
          >>>>>the message is redirected to the other JMS Server ?
          >>>>>Thanks a lot
          >>>>>Francesco
          >>>>
          >>>Hi Barry,
          >>>I have tried to modify the connection factory as you said but
          >>>I'm still stuck. Basically when I shut down one of the two Nodes, the
          >>
          >>Sender
          >>
          >>>receives an exception "IllegalStateException: Producer is closed".
          >>>
          >>>Could you tell me if it's basically correct that :
          >>>
          >>>Sender----->looks up the Distributed Queue
          >>>Receivers---->look up the single Queues (which belong to the Distr.
          >>
          >>Queue)
          >>
          >>>Thanks again
          >>>Francesco
          >>
          >

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>
            
            <resource-ref>
                <res-ref-name>jms/ConnectionFactory</res-ref-name>
                <res-type>javax.jms.ConnectionFactory</res-type>
                <res-auth>Container</res-auth>
            </resource-ref>
            
            <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>
        
        <resource-description>
            <res-ref-name>jms/ConnectionFactory</res-ref-name>
            <jndi-name>jms/ABCConnectionFactory</jndi-name>
        </resource-description>
        
        <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

How to create JMS Queues and Topics - OAS 10.1.3?

Hi,
Is there a way to create JMS Queues and Topics via the command line for OAS 10.1.3, say through admin-client.jar ?
I have read the "Managing Adminitered Objects" chapter from the "Oracle Containers for J2EE Resource Adapter" book and could not find the information I am looking for.
Thanks.
-Sachin

Hi Sachin --
In the 10.1.3.1 release, a set of new commands have been added to admin_client.jar to support the command line creation of JMS resources:
-addJMSConnectionFactory -domain <domain> -jndiLocation <jndiLocation> [options]
-removeJMSConnectionFactory -jndiLocation <jndiLocation>
-getJMSConnectionFactories
-addDestination -domain <domain> -name <name> -jndiLocation <jndiLocation> [options]
-removeDestination -name <name> [options]
-getDestinations
You can read about it in the doc:
http://download-west.oracle.com/docs/cd/B31017_01/web.1013/b28950/adminclient.htm#CHDDFJJA
cheers
-steve-

How to configure MDB as Durable Subscriber

          I can't seem to find any documentation on how to set up an MDB as a Durable Subscriber.
          I tried using the Edit EJB Descriptor link in the console. I then drilled down
          to Message Driven Destination. For Subscription Durability, I selected Durable.
          I clicked Apply. I also went back to the jar and pressed the Persist button to
          "Persist changes made to the Descriptor(s)".
          I check the Topic to see if there were any Durable Subscribers listed. No. I bounced
          the server. Still no.
          What am I missing? The only info I can find in the documentation about setting
          up Durable Subscriptions is via the JMS API (http://e-docs.bea.com/wls/docs61/jms/implement.html#1097632)
          Using WL v6 SP5, not clustered.
          Any help would be appreciated.
          Jim


Hi James,
          I'm unfamiliar with the console ejb xml editor. I suggest
          posting to the ejb newsgbroup, which is more familiar
          with these things. Meanwhile, the attached notes
          and the following example may help if your willing
          to hand-edit the xml.
          Tom, BEA
          <ejb-jar>
          <enterprise-beans>
          <message-driven>
          <ejb-name>exampleMessageDrivenA</ejb-name>
          <ejb-class>MessageBean</ejb-class>
          <transaction-type>Container</transaction-type>
          <message-driven-destination>
          <destination-type>javax.jms.Queue</destination-type>
          
          </message-driven-destination>
          </message-driven>
          </enterprise-beans>
          <assembly-descriptor>
          <container-transaction>
          <method>
          <ejb-name>exampleMessageDrivenA</ejb-name>
          <method-name>onMessage()</method-name>
          </method>
          <trans-attribute>Required</trans-attribute>
          </container-transaction>
          </assembly-descriptor>
          </ejb-jar>
          
          <weblogic-ejb-jar>
          <weblogic-enterprise-bean>
          <ejb-name>exampleMessageDrivenA</ejb-name>
          <message-driven-descriptor>
          <pool>
          <max-beans-in-free-pool>5</max-beans-in-free-pool>
          <initial-beans-in-free-pool>5</initial-beans-in-free-pool>
          </pool>
          
          <destination-jndi-name>MDBQ</destination-jndi-name>
          
          </message-driven-descriptor>
          <jndi-name>someid</jndi-name>
          </weblogic-enterprise-bean>
          </weblogic-ejb-jar>
          James Goodwin wrote:
          > I can't seem to find any documentation on how to set up an MDB as a Durable Subscriber.
          > I tried using the Edit EJB Descriptor link in the console. I then drilled down
          > to Message Driven Destination. For Subscription Durability, I selected Durable.
          > I clicked Apply. I also went back to the jar and pressed the Persist button to
          > "Persist changes made to the Descriptor(s)".
          >
          > I check the Topic to see if there were any Durable Subscribers listed. No. I bounced
          > the server. Still no.
          >
          > What am I missing? The only info I can find in the documentation about setting
          > up Durable Subscriptions is via the JMS API (http://e-docs.bea.com/wls/docs61/jms/implement.html#1097632)
          >
          > Using WL v6 SP5, not clustered.
          >
          > Any help would be appreciated.
          >
          > Jim
          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.

Multiple Topics/Queue for Single MDB?

Hi -
Is it possible to configure single MDB to handle multiple Topic/Queue in JMS? I used two <jndi-name/> tags for two topics, but only the first one got picked up by the AS7 server. If one MDB can be configured to take multiple topics, how should I configure it? Some configuration example would be most helpful.
Thanks!

Hello,
According to the Ejb 2.1 specifications, in section 15.4.12 "Association of a Message-Driven Bean with a Destination or Endpoint.
A message-driven bean is associated with a destination or endpoint when the bean is deployed in the container. It is the responsibility of the Deployer to associate the message-driven bean with a destination or endpoint."
Based on this sentence, I would be led to beleive that a single mdb reading on multiple destinations would not be supported. You can try x-posting this to the application server forum.
If you desire the same behavior for the multiple topics, you could always use inheritance on your mdb class, or transfer the logic code into a helper class that is reused by multiple, independent MDBs classes....

Programming for Using JMS Distributed Queues

Hi,
Does anyone know specifically how your meant to write java code in order to fully make use of JMS Distributed queues. At the moment we have a 3rd party app, which I don't think is written correctly, as it always locks up after using a distributed queue, or a consumer is at 0 on one of the members of the distributed queue, when it should always should be constant and uniform.
Its as if their code hasn't been written correctly.

Distributed queue applications are encouraged to leverage WebLogic MDBs, which automatically ensure that consumers are attached to each distributed queue member, and to write applications in a way that has no dependency on which JVM a particular message is processed.
At a guess, the third party product is setting up a consumer on one member of the distributed Q, while messages are being produced to the other member. If this assumption is true, here are some thoughts:
* Consider using a single Q for the third party product's usage instead of a distributed queue. Configuring a distributed queue is not adding any high availability, as the product is expecting all messages to pin to the same Q instance.
* Producers and consumers load-balance independently, but, when "affinity" and "load balance" are both configured to false on a Producer's connection factory, producers will have a tendency to load balance to the member that hosts more than one consumer. This might help somewhat, but my guess is that it won't help in all cases -- for example, after a restart I'm not sure that there's a guarantee that the consumer won't load balance to the "wrong" member (the member that has no messages).
* It might help to enable "queue forwarding" on the distributed queue configuration. This feature automatically forwards messages trapped in a destination that has no consumers to a queue that has consumers. "Queue forwarding" is not compatible with WebLogic's "unit-of-order" feature, but it's likely the third party product isn't using this feature. Queue forwarding also imposes a performance penalty - but whether you notice the difference depends on whether you have high performance requirements.
Hope this helps,
Tom
Edited by: TomB on Mar 9, 2011 6:28 PM

What are distributed destinations?

We seem to have some confusion about what distributed destinations are within WebLogic.
          I believe a distributed topic to be a single topic name (Ex. MyTopic) that will be replicated across multiple weblogic servers. So a publisher publishes a MyTopic message to a "virtual topic" on serverA, it will then be replicated to consumers listening on serverB and serverC as well. So basically this buys you failover, load balancing, and possibly some performance increase.
          Another thought is that a distributed topic can contain multiple topic names within it. For instance, AlphabetTopic is a distributed topic. I can send a message to TopicA which is a entry of AlphabetTopics "child" topics. I can also send a message to TopicB which is part of the AlphabetTopic. It is thought that this will buy us the ability to preserve message ordering across topics because somehow weblogic will be able to maintain ordering across a distributed topic.
          Any information is greatly appreciated.

Let's just say we were only using one host, no cluster.
          1) Can I have a distributed topic (AlphabetTopic), that has 26 topics under it (TopicA-Z) each with a subscriber?
          [Tom] Yes, if there are 26 JMS Servers configured on the single WL server host, where each has one of the DD's physical members. DD's are restricted to working within a single cluster or a single WL server.
          2) What happens if I publish a message directly to TopicA? Does it only go to the physical destinations subscriber?
          [Tom] No. It is still forwarded to all 25 other topics.
          If it were a cluster, would it go to a TopicA physical destination on another node?
          [Tom] Yes. The message would publish directly to TopicA where-ever it resides in the cluster.
          If it is not routed, then in this instance you are not even really using dist topics.
          3) What if I post a message to AlphabetTopic?
          [Tom] If you published to "AlphabetTopic" it would generally first go to a physical topic on the local server (depending on how you've configured your load balancing), and it would also be replicated to all of the other physical topic members.
          My understanding is that it would go to all subscribers listening for TopicA-TopicZ.
          [Tom] Correct.
          Then it would be up to selectors to filter out if all of those clients were to retrieve the message, correct?
          [Tom] Correct.
          Tom

JMS Distributed Destination Topic - how to avoid MDB to recieve duplicates

Similar Messages

Maybe you are looking for