Uniform Distributed Topics and Unicast Cluster Messaging

...seem to be incompatible. I have a WLS 10.0 domain that has a cluster of servers to which a uniform distributed topic is deployed. There is an MDB listening to the topic member in each server. A stateless session EJB publishes to the distributed topic from one of its methods, and I expect every MDB instance to receive the message. This works correctly when the cluster is configured with multicast messaging, but when I configured the cluster to use unicast messaging (as recommended in the documentation) the MDB on the server that receives the EJB call is the only MDB that receives the message.
Is there something else I need to configure?

Similar Messages

Updating versioned app with Uniform Distributed Topic fails on 10.3.3

I have a versioned ear application running on a two server cluster. It has a MDB that accesses a Uniform Distributed Topic (global jndi, setup in console). When I increment the version and do an update/redeploy and click Activate, it gives an error saying that one of my entity beans is already bound to the JNDI tree.
If I disable the Uniform Distributed Topic / MDB connection by changing the JNDI name of the Uniform Distributed Topic in the console, then I can redeploy/update fine with no errors!
Looking at the log, that entity bean is initialized right after the MDB that attaches to the Uniform Distributed Topic.
Another thing to note is both versions are active after the error (rather than the newer version doing a stop run on the older version). However the newer version is not fully initialized on the second server in the cluster. The UDT is currently targeted to a subdeployment that targets only the migratable JMS Server pinned to the first server. I have also tried targeting it to all members of the cluster. I do only have one JMS Server that is migratable and is currently pinned to the first server.

hello guri,
can you give us the exact error message, or even a screenshot please ?
The search box on top-right of this page is your true friend, and the public Knowledge Base too:

Durable Subscriber for Uniform Distributed Topic

Hi I created one Uniform distributed topic (UDT). And One Error topic which is also Uniform distributed topic (UDT) for the same Uniform distributed topic (UDT). Now i want all the error messages in error topic to persist. So i want to create one durable subscriber for error topic. For normal topic it is easy to create but how can i create durable sub scriber for Error Topic. Please suggest.

Thank you Kalyan. But i don't think that will help. Or let me rephrase my question.
Below are my observations for using Error topic for Uniform Distributed Topic (UDT) -
1. Error topic for a UDT has to be a UDT, in the same subdeployment.
2. It is not possible to create a durable subscriber for UDT from WLS console - there is no create button.
We need durable subscriber to persist error messages. So as a work around I have created a dummy SOA process as a subscriber to the error UDT and turned the SOA process off.
Do you have an idea if we can avoid creation of dummy subscriber and still persist messages in error topic (UDT) for distributed env?
will the attribute value "Delivery Mode" = Persist help?

1 "simple" JMS topic and 2 cluster elements with OSB

Hi,
I have 1 simple jms topic (not distributed, not on migratable target) and cluster with 2 members - OSB as main application. My OSB proxy service reads from this topic and saves data to file.
The problem is that reading from topic appears twice - once by each cluster member. How to configure topic or proxy service for only one reading?

FYI - At this year's Oracle OpenWorld, which is being held in conjunction with this year's JavaOne, Oracle will be announcing a set of enhancements that are designed to cover this exact use case.
Tom Barnes
Session ID: S317469
Title: New Service-Oriented Architecture Patterns with Enterprise Grid Messaging
Abstract: Messaging systems are essential in enabling the flexibility and loosely coupled nature of a service-oriented architecture (SOA). Oracle WebLogic Java Message Service (JMS) includes new pub-sub capabilities that make architectures more adaptable, allowing message producers to be ignorant of who is the consumer of a message or how many consumers there are. It also enables easy scale out and dynamic adaptability through clustering and message-driven bean (MDB) enhancements, all while still guaranteeing strict message ordering. This session will outline new JMS capabilities and show how they enable new designs with Oracle WebLogic Server and Oracle Service Bus.
Speaker(s): Dongbo Xiao, Oracle, Principal Member of Technical Staff
Biography not available.
David Cabelus, Oracle USA, Senior Principal Product Manager
Dave Cabelus is a Senior Principal Product Manager in the WebLogic Server group at Oracle. Dave's responsibilities include product strategy and direction for various pieces of WebLogic Server, including Java Messaging, Operations and Management, Diagnostics, and various other initiatives, and previously included database connectivity, transactions, and Web tier integration. In the industry since 1996 and involved in Java since 1999, Dave worked at various software companies including Logic Works, Platinum Software, Kana, and a few startups before coming to Oracle (BEA) in 2001.
Event: JavaOne and Oracle Develop
Stream(s): ORACLE DEVELOP, DEVELOP
Track(s): Application Grid and Oracle WebLogic
Tags: Add
Session Type: Conference Session
Session Category: Features
Duration: 60 min.
Schedule: Thursday, September 23, 11:00AM | Hotel Nikko, Nikko Ballroom II Available
Edited by: TomB on Aug 12, 2010 1:21 PM

