Durable Subscriber MDB
Getting the following error when creating a durable subscriber MDB to FioranoMQ:
2/24/04 10:50 AM Error listening to 'Fiorano JMS Topic : CACHELOCALHOST'
java.lang.InstantiationException: Error: null
at com.evermind.server.jms.OrionServerSessionPool.getServerSessionFull(OrionServerSessionPool.java:433)
at com.evermind.server.ejb.MessageDrivenHome.run(MessageDrivenHome.java:882)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:797)
at java.lang.Thread.run(Thread.java:534)
I have a standalone subscriber that works so I'm pretty sure this isn't a Fiorano issue.
Anyone had any luck in this type of situation?
Which versin of the appserver are using? MDB support for 3rd party JMS providers will only be supported in the next version of the appserver.
Similar Messages
-
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.
-
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. -
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 -
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. -
Durable Subscriber Stops Receiving Messages
We have a durable subscriber using an asynchronous listener that randomly stops receiving messages. After the application is restarted, messages delivery is re-activated. When the durable subscriber is in this state (where messages are not being delivered), the JMX Mbean "isActive" attributes is true. There are other durable subscribers on this same destination that receive messages as expected.
Has anyone observed this behavior for a durable subscription?What is the MQ version shown at beginning of the broker log ? Could you please give more description of your application and what the subscriber clients do ?
-
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 -
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 -
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).
-
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? -
Deploy MDBs in Different WL Instances Subscribed to Same Topic
Let's say I have MDBs X, Y, and Z, each needing to be deployed to a different Weblogic
server. All need to subscribe to the same Topic. How is this done? Specifically,
how is the Topic configured and how are the MBDs deployed?
Thanks,
Jim Goodwin
For your reading enjoyment, I'm posting some of my
internal notes on durable subscriber MDB's. This consolidates
newsgroup information in one place.
Jim Goodwin wrote:
> "Jim Goodwin" <[email protected]> wrote:
>
>>Let's say I have MDBs X, Y, and Z, each needing to be deployed to a different
>>Weblogic
>>server. All need to subscribe to the same Topic. How is this done? Specifically,
>>how is the Topic configured and how are the MBDs deployed?
>>
>>Thanks,
>>
>>Jim Goodwin
>
>
> Bah! Nevermind. I found the information I was looking for in other threads.
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 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.
-
MDB/Topic/WLS cluster question
Hi
I was going through some WLS 8.1 docs on JMS and had a question abt Topics & WLS
in cluster config where say I have 3 servers with say server#1 hosting the Topic
[not a distributed destination]. I have an an ear file containing an MDB with
no pool size limit. After deploying the ear in the cluster - lets say that each
server on the cluster has 5 instances of the MDB [just an example] and a message
is published on the Topic.
Q1>Will all the 3 servers get a [one and only one] copy of that message? [my guess
is yes]
Q2>Only 1 instance [out of 5] of the MDB/per server will get the message - right?
Q3> Had I had a separate deployment of the same MDB class in the EAR file for
the same Topic - thats just going to get treated as a completely separate subscriber
independent of the first MDB though the implementing class is the same - right?
thanks
Anamitra
Anamitra wrote:
> Hi
> I was going through some WLS 8.1 docs on JMS and had a question abt Topics & WLS
> in cluster config where say I have 3 servers with say server#1 hosting the Topic
> [not a distributed destination]. I have an an ear file containing an MDB with
> no pool size limit. After deploying the ear in the cluster - lets say that each
> server on the cluster has 5 instances of the MDB [just an example] and a message
> is published on the Topic.
>
> Q1>Will all the 3 servers get a [one and only one] copy of that message? [my guess
> is yes]
Yes.
> Q2>Only 1 instance [out of 5] of the MDB/per server will get the message - right?
Yes.
> Q3> Had I had a separate deployment of the same MDB class in the EAR file for
> the same Topic - thats just going to get treated as a completely separate subscriber
> independent of the first MDB though the implementing class is the same - right?
Yes.
>
> thanks
> Anamitra
>
For a little more information, I'm attaching notes on durable
subscriber MDBs.
A JMS 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.
In WebLogic 8.1 and previous, 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 connection id, which is unique within a cluster, 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.
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 above prevents a durable topic subscriber MDB from running on multiple servers. When an instance of the MDB starts on another server, it deploys successfully, but a conflict is detected and the MDB fails to fully connect to JMS. The work-around is the following:
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.
4) A copy of each message is sent to each to each server's MDB pool.
-
Client Id in use - WL6.1 sp3 server to server JMS messaging
Any feedback would be greatly appreciated. THANKS!
-Alan May
Scenario:
Two weblogic 6.1 sp3 instances running on two separate Solaris 8 boxes.
Server a - a message producer(client) for a number of topics and queues on b
Server b - hosts JMS services including all the topics and queues, has both
message producers and mdb consumers for a number of topics and queues
What I've set up: a durable connection factory for topics for server a,
topics for server b, queues for server a, and queues for server b (all
targeted to server b)
I have a singleton on each server that has methods to retrieve the queue
connection or topic connection appropriate for that server(a single
connection is
shared for all topic producers and a separate connection is share for all
queue producers for each server)
I have each producer open and close a new session every time. However, the
topic and queue connections are shared for all producers for that JVM. This
seemed to be the approach recommended by the JMS spec, but do you feel this
is the appropriate granularity given the above scenario? I am not currently
closing my jms connection as part of a weblogic shutdown class. Is that
essential in that case? If the server crashes - are there any
recommendations on how to handle(if closing the connection is the issue)?
I've confirmed that my JMS clients running with server b are not using the
connection factories setup for a's use.
Issue:
Everything works on server b as expected.
Server a's connections seemed to be fouled. I was getting that the clientid
was in use(stack trace included below) while trying to fetch the connection.
I stopped server a, removed the fouled connection factories on server
b(dedicated for server a's use), and created new connection factories for
a's use. I stopped server b and deleted everything from the two JMSState
and JMSStore tables, restarted a then b, and tried the test again. This
time the singleton code could fetch the connection without receiving a
JMSException, but I was getting an exception when I tried to open a session
from the connection.
If worst comes to worse, I can stick a stateless session bean on b, to act
as a delegate producer on behalf of server a, but I'd like to avoid it if
possible.
Any recommendations? Please let me know if it would be helpful for me to
clarify any points.
Server a's original error:
weblogic.jms.common.InvalidClientIDException: Client id, Parser.topicPrime,
is in use
Start server side stack trace:
weblogic.jms.common.InvalidClientIDException: Client id, Parser.topicPrime,
is in use
at
weblogic.jms.frontend.FEConnection.setClientId(FEConnection.java:918)
at weblogic.jms.frontend.FEConnection.<init>(FEConnection.java:178)
at
weblogic.jms.frontend.FEConnectionFactory$1.run(FEConnectionFactory.java:319
at weblogic.management.internal.Helper.doLocally(Helper.java:1656)
at
weblogic.jms.frontend.FEConnectionFactory.connectionCreate(FEConnectionFacto
ry.java:316)
at weblogic.jms.frontend.FEConnectionFactory_WLSkel.invoke(Unknown
Source)
at
weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:305)
at
weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java
:93)
at
weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:274)
at
weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:2
2)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
End server side stack trace
Hi Alan,
Lots of questions in one message! I'm going to
try and answer them using the shotgun approach -- let
me know if I miss.
(1) It is good practice to close JMS resources when you are done
with them, even if the destination host server crashes. The reason
is that the connection resource may be hosted on a different
WL server than the destination.
(2) Creating a session/producer per message is heavy-weight
in terms of CPU and network - if your app is performance
sensitive is is better to cache these resources for re-use.
See the JMS Performance Guide for details.
(3) From your description I can't tell which two
clients are conflicting. If what I'm writing here
doesn't help, please try to narrow it down and repost.
(4) Make sure that the connection factory does not have
a "client-id" configured for it. Otherwise only one client
can use the connection factory - instead have individual
clients dynamically set their ids.
(5) Note that client-ids are usually only useful for
durable subscriber access, as other types of clients
generally don't need exclusive connections, and therefore
don't need client-ids.
(6) The attached notes, which are for MDBs, may help you
understand durable subscriptions and client-id's better in general.
Tom
Alan May wrote:
> Any feedback would be greatly appreciated. THANKS!
>
> -Alan May
>
>
> Scenario:
>
> Two weblogic 6.1 sp3 instances running on two separate Solaris 8 boxes.
>
> Server a - a message producer(client) for a number of topics and queues on b
>
> Server b - hosts JMS services including all the topics and queues, has both
> message producers and mdb consumers for a number of topics and queues
>
> What I've set up: a durable connection factory for topics for server a,
> topics for server b, queues for server a, and queues for server b (all
> targeted to server b)
>
> I have a singleton on each server that has methods to retrieve the queue
> connection or topic connection appropriate for that server(a single
> connection is
> shared for all topic producers and a separate connection is share for all
> queue producers for each server)
>
> I have each producer open and close a new session every time. However, the
> topic and queue connections are shared for all producers for that JVM. This
> seemed to be the approach recommended by the JMS spec, but do you feel this
> is the appropriate granularity given the above scenario? I am not currently
> closing my jms connection as part of a weblogic shutdown class. Is that
> essential in that case? If the server crashes - are there any
> recommendations on how to handle(if closing the connection is the issue)?
>
> I've confirmed that my JMS clients running with server b are not using the
> connection factories setup for a's use.
>
> Issue:
> ------
> Everything works on server b as expected.
>
> Server a's connections seemed to be fouled. I was getting that the clientid
> was in use(stack trace included below) while trying to fetch the connection.
>
> I stopped server a, removed the fouled connection factories on server
> b(dedicated for server a's use), and created new connection factories for
> a's use. I stopped server b and deleted everything from the two JMSState
> and JMSStore tables, restarted a then b, and tried the test again. This
> time the singleton code could fetch the connection without receiving a
> JMSException, but I was getting an exception when I tried to open a session
> from the connection.
>
> If worst comes to worse, I can stick a stateless session bean on b, to act
> as a delegate producer on behalf of server a, but I'd like to avoid it if
> possible.
>
> Any recommendations? Please let me know if it would be helpful for me to
> clarify any points.
>
>
>
> Server a's original error:
> weblogic.jms.common.InvalidClientIDException: Client id, Parser.topicPrime,
> is in use
>
> Start server side stack trace:
> weblogic.jms.common.InvalidClientIDException: Client id, Parser.topicPrime,
> is in use
> at
> weblogic.jms.frontend.FEConnection.setClientId(FEConnection.java:918)
> at weblogic.jms.frontend.FEConnection.<init>(FEConnection.java:178)
> at
> weblogic.jms.frontend.FEConnectionFactory$1.run(FEConnectionFactory.java:319
> )
> at weblogic.management.internal.Helper.doLocally(Helper.java:1656)
> at
> weblogic.jms.frontend.FEConnectionFactory.connectionCreate(FEConnectionFacto
> ry.java:316)
> at weblogic.jms.frontend.FEConnectionFactory_WLSkel.invoke(Unknown
> Source)
> at
> weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:305)
> at
> weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java
> :93)
> at
> weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:274)
> at
> weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:2
> 2)
> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
> End server side stack trace
>
>
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
-
All mail going into spam folder
After upgrading to Lion all mail going straight to spam folder, even the addresses saved in address book. Any suggestions on how to fix?
-
CS3 won't install completely under OS X 10.6.8
I'm attempting to move CS3 Web Premium from my MacBook Pro (OS X 10.6.8) to my iMac (OS X 10.8.3). When I run the installer on my iMac the following are NOT installed: * Flash * Illustrator * Photoshop * Shared Components * Create Suite 3 Web Premium
-
Not able to post Realized Gain/Loss GL acct during foreign vendor payment
Dear Experts. 1. When I make a vendor payment by using F-53 for USD payment for foreign vendor. I am supposed to get Realised Gain /Loss account for the variation on payment date. 2. My local currency is INR and foreign Currency is USD. 3. DIrect
-
Does anyone have a method to clear the password cache programmatically? I want to prevent access to password protected block diagrams after I've done some block diagram changes but without restarting LabVIEW or navigating the Options menu Thanks Al
-
MacBook Pro doesn't turn on at all
Hello, I am Luixituh, and I am in a terrible situation with my MacBook Pro, the thing is that I have been using it very happily since yesterday I went to use it and I pressed the power button to turn on, but absolutely nothing happened. I tried to ch