A bug in distributed topic on WL8.1SP3 ?

Hi.
          We use a distributed topic to synchronise our web application over a cluster.
          When we first start our two managed servers, there's no problem : the two web applications communicates with each other.
          Then, we restart one of the managed server to simulate a crash. When the restarted server is up again, its web application continue to receive the messages from the other server but can't emit : the new server seems to be mute.
          I did the same test with Weblogic 8.1 SP4 and Weblogic 7.0 SP4 and I didn't encounter the problem.
          I looked for a referenced bug and I didn't find anything. Did I miss something or is there really a bug in distributed topic in Weblogic server 8.1 SP3 ?
          Thanks for your replies.

Ask BEA support about CR188391.
That fixes a group of JMS related problems introduced in SP3.
-Sean

Similar Messages

MDB on distributed topic issue (server restart)

Setup:
          - On WebLogic 8.1 SP3, One cluster with 2 managed servers, S1 and S2.
          - JMS servers are configured for both S1 and S2.
          - ConnectionFactory(load balancing=true, server affinity=false, XA Transaction=true) is deployed to the cluster
          - Distributed topic, DT1, deployed to the cluster with physical memeber on each JMS server, T1 on S1, T2 on S2
          - MDB for DT1 is deployed in both S1 and S2
          - Sending message to DT1 thru a session bean with container managed transaction.
          Test:
          1. Start both server, and send 10 messages to DT1, evenrything is fine, both servers received 10 messsage each
          2. Shutdown S2
          3. Send another 10 messages to DT1, S1 received 10 messages thru MDB deployed on it, and noticed that there are 10 messages pending for T1 (by using console destination monitoring function)
          4. Restart S2
          5. When S2 is fully restarted, noticed that the 10 pending messages are gone for T1, but S1 printout 10 Alert: Tx heuristic result
          6. then, if send another 10 messages thru session bean in S1, both servers receives 10 messages each; if send another 10 messages thru session bean in S2, only S2 will receive them all, S1 receives nothing and noticed that 10 messages pending for T2
          Someone posted a similar issue before, but no clear answer on exactly what happened and how to fix it.
          Thanks,
          JD

The errors are:
          <17-Feb-2005 4:40:45 o'clock PM EST> <Error> <JTA> <BEA-110412> <Xid=BEA1-054635FA5A4B74B8B574(14775730),Status=Committed,HeuristicErrorCode=XA_HEURHAZ,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=300,XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=committed,assigned=server2),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@e8b13,re-Registered = false),SCInfo[NakinaDomain+server2]=(state=committed)) completed heuristically: (weblogic.jdbc.wrapper.JTSXAResourceImpl, HeuristicHazard, (javax.transaction.xa.XAException: No connection associated with xid = BEA1-054635FA5A4B74B8B574-7765626C6F6769632E6A6462632
          E777261707065722E4A545358415265736F75726365496D706C)) >

Trouble with a JMS proxy listening to a distributed topic

Hi all,
I've setup an ALSB cluster with 1 admin instance and 2 managed instances (m01 and m02).
I've also configured 1 distributed topic A and defined the two below proxies:
- proxy P1 is a http proxy that publishes a message into the distributed topic A. The proxy uses a business service with jms protocol and endpoint uri:
jms://wasdv1r3n1.dev.b-source.net:7301,wasdv1r3n1.dev.b-source.net:7303/my.ConnectionFactory/DistributedTopicA
- proxy P2 is a JMS proxy listening to
jms://wasdv1r3n1.dev.b-source.net:7301,wasdv1r3n1.dev.b-source.net:7303/my.ConnectionFactory/DistributedTopicA
that logs the received message and writes it to file.
The strange behaviour is that on the managed m01 log file I see the message received from P2 but also on the managed m02 log file I see the message received from P2.
So I'm sending out 1 message and receiving 1 x managed that is total = 2.
This strange behaviour is also confirmed from the fact that I see on the file system 2 files and not only 1.
I thought it was a problem concerning the config of business service that publishes message into the distributed topicA; but I tried with an external 'normal' java JMS subscriber that listens to t3://wasdv1r3n1.dev.b-source.net:7301,wasdv1r3n1.dev.b-source.net:7303 and it works properly: it receives only 1 message.
I'm trying to understand where is my fault.
Do you have any idea ?
Thanks in advance
Patrizio

