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

Similar Messages

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?

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

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 Topic - Deliver to only one Durable Subscriber

Hi,
Is it possible to put a message onto a topic but only have it delivered to a single durable subscriber?
I realise this breaks the rules of what a topic is but this is for a scenario where a single subscriber has errored when processing the original message from the topic. I am putting a user interaction process to recover it and if the user selects ‘resubmit’ I want to put the message back on the topic but only deliver it to the one subscriber that failed to process the message.
My ways to achieve this (in order of preference) would be.
1.     JMS Adapter
2.     Writing Java to use JMS API
If neither of these are possible than:
3.     Create a System Resubmit queue and have every composite look for message on the resubmit queue (with their client ID) as well as the normal topic they use
Of course I would like to avoid 3 as it introduces a complication into every process we create that takes messages from a JMS Topic.
Thanks for your help.
Robert

I could suggest a (dirty) trick:
all subscribers subscribe to the topic using a filter (message selector, http://docs.oracle.com/javaee/6/tutorial/doc/bnceh.html#bncer)
SUBSCRIBER1 uses:
destination = ALL OR SUBSCRIBER1
SUBSCRIBER2 uses:
destination = ALL OR SUBSCRIBER2
etc
The first message has the property destination set to ALL, so all subscribers will process it.
The resubmitted message will have destination = SUBSCRIBER<N>, where N is the failed subscriber

Error of Foreign JMS server connecting to durable subscriber topic

Weblogic server domain is trying to connect to the durable topic configured on the other weblogic domain. (Both domain are running on weblogic 9.2 platform)
WLI 9.2 Event generator is TestPinFJ is the MDB which is trying to listen message from Foreign JMS.
Following error we have got when I did following configuration for connecting to durable topic using foreign JMS.
<EJB> <BEA-010061> <The Message-Driven EJB: TestPinFJ is unable to connect to the JMS destination: TestQueue. The Error was:
java.lang.IllegalArgumentException: port out of range:-16>
Detail configuration is as follows:
Foreign JMS : TestFS
General:
JNDI Connection URL: t3://10.20.65.95:9004 TestClient123 (where TestClient123 is the client id for durable subscriber topic )
Destinations:
Local JNDI Name: TestQueue
Remote JNDI Name: TestTopic
Connection Factories :
Local JNDI Name: TestQCF
Remote JNDI Name: TestTCF
My suspect is the JNDI connection URL is incorrect. Please advice how to configure JNDI conn url while connecting to durable topic with client id?

hi Hussain,
I am the collegue of the person created this thread.
Thaks for the input. can u please suggest me how do we configure connectionfactory and JSM topic to durable subscription with ClientID.Shoudl th eClientID be same for JMSTopic and ConectionFactory?
In Domain "A" I have created JMS topic with durable subscriber wioth client ID "TestClient123" and created a conenctionfacory with same client ID "TestClient123" .
In Domain "B" i created a foreign JMS connecting to topic in Domain A using connection facatory created in Domain "A" configured as as remoteConnectionFActory.
Also the JNDI Connection URL is : t3://10.20.65.95:9004
"weblogic.jms.common.InvalidClientIDException: Client id, Testclient1, is in use. The reason for rejection is "The JNDI name weblogic.jms.connection.clientid.TestClient123was found, and was bound to an object of type weblogic.jms.frontend.FEClientIDSingularAggregatable : FEClientIDSingularAggregatable(SingularAggregatable(<9222810352589496374.1>:1):TestClient123)"
Nested exception: weblogic.jms.common.InvalidClientIDException: Client id, EAIEXTTestClient123, is in use. The reason for rejection is "The JNDI name weblogic.jms.connection.clientid.TestClient123 was found, and was bound to an object of type weblogic.jms.frontend.FEClientIDSingularAggregatable : FEClientIDSingularAggregatable(SingularAggregatable(<9222810352589496374.1>:1):TestClient123)".
weblogic.jms.common.InvalidClientIDException: Client id, EAIEXTTestClient123, is in use. The reason for rejection is "The JNDI name weblogic.jms.connection.clientid.TestClient123 was found, and was bound to an object of type weblogic.jms.frontend.FEClientIDSingularAggregatable : FEClientIDSingularAggregatable(SingularAggregatable(<9222810352589496374.1>:1):TestClient123)"
at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:211)"
IS there any chnage i need to make to get this connectivity between Domain A and B working?
Appreciate your help on this.