Trouble shooting on Distributed topic targeting on OSB cluster

BPELon soa cluster , unable to consume message from a distributed topic targeting to OSB cluster.

Target distributed topic to soa cluster as well along with osb cluster and try once again.
Regards,
Karan
Oracle Fusion Middleware Blog

Issue with Distributed Queue and WebLogic Clustering

Hi, When a message is received by distributed queue, MDB is processing the message on two managed servers. There seems to be issue with clustering and the physical queues present on both the managed servers are receving the message.
Our environment configuration details are as below:
One Web logic Cluster with 2 nodes (2 managed web logic servers).
One MDB deployed on the cluster listening to a queue with JNDI name “xng/jms/CODEventsQueue”
One Distributed queue with two members on the two nodes of the cluster, and with JNDI name “xng/jms/CODEventsQueue”
Two members of the distributed queue deployed on two JMS servers, which are separately deployed on each managed server .
And the distributed queue is deployed on the cluster.
Any help is appreciated.
Thanks
Sampath

It is not clear to me how you concluded that "both the managed servers are receiving the message". Did you monitor the queues' statistics, or did you see both MDB instances received the same message?
It looks like that you using a weighted distributed queue. Do the two physical queues that compose the distributed queue have their own JNDI names? If so, what are they?
Have you tried to use a uniform distributed queue and see if the same behavior shows up?
You can find more about uniform distributed destination at
http://edocs.bea.com/wls/docs103/jms/dds.html#wp1313713
BTW, which WebLogic Server releases are you using? Could you provide the distributed queue configuration?
Thanks,
Dongbo

JMS Uniform Distribute Queue Unit Of Order, problem when one node goes down