If you publish a message to a topic, all the proxy that subscribed to this topic will receive the message. If you want the message to be processed by only one managed server you can publish to a queue instead.
Gregory Haardt
ALSB Prg. Manager
[email protected]

Lookup of distributed topic

Scenario : 2 servers A, B both in cluster and hosting stateless session bean which, when called by a client app, places a message on a queue for an MDB to pick up. The MDB copies the message to a distributed topic, to which my clients subscribe.
          Problem : sometimes when I start my client everything is fine (it calls the SSB on one of the servers according to the round robin load balancing, and receives a message on the topic). I can run this with both servers up and multiple clients - they all balance their calls across the servers and receive all the messages (incl. those due to calls made by other clients - intentional). However, sometimes when I start a client it receives messages in response to SSB calls on only one server (ie it gets a message when a client calls SSB on server 1, but not if a client calls SSB on server 2). Simultaneously another client will get the message. Each time I start the application there seems to be approx. 50% chance it will work or fail - depending I think on which server the connection factory/topic are looked up. It seems like the distributed topic found in the JNDI of one server is not aware of the member topic the other server (or possibly itself, but that sounds far-fetched). As far as I can see the config is correct. When the problem manifests, I check the JMS server info on the admin console and I see that one of the JMS servers does not have the client registered as a consumer - so why sometimes does the client not register with both topics via the distributed topic ? The lookup is always done the same way - the only delta as far as I can tell is in which JNDI the lookup is done - and that is decided by the round robin.