Durable subscriber configured for the topic - reconnect policy

Hi,
we have Durable subscriber configured for the topic. When ever the managed server associated with the Topic is restarted, we have to restart subscriber to receive the messages again.
we did tried using the reconnect policy to all , still we have same issue, could you please provide your suggestions.
Susbcriber is not throwing the connect exception as well,when ever the managed server goes down also.
thanks
ARun

I would suggest, if you have done so, that you set an Exception listener on the connection, or on the session using WLS extension interface, so that your client will get Exception on server failure and refresh the JMS objects (connection/session/subscriber).

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
          >

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 subscriber question

Hi,
          wls 8.1.4.
          Scenario: Durable subscriber (DS) connects to a jms distributed topic member T1.
          DS gets disconnected and has a backlog of messages.
          DS connects to jms distributed topic member T2 (on a different jms/managed server) (using the same client-id it had used when connecting to T1).
          Looks like the subscription starts afresh and the backlog (from T1) is lost.
          Is this the expected behavior. Any way we can make this DS reconnect carry forward the state (backlog) as well.
          Thanx,

Examples that comes with the O'Reilly book on the subject can be found at http://examples.oreilly.com/javmesser
In there you can find a couple of examples on durable subscriptions.
For other questions you have refer to the JMS specifications http://java.sun.com/products/jms/jms1_0_2-spec.pdf

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.

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]

Durable subscriber problem in 10G

Hello all,
We are trying to upgrade an application which uses AQ from Oracle 9i to 10G (10.2.0).
While having a topic owned by one user (metr_data) and trying to create a durable subscriber as another one (metr), we're getting an ORA-01031 error. Just dequeueing
messages as this user works fine...
Is there some additional privilege to be granted for creating durable subscribers?
A small test program:
// Create queue as metr_data
Properties p = new Properties();
p.put("user","metr_data");
p.put("password","metr_data");
Connection c1 = DriverManager.getConnection("jdbc:oracle:thin:system/system@//localhost:1521/WTS",p);
TopicConnection topicConnection1 = AQjmsTopicConnectionFactory.createTopicConnection(c1);
topicConnection1.start();
AQjmsSession topicSession1 = (AQjmsSession)topicConnection1.createTopicSession(true,0);
AQQueueTableProperty qtp = new AQQueueTableProperty("SYS.AQ$_JMS_TEXT_MESSAGE");
qtp.setMultiConsumer(true);
AQQueueTable qt = topicSession1.createQueueTable("metr_data", "testtab", qtp);
System.out.println("Created table");
AQjmsDestinationProperty dp = new AQjmsDestinationProperty();
AQjmsDestination t = (AQjmsDestination) topicSession1.createTopic(qt, "test",dp);
System.out.println("Created queue" );
Topic topic1 = topicSession1.createTopic("METR_DATA.test");
System.out.println(topic1);
( (AQjmsDestination)topic1).grantTopicPrivilege(topicSession1, "DEQUEUE","metr", false);
// Access queue as metr
Connection c = DriverManager.getConnection("jdbc:oracle:thin:system/system@//localhost:1521/WTS","metr","metr");
TopicConnection topicConnection = AQjmsTopicConnectionFactory.createTopicConnection(c);
topicConnection.start();
TopicSession topicSession = topicConnection.createTopicSession(true,0);
Topic topic = topicSession.createTopic("metr_data.test");
System.out.println(topic);
TopicSubscriber s = topicSession.createDurableSubscriber(topic,"metr");
System.out.println(s);
I do have granted the metr user execute on the 4 traditional aq packages.....
Regards,
Francois.

Hi All,
I am able to connect again using the same clientid when i stop/start the web application. I am just curious why the command "imqcmd destroy dur" has no effect on such a situation.

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>

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

Durable subscribe to distributed topic

Similar Messages

Maybe you are looking for