Hi ,
I have the following code which post a message (with Unit of Order set ) to a Uniform Distribute Queue in a cluster with two member servers (server1 and server2).
--UDQ is targeted to a subdeployment that is mapped to two JMS servers pointing to each member servers
--Connection Factory is using default targeting ( i tried mapping to Sub deployment also)
javax.naming.InitialContext serverContext = new javax.naming.InitialContext();
javax.jms.QueueConnectionFactory qConnFactory = (javax.jms.QueueConnectionFactory)serverContext.lookup(jmsQConnFactoryName);
javax.jms.QueueConnection qConn = (javax.jms.QueueConnection)qConnFactory.createConnection();
javax.jms.QueueSession qSession = qConn.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
javax.jms.Queue q = ( javax.jms.Queue)serverContext.lookup(jmsQName);
weblogic.jms.extensions.WLMessageProducer qSender = (weblogic.jms.extensions.WLMessageProducer) qSession.createProducer(q);
qSender.setUnitOfOrder("MyUnitOfOrder");
javax.jms.ObjectMessage message = qSession.createObjectMessage();
HashMap<String, Object> map = new HashMap<String, Object>();
map.put("something", "SomeObject");
message.setObject(map);
qSender.send(message);
} catch (Exception e) {
Steps followed:
1. Post a message from "server1"
2. Message picked up by "server2"
3. Everything fine
4. Shutdown "server2"
5. Post a message from "server1"
6. ERROR: "hashed member of MyAppJMSModule!MyDistributedQ is MyAppJMSModule!MyJMSServer-2@MyDistributedQ which is not available"
WebLogic version : 10.3.5
Is there a way (other than configuring Path Service ) to make this code work "with unit of order" for a UDQ even if some member servers go down ?
Thanks very much for your time.

If you want to avoid use of the Path Service, then the alternative is to make the destination members highly available. This will help ensure that the host member for a particular UOO is up.
One approach to HA is to configure "service migration". For more information see the Automatic Service Migration white-paper at
http://www.oracle.com/technology/products/weblogic/pdf/weblogic-automatic-service-migration-whitepaper.pdf
In addition, I recommend referencing Best Practices for JMS Beginners and Advanced Users
http://docs.oracle.com/cd/E17904_01/web.1111/e13738/best_practice.htm#JMSAD455 to help with WL configuration in general.
Hope this helps,
Tom

MDB deployed against distributed topics

I posted this to EJB 2.0 and didnt receive a reply.
          Below is per weblogic documenation
          Deploying Message-Drive Beans on a Distributed Topic
          When an MDB is deployed on a distributed topic and is targeted to a
          WebLogic Server instance in a cluster that is hosting two members of the
          distributed topic on a JMS server, the MDB gets deployed on both the
          members of the distributed topic. This occurs because MDBs are pinned to
          a distributed topic member's destination name.
          Therefore, you will receive [number of messages sent] * [number of
          distributed topic members] more messages per MDB, depending on how may
          distributed topic members are deployed on a WebLogic Server instance.
          For example, if a JMS server contains two distributed topic members,
          then two MDBs are deployed, one for each member, so you will recieve
          twice as many messages.
          The above is out of the online documentation. In my case I will have
          the MDB running
          on 7.0 servers which dont have the topics configured on them they will be in
          the 7.0 cluster. Will I get dupe messages on the 8 7.0 servers which have
          MDB's deployed against our 7.0 host cluster??
          Thats not what I want ideally i want all 8 servers MDB's sharing the
          distributed
          destinations on the wls7.0 servers in our host cluster so for example
          We have two machines in our host cluster with a distributed topic
          between the
          two lets say foo.
          Now in the MDB's deployment descriptor would like to point the beans
          to the dist destination but have them load balance against
          the two distributed topics and not have a bean deployed against each topic
          member.
          Larry Presswood wrote:
          Ok here is what I would like to do
          I have two servers in a weblogic cluster with a JMS topic which is
          spread across
          the two servers.
          Now I would like to have the consumers which will be MDB's running on 8
          6.1 sp3 or
          sp4 servers to consume from the Topic
          Question:
          1. How does MDB pick wich server it will consume? IE clustering algorithm
          2. What happens if a host server above goes down will it re-connect
          3. Is this going to work ok.
          We want multicast consumers since our message traffic will be very high.


Hi,
          Did you find the solution? I too have the same requirement. I need to put multiple server address as PROVIDER_URL, as PROVIDER_URL=t3://localhost:8001,localhost:8002,localhost:8003.
          But it is not looking up next servers. If we shut down first server(8001), queue is unable to found.
          Can you suggest the solution, if you have any.
          Thanks,
          Murthy P.

JMS Durable Distributed Topics

          Please forgive my ignorance if I am doing something silly. I am new to Weblogic
          and JMS, but learning a lot quickly. Any help will be greatly appreciated.
          I am running weblogic 8.1 with no service packs in a development environment only.
          We are trying to work out what is the expected behaviour for our current JMS Topic
          framework.
          I have a two server cluster with distributed topics configured. The two topics
          are configured to be durable. I have a test which generates about 100 events for
          test purposes. Under normal circumstances, each server processes about 50 messages.
          (Load balancing!)
          When the test is running, I kill one of the servers manually before it finishes.
          (Not a gracefull shutdown). The killed server processes about 20 messages, and
          the running server processes about 50. I can see that tables for the persistent
          topics have something (I don't know what) representing about all 100 events sent.
          When I bring the killed server back up, nothing happens. I would expect, from
          the documentation that I read, that the remaining 30 or so events will be put
          on the topic to be processed by our MDBs.
          Why don't all the events get placed on the topic of the killed server when it
          starts back up?
          What is the expected behaviour here?
          Is something wrong with my topic setup?
          Thanks in advance for any help...
          regards,
          Patrick Parato


Hi Patrick,
          Note 1: If you desire MDB to be transactional. Make sure
          the assembly descriptor in ejb-jar.xml is set to
          "Required" in addition to making the transaction-type
          "Container" as you have already done.
          <assembly-descriptor>
          <container-transaction>
          <method>
          <ejb-name>YOUREJBNAME</ejb-name>
          <method-name>onMessage()</method-name>
          </method>
          <trans-attribute>Required</trans-attribute>
          </container-transaction>
          </assembly-descriptor>
          Note 2: Your MDB is non-durable. It needs to be durable
          to cause messages to persist. Add the following line
          in the message-driven-destination clause of your ejb-jar.xml:
          <subscription-durability>Durable</subscription-durability>
          See the JMS FAQ on dev2dev.bea.com (or the JMS Performance
          Guide white-paper) for information on how to make
          sure a message is persistent.
          Note 3: Only one durable subscriber MDB will
          be able to attach to a given durable subscription, MDB's
          on other servers won't be able to, so even if the MDB
          is targeted at the cluster only one MDB will be able
          to process messages. This is the nature
          of durable subscriptions. I'm attaching some personal
          notes on the subject.
          Note 4: Durable subscriptions must refer to
          the JNDI name of member destinations, not to
          the distributed destination. WL does not support
          durable subscriptions directly on a distributed topic.
          Note 5: If you do not want message replication I'm not
          sure why you are using a distributed topic. Use a
          distributed queue.
          Tom
          Patrick Parato wrote:
          > Tom,
          >
          > Thanks for the quick reply.
          >
          > The first thing I want to clarify is that we only have one subscriber (MDB) that
          > is deployed once across multiple servers in a cluster. So this may explain why
          > each server is getting half the messages.
          Its still not clear. Each MDB pool should get each message.
          The individual
          instances in the pool will divide the messages sent to their MDB
          pool's subscription among them.
          >
          >
          >>2) Make sure that you are using durable subscribers. I suspect you
          >>are not. Note that durable subscribers are not supported
          >>for distributed destinations - they must refer directly to a member
          >>destination instead.
          >>
          >
          >
          > We are definitely using a distributed topic. The entry for our MDB in the weblogic-ejb.jar.xml
          > for the <destination-jndi-name> refers to the jndi name of the distributed topic.
          > So if I understand you correctly you are saying that the <destination-jndi-name>
          > should refer to the jndi name of an actual phyiscal topic on one of the servers.
          > By tying an MDB to a regular topic, how do we achieve failover if the JMS server
          > that the topic is associated with should fail?
          >
          >
          >
          > Here is a snippet of our config.xml:
          > (Names have been changed for security reasons)
          >
          > <JMSServer Name="JMS Server1" Store="Event Store1" Targets="myserver1">
          > <JMSTopic CreationTime="1065029382062"
          > JNDIName="distributed.topic@JMS Server1"
          > JNDINameReplicated="false"
          > Name="Distributed Topic@JMS Server1"
          > Template="Distributed Topic" TimeToDeliverOverride="5000"/>
          > </JMSServer>
          >
          > <JMSServer Name="JMS Server2" Store="Event Store2" Targets="myserver2">
          > <JMSTopic CreationTime="1065029382375"
          > JNDIName="distributed.topic@JMS Server2"
          > JNDINameReplicated="false"
          > Name="Distributed Topic@JMS Server2"
          > Template="Distributed Topic" TimeToDeliverOverride="5000"/>
          > </JMSServer>
          >
          >
          > <JMSDistributedTopic JNDIName="distributed.topic" Name="Distributed Topic" Targets="Cluster">
          > <JMSTemplate DeliveryModeOverride="Persistent"
          > Name="Distributed Topic" TimeToDeliverOverride="5000"/>
          > <JMSDistributedTopicMember
          > JMSTopic="distributed.topic@JMS Server1" Name="Distributed Topic@JMS
          > Server1"/>
          > <JMSDistributedTopicMember
          > JMSTopic="distributed.topic@JMS Server2" Name="Distributed Topic@JMS
          > Server2"/>
          > </JMSDistributedTopic>
          >
          >
          > ejb-jar.xml:
          >
          > <message-driven>
          >      <ejb-name>AnMDB</ejb-name>
          >      <ejb-class>package.AnMDB</ejb-class>
          >      <transaction-type>Container</transaction-type>
          >      <message-driven-destination>
          >           <destination-type>
          >                javax.jms.Topic
          >           </destination-type>
          >      </message-driven-destination>
          > </message-driven>
          >
          > weblogic-ejb.jar.xml:
          >
          > <weblogic-enterprise-bean>
          > <ejb-name>AnMDB</ejb-name>
          >      <message-driven-descriptor>
          >      <destination-jndi-name>distributed.topic</destination-jndi-name>
          >      </message-driven-descriptor>
          >      <enable-call-by-reference>True</enable-call-by-reference>
          >      <jndi-name>ejb.AnMDB</jndi-name>
          > </weblogic-enterprise-bean>
          >
          > Thanks for you help and quick reply.
          >
          > regards,
          > Patrick Parato
          >
          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.

JMS distrubuted topic and jms inbound adapter

Hi,
We are building a HA application using precise recovery using JMS. FOr that we want to create a distributed JMS Topic (ckustered JMS Topic). As we understand things, when a JMS subscriber subscribes to a distributed Topic it is actually wired to a sopecific server (a specific fisical JMS Topic). When this JMS server fails the connection is dropped and the JMS subscriber needs to reconnect.
1. Is our understanging correct?
2. If yes and we need to reconnect to the surviving JMS Topic, is there a way to "tell" the JMS Inbound adapter to do so? Is it done automatically by the adapter?
Thanks,

There are a few different things you should be considering when configuring JMS for precise recovery, so I'm afraid this is going to be a long response.
* The precise recovery feature may not work correctly in the case where JMS output messages are lost. Avoiding message loss in the case of a JMS failure involving topics requires the use of persistent messages and durable subscribers. This is true regardless of whether you're using Distributed Topics or a Topic hosted by a single server. So use of durable subscribers is highly recommended when using CEP precise recovery.
* The CEP JMS input adapter won't actually support durable subscriptions until the upcoming 11.1.1.6 (PS5) release. So if you want to use durable subscriptions to avoid problems with precise recovery in the case of JMS server failure you would need to be on this release of CEP (at least for production).
* If you're using the CEP JMS inbound adapter with a distributed topic and a non-durable subscription, you can configure the adapter destination-jndi-name with the logical name of the topic and if the topic member servicing a given consumer fails, the consumer will reconnect to a surviving topic member. This works because you're using a logical destination name (not a physical host name or IP address), so the adapter is able to determine the surviving servers associated with the logical topic and reconnect to one of them. However since you'd be using non-durable subscriptions in this case to achieve failover/reconnect, you can have the problem described above with message loss and precise recovery (non-durable subscribers/non-persistent messaging can lose messages during the actual failover/reconnect).
* Unfortunately, WLS doesn't support durable subscriptions to distributed topics using the logical destination name. When using distributed topics you can only create durable subscriptions on specific topic members, and since these are subscriptions to a specific physical member these subscribers won't failover to another topic member if the server hosting their subscription fails.
So given all of the above you can see that the use of distributed topics with CEP precise recovery may not provide the ideal level of HA (the ability to handle combinations of JMS and CEP failures). You might want to consider using a non-distributed (single server) topic with persistent messaging and durable subscriptions as an alternate approach for precise recovery. In this configuration JMS server failure would require restarting the failed server, but once the JMS server is restarted there should be no message loss and CEP precise recovery should work correctly.
If you're determined to use distributed topics you might want to try posting to the JMS forum to see if anyone there has ideas for other solutions. Just let them know that CEP in this case is essentially acting as a vanilla JMS client (not MDB based) that can't tolerate message loss:
WebLogic Server - JMS

API to list Uniform Distributed Queue JMS Servers

Hi all,
I posted this in the SOA suite forum but this one may be better.
I am writing a POJO webservice to synchronously read a message from a JMS queue. Unfortunately the queue is actually a uniform distributed queue so I actually need to look for messages in each of the local queues.
I have written code to find the JNDI names of the local queues as follows:
StringArray DistribMemberNames = new StringArray();
String ttt;
ttt = JMSHelper.uddMemberJNDIName("IMPJMSServer_1", part1.getJNDIName());
DistribMemberNames.add(ttt);
ttt = JMSHelper.uddMemberJNDIName("IMPJMSServer_2", part1.getJNDIName());
DistribMemberNames.add(ttt);
This works fine but I have hard coded the names of the JMS Servers and this is bad practice. I need to find a method where I can take the JNDI name of the uniform distributed queue and find all the JMSServer names. I have been looking for days but I can’t find anywhere in the API documentation that describes this.
Does anyone have any suggestions?
Thanks
Robert
(I am using 11.1.1.5 on a clustered weblogic enviroment)

Hi,
I have managed to answer this question myself.
I needed to create a context:
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
m_jndiContext = new InitialContext(env);
Look up the main runtime mbean
MBeanServer server;
server = (MBeanServer) m_jndiContext.lookup("java:comp/env/jmx/runtime");
Navigate down the domain configuration to get the JMSServers
ObjectName service = null;
ObjectName domainConfiguration = null;
ObjectName[] jmsServers = null;
service = new ObjectName(
"com.bea:Name=RuntimeService,"
+ "Type=weblogic.management.mbeanservers.runtime.RuntimeServiceMBean");
domainConfiguration = (ObjectName) server.getAttribute(service, "DomainConfiguration");
jmsServers = (ObjectName[]) server.getAttribute(domainConfiguration, "JMSServers");
For each server you can retrive it's name:
for (int i = 0; i < length_serverRT; i++) {
String jmsServerName = "";
jmsServerName = (String) server.getAttribute(serverRT, "Name");
I had to do some additional filtering for my own requirements
Robert

Distributed Topics function as intended?

My question conerns distributed topics and how their intended functionality in a clustered environment should work.
          We have a clustered WLS 8.1 environment with two managed servers with app A and app B deployed to each of them. App A has a distributed topic that it publishes messages to. App A also has a JMS Server on each managed server with a physical topic on each one. So both of these topics are tied to the one Distributed topic. App B is subscribed to this distributed topic. When App A publishes a message to this topic - WL publishes a message to each physical topic on each managed server. Then App B's MDBs (one on each managed server) retrieve their message - in effect processing the one message twice (from an application standpoint). The behavior that I'd like to see is if one message is published to the distributed topic - that one of App A's physical topics would get the message - and that one of the MDBs in App B would process the message. In effect now we receive double messages into App B. Using a distributed Queue in App A is currently not possible as multiple different apps must listen for messages from App A.
          So if you were not running in a clustered environment you would not see this type of behavior because you'd ultimately be publishing only one message to one topic and your mdb would receive only one message.
          Can anyone comment on this?

Hi,
          This is expected behavior. The purpose of a topic, or a distributed topic, is message replication. You would see the same behavior even if the topic was not distributed:
          MDB App A gets a message copy on both servers 1 and 2
          MDB App B gets a message copy on both servers 1 and 2
          If you made the MDB topic subscriptions "durable", you would get the behavior you desire. This is because durable subscriptions are exclusive, so that only the first MDB pool for App A to attach to the subscription would get messages - the other MDB pool A on the other server would be idle (but constantly retrying until the first MDB pool A fails, undeployes, or shuts down).
          I think this information is also in the MDB chapter of the 8.1 EJB Vdocs...
          Tom

Using distributed queues and factories in a weblogic cluster

Hi all,
in our environment we have a domain which has two machines. One is running the AdminServer and Node1 and the 2nd machine is running Node2.
For each Node I have created a JMS Server and a corresponding file store located at each machine.
I've also created a JMS Module containing our required queues, factories and topics. Queues and Topics are of the Uniform Distributed type.
I've targeted this module at the cluster and experimented with creating a subdeployment. But from what I recon, since all my resources have default targeting
enabled, a subdeployment is not required, they target what is targeted by the JMS Module, right?
However I get an exception when both nodes are up:
<Nov 4, 2008 11:47:01 AM EET> <Warning> <JMS> <BEA-040498> <An error occurred while forwarding a message for distributed destination member
MyJMSModule!MyJMSServer@myTopic: weblogic.messaging.dispatcher.DispatcherException: java.rmi.RemoteException: Couldn't connect to weblogic.rjvm.RJVMImpl@187766d - id: '-1415064081927280896S:10.0.0.5:
[7001,7001,-1,-1,-1,-1,-1]:app1:7003,app2:7001:my_domain        :NodeApp2' connect time: 'Tue Nov 04 11:47:01 EET 2008' - it is likely that the connection has already been shut down; nested exception is:
5564732         java.rmi.ConnectException: Couldn't connect to weblogic.rjvm.RJVMImpl@187766d - id: '-1415064081927280896S:10.48.92.70:[7001,7001,-1,-1,-1,-1,-1]:app1:7003,app2:7001:my_domain:NodeApp2'
connect time: 'Tue Nov 04 11:47:01 EET 2008' - it is likely that the connection has already been shut downThe two nodes are up and running and the node managers as well. Is this the correct way to create the queues and topics for a clustered environment?
Thanks
Edited by: dvm on Nov 4, 2008 3:12 AM

I've done the steps but the problem still persists. I don't know if I had this before, but now both machines can't see each other.
From Node1 logs *.out file:
<Warning> <JMS> <BEA-040498> <An error occurred while forwarding a message for distributed destination member MyJMSModule!MyJMSServer2@my_cacheTopic:
weblogic.messaging.dispatcher.DispatcherException: java.rmi.RemoteException:
Couldn't connect to weblogic.rjvm.RJVMImpl@62017d - id: '4786464166486913267S:10.48.92.70:[7001,7001,-1,-1,-1,-1,-1]:app1:7003,app2:7001:my_domain:NodeApp2'
connect time: 'Wed Nov 05 16:03:53 EET 2008' - it is likely that the connection has already been shut down; nested exception is:
java.rmi.ConnectException: Couldn't connect to weblogic.rjvm.RJVMImpl@62017d - id: '4786464166486913267S:10.48.92.70:[7001,7001,-1,-1,-1,-1,-1]:app1:7003,app2:7001:my_domain:NodeApp2'
connect time: 'Wed Nov 05 16:03:53 EET 2008' - it is likely that the connection has already been shut downand from Node2 logs *.out file:
<Warning> <JMS> <BEA-040498> <An error occurred while forwarding a message for distributed destination member MyJMSModule!MyJMSServer1@my_cacheTopic:
weblogic.messaging.dispatcher.DispatcherException: java.rmi.RemoteException:
Couldn't connect to weblogic.rjvm.RJVMImpl@24b64a - id: '-788798942991630857S:10.48.92.69:[7003,7003,-1,-1,-1,-1,-1]:app1:7003,app2:7001:my_domain:NodeApp1'
connect time: 'Wed Nov 05 16:03:59 EET 2008' - it is likely that the connection has already been shut down; nested exception is:
java.rmi.ConnectException: Couldn't connect to weblogic.rjvm.RJVMImpl@24b64a - id: '-788798942991630857S:10.48.92.69:[7003,7003,-1,-1,-1,-1,-1]:app1:7003,app2:7001:my_domain:NodeApp1'
connect time: 'Wed Nov 05 16:03:59 EET 2008' - it is likely that the connection has already been shut downThis happens just after the managed servers have been started with the application previously deployed.

Reading messages from all distributed queues on a cluster (WLS 9.2)

Hi,
I have a following problem with distributed queues on WebLogic Server 9.2 MP1.
Here's a brief description of my setup:
I've got a cluster called 'myCluster', and two cluster nodes on it, 'nodeA' and 'nodeB'. I also have two JMS servers, 'jmsA' and 'jmsB'. Then I have a jms module 'myModule' with a subdeployment 'mySubdeployment' targeted on jms servers 'jmsA' and 'jmsB'. I have a jms connection factory 'TestFactory' that is targeted on myCluster (default targetting), and a jms queue 'TestQueue' (Uniform Distributed Queue) using subdeployment 'mySubdeployment' (targeted to 'jmsA' and 'jmsB').
Now, the queue 'TestQueue' is used as a location where messages are stored when the system has met a problem in the environment that is preventing the normal handling of messages. Messages are kept in this queue until the problem is over, that's when the system administrator uses a browser application that requests the system to read the messages and handle them normally.
The problem is that the cluster node which gets the request seems to be able to read only its own queue and the messages on the other nodes queue are left untouched. I know that I could send a message to the another node for example via topic 'purge_your_messages', but that's not suitable for this case. I need to sort the messages by their ids (set as a message property) and because of that I need exactly one node executing the purge.
Any advice?
- jj
Edited by: user5736915 on 10-Dec-2008 14:10

Browsers and receivers always attach to a single member of a distributed destination.
WebLogic MDBs, on the other hand, automatically handle the task of attaching receivers to every member, and are quite simple to code and use these days. If you have the option of using WL MDBs, I recommend using them. (There's no equivalent for browsers.)
Spring won't do the same OOTB, but there does appear to be a work-around for the Spring receiver issue (albeit not for browsers - just receivers). Here's a sample Spring impl that attaches a subscription to each and every member of a distributed topic:
http://sleeplessinslc.blogspot.com/2011/12/weblogic-jms-partitioned-distributed.html.
If the above isn't helpful, and you must cycle through every message on every server in the cluster, then you'll need write special case code to check each separately. There are two common options for enumerating the destinations and working with each one - the JMX mbean "message management" APIs (WLST Jython scripting or Java based) and the weblogic.jms.extensions destination availability APIs.
HTH,
Tom

JNDINameReplicated and distributed topics in 6.1 SP3

          I am trying to figure out how to setup a distributed topic in Weblogic that is
          capable of running even if one of the servers in the cluster goes down. I know
          that the topic can only run on one machine at a time because it is replicated
          in each server's JNDI tree. So, to get around this, I created the same topic
          on two servers in my cluster and I set the JNDINameReplicated parameter to false.
          However, if I send a message to the topic "cars" in server1, the message WON'T
          be forwarded to subscribers of the topic "cars" in server2. How can I enforce
          this? I will have subscribers to the topic "cars" on a different Weblogic server
          then the one that the producer to the topic is sending the messages out on.
          Any ideas how I can distribute the message throughout all of my JMS servers?
          Thanks.
          Dan


Or move to 7.0 which has distributed destinations built-in.
          _sjz.
          "Tom Barnes" <[email protected]> wrote in message
          news:[email protected]...
          > Hi Dan,
          >
          > I think you will need to implement you're own forwarders to replicate
          messages
          > between the two topics.
          >
          > Create an MDB on each server with a durable subscription on the other
          server.
          > The MDB simply publishes each message it receives to the local topic.
          >
          > Have the MDB descriptors respectively specify the URL for the remote
          > server (this is a WebLogic extension to aid in configuring foreign JMS
          providers,
          > but helps you out here.)
          >
          > If you want to get exactly-once forwarding, set transaction-required on
          the MDB.
          > Otherwise, you will get possible duplicates (message is forwarded by MDB
          and
          > server crashes before it is acknowledged).
          >
          > If you want higher performance forwarding, you will need to roll your own
          > forwarder in a startup class. Such a forwarder could batch several
          subscribes and
          > publishes under the same transaction (as the messaging bridge does). Or,
          if you
          > don't care about ordering, simply crank up your MDB pool size. (If you do
          care
          > about ordering it should be set to 1.)
          >
          > One key thing: The forwarders should set a property on the message to
          indicate that
          > the
          > message has already been forwarded. They should also specify a selector
          in
          > their descriptors which filters out already forwarded messages based on
          this
          > property.
          >
          > Tom
          >
          > Dan Baumbach wrote:
          >
          > > I am trying to figure out how to setup a distributed topic in Weblogic
          that is
          > > capable of running even if one of the servers in the cluster goes down.
          I know
          > > that the topic can only run on one machine at a time because it is
          replicated
          > > in each server's JNDI tree. So, to get around this, I created the same
          topic
          > > on two servers in my cluster and I set the JNDINameReplicated parameter
          to false.
          > > However, if I send a message to the topic "cars" in server1, the
          message WON'T
          > > be forwarded to subscribers of the topic "cars" in server2. How can I
          enforce
          > > this? I will have subscribers to the topic "cars" on a different
          Weblogic server
          > > then the one that the producer to the topic is sending the messages out
          on.
          > >
          > > Any ideas how I can distribute the message throughout all of my JMS
          servers?
          > > Thanks.
          > > Dan
          >

Uniform Distributed Topics and Unicast Cluster Messaging

Similar Messages

Maybe you are looking for