Thanks for the suggestions.
          I checked 1,2,3 :)
          As for 4 - the SSB posts to a queue, from which the MDB picks up the message and places on the topic. Both are from within server, so don't specify a provider URL. I also tried it with SSB posting direct to topic - same problem.
          My config.xml is here FYI:
          <?xml version="1.0" encoding="UTF-8"?>
          <Domain ConfigurationVersion="8.1.2.0" Name="LOSDomain">
          <Cluster ClusterAddress="arjun,manu" MulticastAddress="237.0.0.1" Name="LOSCluster"/>
          <Server ExpectedToRun="false" ListenAddress="mahesh"
          ListenPort="7001" Name="LOSClusterAdminServer"
          NativeIOEnabled="true" ReliableDeliveryPolicy="RMDefaultPolicy" ServerVersion="8.1.3.0">
          <SSL Enabled="false" HostnameVerificationIgnored="false"
          IdentityAndTrustLocations="KeyStores" Name="LOSClusterAdminServer"/>
          </Server>
          <Server Cluster="LOSCluster" ExpectedToRun="true"
          ListenAddress="arjun" Machine="arjun" Name="LOSClusterArjun"
          NativeIOEnabled="true" ServerVersion="8.1.3.0">
          <SSL Enabled="false" IdentityAndTrustLocations="KeyStores" Name="LOSClusterArjun"/>
          <ExecuteQueue Name="weblogic.kernel.Default"/>
          <ServerStart JavaHome="C:/bea/jdk142_04" Name="LOSClusterArjun"
          OutputFile="C:\bea\user_projects\domains\LOSDomain\.\NodeManagerClientLogs\LOSDomain_LOSClusterArjun\startServer_08_27_2004-15_01_54-3.log"
          Password="{3DES}Ai8rf75Evm+hCUFOy5gryA==" Username="losclusteradmin"/>
          </Server>
          <Server Cluster="LOSCluster" ExpectedToRun="true"
          ListenAddress="manu" Machine="manu" Name="LOSClusterManu"
          NativeIOEnabled="true" ServerVersion="8.1.3.0">
          <SSL Enabled="false" IdentityAndTrustLocations="KeyStores" Name="LOSClusterManu"/>
          <ExecuteQueue Name="weblogic.kernel.Default"/>
          <ServerStart JavaHome="C:/bea/jdk142_04" Name="LOSClusterManu"
          OutputFile="C:\bea\user_projects\domains\LOSDomain\.\NodeManagerClientLogs\LOSDomain_LOSClusterManu\startServer_08_27_2004-15_01_55-3.log"
          Password="{3DES}Ai8rf75Evm+hCUFOy5gryA==" Username="losclusteradmin"/>
          </Server>
          <MigratableTarget Cluster="LOSCluster"
          Name="LOSClusterArjun (migratable)"
          Notes="This is a system generated default migratable target for a server. Do not delete manually." UserPreferredServer="LOSClusterArjun"/>
          <MigratableTarget Cluster="LOSCluster"
          Name="LOSClusterManu (migratable)"
          Notes="This is a system generated default migratable target for a server. Do not delete manually." UserPreferredServer="LOSClusterManu"/>
          <Machine Name="arjun">
          <NodeManager ListenAddress="arjun" Name="arjun"/>
          </Machine>
          <Machine Name="manu">
          <NodeManager DebugEnabled="true" ListenAddress="manu" Name="manu"/>
          </Machine>
          <JMSFileStore Directory="rmfilestore" Name="FileStore"/>
          <WSReliableDeliveryPolicy DefaultRetryCount="10"
          DefaultTimeToLive="60000" Name="RMDefaultPolicy" Store="FileStore"/>
          <Security Name="LOSDomain"
          PasswordPolicy="wl_default_password_policy"
          Realm="wl_default_realm" RealmSetup="true"/>
          <EmbeddedLDAP
          Credential="{3DES}5pcSSYqvrUsFDxEIjHW8D8A+zarHYUQBLqy3bbNobRE=" Name="LOSDomain"/>
          <SecurityConfiguration
          Credential="{3DES}/C+AT2Uk5aYMzkLa1YtpOuci2NKs2z1Un8erWai4ckZ9mcuA7hp4Y5UqoNKRG9OxYZ8TyH0UhUmu8Dl2+PJK+p40DcGCqTX8"
          Name="LOSDomain" RealmBootStrapVersion="1"/>
          <Realm FileRealm="wl_default_file_realm" Name="wl_default_realm"/>
          <FileRealm Name="wl_default_file_realm"/>
          <PasswordPolicy Name="wl_default_password_policy"/>
          <JMSServer
          Name="WSStoreForwardInternalJMSServerLOSClusterAdminServer"
          Store="FileStore" Targets="LOSClusterAdminServer">
          <JMSQueue CreationTime="1092921740515"
          JNDIName="jms.internal.queue.WSStoreForwardQueue"
          JNDINameReplicated="false" Name="WSInternaljms.internal.queue.WSStoreForwardQueueLOSClusterAdminServer"/>
          <JMSQueue CreationTime="1092921740937"
          JNDIName="jms.internal.queue.WSDupsEliminationHistoryQueue"
          JNDINameReplicated="false" Name="WSInternaljms.internal.queue.WSDupsEliminationHistoryQueueLOSClusterAdminServer"/>
          </JMSServer>
          <JDBCConnectionPool
          DriverName="oracle.jdbc.xa.client.OracleXADataSource"
          Name="LOSClusterOraclePool" Password="{3DES}V0qT6N3+0rs="
          Properties="user=los4"
          Targets="LOSClusterAdminServer,LOSCluster"
          TestTableName="SQL SELECT 1 FROM DUAL" URL="jdbc:oracle:thin:@balti:1521:losdb3"/>
          <JDBCTxDataSource JNDIName="LOSClusterOracleDataSource"
          Name="LOS Cluster Oracle Data Source"
          PoolName="LOSClusterOraclePool" Targets="LOSClusterAdminServer,LOSCluster"/>
          <JMSServer Name="LOSClusterJMSServer_Arjun" Targets="LOSClusterArjun">
          <JMSQueue CreationTime="1092924092765"
          JNDIName="LOSNotificationQueue@LOSClusterJMSServer_Arjun"
          Name="LOS Notification Queue@LOSClusterJMSServer_Arjun" Template="LOS Notification Queue"/>
          <JMSTopic CreationTime="1093428475187"
          JNDIName="LOSNotificationTopic@LOSClusterJMSServer_Arjun"
          Name="LOS Notification Topic@LOSClusterJMSServer_Arjun" Template="LOS Notification Topic"/>
          </JMSServer>
          <JMSServer Name="LOSClusterJMSServer_Manu" Targets="LOSClusterManu">
          <JMSQueue CreationTime="1092924092750"
          JNDIName="LOSNotificationQueue@LOSClusterJMSServer_Manu"
          Name="LOS Notification Queue@LOSClusterJMSServer_Manu" Template="LOS Notification Queue"/>
          <JMSTopic CreationTime="1093428475734"
          JNDIName="LOSNotificationTopic@LOSClusterJMSServer_Manu"
          Name="LOS Notification Topic@LOSClusterJMSServer_Manu" Template="LOS Notification Topic"/>
          </JMSServer>
          <JMSJDBCStore ConnectionPool="LOSClusterOraclePool"
          Name="LOSClusterJMSJDBCStore_Arjun" PrefixName="JMS_Arjun_"/>
          <JMSJDBCStore ConnectionPool="LOSClusterOraclePool"
          Name="LOSClusterJMSJDBCStore_Manu" PrefixName="JMS_Manu_"/>
          <JMSConnectionFactory JNDIName="LOSConnectionFactory"
          Name="LOS Connection Factory" ServerAffinityEnabled="false" Targets="LOSCluster"/>
          <JMSTemplate Name="LOS Notification Topic"/>
          <JMSTemplate Name="LOS Notification Queue"/>
          <JMSDistributedQueue JNDIName="LOSNotificationQueue"
          Name="LOS Notification Queue" Targets="LOSCluster" Template="LOS Notification Queue">
          <JMSDistributedQueueMember
          JMSQueue="LOS Notification Queue@LOSClusterJMSServer_Manu" Name="LOS Notification Queue@LOSClusterJMSServer_Manu"/>
          <JMSDistributedQueueMember
          JMSQueue="LOS Notification Queue@LOSClusterJMSServer_Arjun" Name="LOS Notification Queue@LOSClusterJMSServer_Arjun"/>
          </JMSDistributedQueue>
          <JMSServer Name="LOS Admin Server JMS Server" Targets="LOSClusterAdminServer"/>
          <JMSDistributedTopic JNDIName="LOSNotificationTopic"
          Name="LOS Notification Topic" Targets="LOSCluster" Template="LOS Notification Topic">
          <JMSDistributedTopicMember
          JMSTopic="LOS Notification Topic@LOSClusterJMSServer_Arjun" Name="LOS Notification Topic@LOSClusterJMSServer_Arjun"/>
          <JMSDistributedTopicMember
          JMSTopic="LOS Notification Topic@LOSClusterJMSServer_Manu" Name="LOS Notification Topic@LOSClusterJMSServer_Manu"/>
          </JMSDistributedTopic>
          <Application Name="NopTest"
          Path="C:\bea\user_projects\domains\LOSDomain\LOSClusterAdminServer\upload\NopTest.ear"
          StagedTargets="LOSClusterManu,LOSClusterArjun"
          StagingMode="stage" TwoPhase="true">
          <EJBComponent Name="NopTestFacade.jar" Targets="LOSCluster" URI="NopTestFacade.jar"/>
          <EJBComponent Name="NotificationMDB.jar" Targets="LOSCluster" URI="NotificationMDB.jar"/>
          </Application>
          </Domain>

