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?
Similar Messages
-
Updating versioned app with Uniform Distributed Topic fails on 10.3.3
I have a versioned ear application running on a two server cluster. It has a MDB that accesses a Uniform Distributed Topic (global jndi, setup in console). When I increment the version and do an update/redeploy and click Activate, it gives an error saying that one of my entity beans is already bound to the JNDI tree.
If I disable the Uniform Distributed Topic / MDB connection by changing the JNDI name of the Uniform Distributed Topic in the console, then I can redeploy/update fine with no errors!
Looking at the log, that entity bean is initialized right after the MDB that attaches to the Uniform Distributed Topic.
Another thing to note is both versions are active after the error (rather than the newer version doing a stop run on the older version). However the newer version is not fully initialized on the second server in the cluster. The UDT is currently targeted to a subdeployment that targets only the migratable JMS Server pinned to the first server. I have also tried targeting it to all members of the cluster. I do only have one JMS Server that is migratable and is currently pinned to the first server.hello guri,
can you give us the exact error message, or even a screenshot please ?
The search box on top-right of this page is your true friend, and the public Knowledge Base too: -
Uniform Distributed Topics and Unicast Cluster Messaging
...seem to be incompatible. I have a WLS 10.0 domain that has a cluster of servers to which a uniform distributed topic is deployed. There is an MDB listening to the topic member in each server. A stateless session EJB publishes to the distributed topic from one of its methods, and I expect every MDB instance to receive the message. This works correctly when the cluster is configured with multicast messaging, but when I configured the cluster to use unicast messaging (as recommended in the documentation) the MDB on the server that receives the EJB call is the only MDB that receives the message.
Is there something else I need to configure?...seem to be incompatible. I have a WLS 10.0 domain that has a cluster of servers to which a uniform distributed topic is deployed. There is an MDB listening to the topic member in each server. A stateless session EJB publishes to the distributed topic from one of its methods, and I expect every MDB instance to receive the message. This works correctly when the cluster is configured with multicast messaging, but when I configured the cluster to use unicast messaging (as recommended in the documentation) the MDB on the server that receives the EJB call is the only MDB that receives the message.
Is there something else I need to configure? -
Message payload logging for Uniform Distribute Queue
Hi All,
We have a requirement to log the message payload, of every jms message received in a Uniform Distribute Queue in Weblogic.
Please let us know how can we achieve this.
Thanks.If you want to avoid use of the Path Service, then the alternative is to make the destination members highly available. This will help ensure that the host member for a particular UOO is up.
One approach to HA is to configure "service migration". For more information see the Automatic Service Migration white-paper at
http://www.oracle.com/technology/products/weblogic/pdf/weblogic-automatic-service-migration-whitepaper.pdf
In addition, I recommend referencing Best Practices for JMS Beginners and Advanced Users
http://docs.oracle.com/cd/E17904_01/web.1111/e13738/best_practice.htm#JMSAD455 to help with WL configuration in general.
Hope this helps,
Tom -
How to enable JMS logging to capture message body for Uniform Distributed Q
Hi All,
we need to log JMS message body for our PROD env. but we do not see any "All Body" option in JMSQueue-> logging for our Uniform Distributed Queue.
Please let me know how can we achieve our requirement.
Thanks in Advance.got the solution.
This is a know bug - [ID 1377584.1]
adding below parameters in config/jms file should do the requirement.:
<message-logging-params>
<message-logging-enabled>true</message-logging-enabled>
<message-logging-format>%header%,JMSCorrelationID,JMSDeliveryMode,JMSDestination,JMSExpiration,JMSMessageID,JMSPriority,JMSRedelivered,JMSReplyTo,JMSTimestamp,JMSType,%properties%,JMSXDeliveryCount,JMSXUserID,JMS_BEA_DeliveryTime,JMS_BEA_RedeliveryLimit,JMS_BEA_UnitOfOrder,*%body%*</message-logging-format>
</message-logging-params>
Edited by: Bob on May 10, 2013 11:53 AM -
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 -
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, PeterAccording 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 -
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 TigadiHi 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 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
ARunI 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).
-
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.
RobertI 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. -
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
>
-
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>
<!--
<destination-type>javax.jms.Topic</destination-type>
<subscription-durability>Durable</subscription-durability>
-->
</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>
<!-- Sample MessageDriven bean Weblogic deployment descriptor -->
<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>quotestopic</destination-jndi-name>
-->
<destination-jndi-name>MDBQ</destination-jndi-name>
<!--
<provider-url>t3://localhost:10001</provider-url>
<connection-factory-jndi-name>cf3</connection-factory-jndi-name>
<jms-client-id>cid444</jms-client-id>
-->
</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.
Maybe you are looking for
-
IMovie crashes when click on create iDVD project
IMac Power PCG5 1.8 GHz, 768 MB DDR SDRAM, running Tiger (can't find the version, but must be the latest) iMovie 4.0.1 iDVD 4.0.1 I worked on my iMovie project for months, I cliked iDVD on the right, added chapters. When I click on "Create iDVD proje
-
Where Is File Stored On Computer When Using: File.applicationStorageDirectory
When using the File.applicationStorageDirectory function, where is Adobe storing the program on an Windows/Apple computer? I know what it means, but I would just like to be able to verify for myself that the file is being created when I'm developing
-
Ideacentre A720 - Recover Partition (One Key Recovery) doesn't boot
My System was without a SSD Drive, but I upgraded it by my own and everything was allright after I cloned the System to the SSD-drive. I keep the "LENOVO_PART" (20gb) on my HDD, and the rest of it was just for Data-storage. 2 Month later Iwanted to c
-
SAP timezone vs Windows Timezone
Hello all, is there any way to map Windows timezones to ABAP ones (for example, any ABAP function)? That means, for example, '(GMT+01) Amsterdam, Berlin, ...' in Windows to 'CET' in SAP. Thanks.
-
I need help with installing the flash player!
I am trying to install the flash player and as the download progresses it asks me to close internet explorer to continue. I close internet explorer and press the continue button and it repeats the request to close internet explorer. I have complete