Distributed topic - JMS adapter consuming duplicate messages

We have distributed topic thats consumed by a composite (JMSadpter in mediator).
We see for every one message sent the composite consumes the message twice. (With forwarding policy set to partitioned)
Is this an expected behavior? and how do we make the consumer (JMS adapter) consume only once per message
Thanks
Vijay

From the documentation (provided here: http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10231/adptr_jms.htm)
The JMS API specifies three types of acknowledgments that can be sent by the JMS publisher:
- DUPS_OK_ACKNOWLEDGE, for consumers that are not concerned about duplicate messages
- AUTO_ACKNOWLEDGE, in which the session automatically acknowledges the receipt of a message
- CLIENT_ACKNOWLEDGE, in which the client acknowledges the message by calling the message's acknowledge method
Could you check in the weblogic-ra.xml what acknowledge mode has been configured:
<property>
<name>AcknowledgeMode</name>
<value>AUTO_ACKNOWLEDGE</value>
</property>
...Note that when DUPS_OK_ACKNOWLEDGE is used it can happen that a message is consumed more than once.
Are you also sure that the message is not produced twice?
Seminar on Cloud Computing - http://middlewaremagic.com/weblogic/?p=7387

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
          >

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.

How to create Bridge connecting distributed Topic to queue

Hi,
I am trying to create a bridge which connects distributed topic with JMS queue.
Both the topic and queue are in the same domain.
But it is not getting connected. Status is failed.
Below is the configuration -
<messaging-bridge>
<name>DisTopicBridge</name>
<target>Managed_soa_server01</target>
<source-destination>DisTopicSource</source-destination>
<target-destination>QueueSource1</target-destination>
<selector></selector>
<quality-of-service>Exactly-once</quality-of-service>
<qos-degradation-allowed>false</qos-degradation-allowed>
<durability-enabled>true</durability-enabled>
<idle-time-maximum>60</idle-time-maximum>
<async-enabled>true</async-enabled>
<started>true</started>
<preserve-msg-property>false</preserve-msg-property>
</messaging-bridge>
<jms-bridge-destination>
<name>DisTopicSource</name>
<adapter-jndi-name>eis.jms.WLSConnectionFactoryJNDIXA</adapter-jndi-name>
<classpath></classpath>
<connection-factory-jndi-name>jndi/TestConnectionFactory</connection-factory-jndi-name>
<initial-context-factory>weblogic.jndi.WLInitialContextFactory</initial-context-factory>
<connection-url>t3://xxx.xx.xxx.40:9101</connection-url>
<destination-jndi-name>jndi/TestDistributedTopic</destination-jndi-name>
<destination-type>Topic</destination-type>
</jms-bridge-destination>
<jms-bridge-destination>
<name>QueueSource1</name>
<adapter-jndi-name>eis.jms.WLSConnectionFactoryJNDIXA</adapter-jndi-name>
<classpath></classpath>
<connection-factory-jndi-name>jndi/QConnectionFactory</connection-factory-jndi-name>
<initial-context-factory>weblogic.jndi.WLInitialContextFactory</initial-context-factory>
<connection-url>t3://xxx.xx.xxx.40:9101</connection-url>
<destination-jndi-name>jndi/TestQueue2</destination-jndi-name>
<destination-type>Queue</destination-type>
</jms-bridge-destination>
Error in the log:
<Warning> <MessagingBridge> <server-app-01> <Managed_soa_server01> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <d632395af8efc868:3b2a67dd:13752cfef88:-8000-00000000000d3c66> <1337198463908> <BEA-200026> <Bridge "DisTopicBridge" encountered some problems in one of its adapters or underlying systems. It stopped transferring messages and will try to reconnect to the adapters shortly. (The exception caught was javax.resource.ResourceException: Error setting message listener.)>
<Info> <MessagingBridge> <server-app-01> <Managed_soa_server01> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <d632395af8efc868:3b2a67dd:13752cfef88:-8000-00000000000d3c67> <1337198463908> <BEA-200020> <Bridge "DisTopicBridge" is stopped.>
<Info> <MessagingBridge> <server-app-01> <Managed_soa_server01> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <d632395af8efc868:3b2a67dd:13752cfef88:-8000-00000000000d3cb9> <1337198471319> <BEA-200034> <Bridge "DisTopicBridge" is shut down.>
Is there any special way we have to configure the Bridge while using Distributed topic?

Hello,
Please find the more details about the error we are receiving ( BEA-200026 )
http://docs.oracle.com/cd/E13222_01/wls/docs100/messages/Bridge.html
BEA-200026
Warning: Bridge "arg01" encountered some problems in one of its adapters or underlying systems. It stopped transferring messages and will try to reconnect to the adapters shortly. (The exception caught was t.)
Description
This message indicates that errors occurred during the process of transferring messages. The bridge stopped its connections to both adapters and will attempt reconnect soon.
Cause
There was a problem in receiving or sending messages to one of the sides of the bridge.
Action
No action required.
I would also request you to specify the version of weblogic and verify if the adapter is being deployed properly.
Please reveiw the bridge document
http://docs.oracle.com/cd/E11035_01/wls100/bridge/bridgefaq.html
Can you also check the status of the bridge
Messaging –> Bridges –> YOUR_Bridge_NAME –> Monitoring [tab]
Please provide the above required details
-Vishal Iyer

Messages for Durable Subscriber are not persisted with Distributed Topic

Setup:
          - Weblogic 8.1 SP 6 cluster with two nodes on single Sun Solaris 5.8 host
          - Distributed topic destination, separate JMS server with separate filestore for each node
          - Standalone durable JMS client connecting to distributed topic destination using specific JNDI name.
          - Messages are persistent (msg.setJMSDeliveryMode(DeliveryMode.PERSISTENT). Delivery mode override for topic destinations is set to "Persistent"
          Test:
          1) Both nodes up, starting durable topic subscriber -> durable subscriber is visible in Weblogic console -> sending X messages -> X messages are received :-)
          2) Both nodes up, killing durable topic subscriber -> durable subscriber is still visible in Weblogic console -> sending X messages -> Messages Current Count for durable subscribers is set to X -> starting JMS client again
          2a) subscribing to same node as before -> console says durable subscriber is active again -> X messages are received :-)
          2b) subscribing to other node -> durable subscriber is automatically migrated by Weblogic to this node, console says that subscriber is active, but Messages Current Count is 0 (zero) -> 0 (zero) messages are received :_|
          Where are my X messages gone?
          Should I open a call or did I misunderstand the basics?
          Thanks, Peter

According to Bea Customer Support this is the normal behavior. If you kill a durable topic subscriber and reconnect it with the same id to another node, the old subscription is deleted and all messages still waiting to be delivered are gone.
          Lesson learned: If you need failover for the server AND client use JMS queues.
          Peter

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

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

Durable subscribe to distributed topic

Hi,
          The documentation states:
          ========================
          Note:      Durable subscribers (DurableTopicSubscriber) cannot be created for distributed topics. However, you can still create a durable subscription on distributed topic member and the other topic members will forward the messages to the topic member that has the durable subscription.
          =======================
          1. What is the technical reason that prevents durable subscribers to be created for distributed topics?
          2. If we create a durable subscriber to individual members of the distributed topic, what are the failover characteristics?
          a. If there is a durable subscriber to one of the physical members of the distributed topic, what happens if the server hosting the physical member dies? Lets assume we have a 2 node cluster
          b. Are the messages persisted until the server comes up or does the durable subscriber automatically migrate to the other server?
          Thanks in advance!
          regards,
          Vish Tigadi

Hi there,
          1 - The technical requirement is to ensure that the durable subscription exists "exactly once" within the clustered destination - planned for a future release.
          2 and 2a - Durable subscriptions fail-over with their host destination.
          2b - JMS servers can automatically fail-over using "whole server" migration (as of version 9.0) per the doc, or manually fail-over using "service migration" (as of version 7.0?). In the next upcoming release (now available as a "tech preview"), we've added support for automatic service migration of JMS servers.
          Tom

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?

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:

A bug in distributed topic on WL8.1SP3 ?

Similar Messages

Maybe you are looking for