Topic vs MDB's
Hi,
We are designing an application which will serve as message broker between different
publisher and subscriber applications. We are planning to use Weblogic 6.1 JMS
for that purpose. Could you please let me know what are the pros and cons of having
multiple topics for different types of messages VS having a single topic serving
all types of messages and multiple MDB's with message selectors to process those
messages?
Also, could you please let me know the resources I can refer for looking at different
design patterns and design considerations for this type of JMS message broker?
Thanks,
Goutam.
Jason -- One important point is that the EJB specification (specifically MDBs) does not guarantee FIFO processing. Here is the quote from section 15.4.6 of the spec:
A container allows many instances of a message-driven bean class to be executing concurrently, thus allowing for the concurrent processing of a stream of messages. No guarantees are made as to the exact order in which messages are delivered to the instances of the message-driven bean class, although the container should attempt to deliver messages in order when it does not impair the concurrency of message processing. Message-driven beans should therefore be prepared to handle messages that are out of sequence: for example, the message to cancel a reservation may be delivered before the message to make the reservation.
That said, I have seen queuing systems that have used both types of arrangements you describe (although none were using JMS.) For the generic case, there were problems if the queue was backed up so you might consider multiple queues with different priorities, each of which has a generic payload. This helps starvation of time critical messages.
If you do establish different topics, then you will have more work to do in terms of deployment and management of the topics, but the messages will be cleanly separated and you may be able to make some optimizaitons of message processing since they can be created in a form that best mathces their use.
Overall, my experiences with generic queues, once we established multiple queues with different priorities, was good. Just be ready for the additional overhead of processing XML messages.
Thanks -- Jeff
Similar Messages
-
One Topic, One MDB, Multiple Deployments?
I want to deploy EJBs representing multiple applications in a single server. Each
of these applications has different reasons for wanting to receive messages sent
to a particular single system-wide "event" topic. Ideally, I would develop a single
MDB class that each application would deploy with its own message selector(s). This
sounds like it should work -- but then I saw this in section 4.11 of the JMS Performance
Guide:
"Note: Topic-driven MDBs have vendor-specific semantics. In WebLogic, MDBs that listen
on a
topic currently receive one message per deployment [as of 6.0SP1]. If you have an
MDB with
multiple instances on a single server listening on a topic, it will receive only
one copy of a
published message regardless of the number of instances. If you have an MDB deployed
across
multiple machines listening on a topic, then each deployment will receive a copy
of any published
message on that topic. In other words, you will get multiple copies of the message
distributed
evenly once to each of your MDB deployments."
Does this mean that I can't do what I described above?
TIA,
Mark
I think WL is giving you the behavior you are looking for. The same MDB pool with multiple
instances will only receive one copy of the message. Different MDB pools will each receive
their own copy of the message, regardless of what server they exist on.
For example,
A1: MDB pool with selector x=a,
A2: MDB pool with selector x=a
B: MDB pool with selector x=b
AB: MDB pool with selector x=a OR x=b
publish msg property x = a:
pool A1 will receive one copy of msg and give to one of its instances
pool A2 will receive one copy of msg and give to one of its instances
pool AB will receive one copy of msg and give to one of its instances
pool B will NOT receive the msg
Tom
Mark Shaffer wrote:
> I want to deploy EJBs representing multiple applications in a single server. Each
> of these applications has different reasons for wanting to receive messages sent
> to a particular single system-wide "event" topic. Ideally, I would develop a single
> MDB class that each application would deploy with its own message selector(s). This
> sounds like it should work -- but then I saw this in section 4.11 of the JMS Performance
> Guide:
>
> "Note: Topic-driven MDBs have vendor-specific semantics. In WebLogic, MDBs that listen
> on a
> topic currently receive one message per deployment [as of 6.0SP1]. If you have an
> MDB with
> multiple instances on a single server listening on a topic, it will receive only
> one copy of a
> published message regardless of the number of instances. If you have an MDB deployed
> across
> multiple machines listening on a topic, then each deployment will receive a copy
> of any published
> message on that topic. In other words, you will get multiple copies of the message
> distributed
> evenly once to each of your MDB deployments."
>
> Does this mean that I can't do what I described above?
>
> TIA,
>
> Mark
-
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.
-
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.
-
Is there any stadard patterns for achnowledging the client from the MDB regarding the success of a method call.
I can make the client to listen on a particular Queue/Topic and MDB can send the status to this configured Queue or Topic.
Is there any other alternative for this?Can you be more clear on what meant by pattern in this
case? What exactly is the scenario and kind of
solution you are looking for?Our aim is to make an asynchronous method call from the swing based client in the J2EE environment. For that we have set up a cliet in such away that one thread woould listen on a TOPIC on the client side.
Client makes request to an MDB on the server side. While making a request some errors may occur. But we couldn't find a suitable mechanisam to give it back to client.
This is the scenario. Pls help me to find suitable solution? Is there any betterway to make asynchrnous calls from Swing client in J2EE environment. -
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.
-
Hi
We need to see at that any instance of time there should min of 5 MDB instances ready and listening to a external JMS Tibco queue.
We tried to set max-instances="10" min-instances="5" for the message driven bean deployment in orion-ejb-jar.xml - but still seems to instiate only one activeBean.
<message-driven-deployment
name="MessageDrivenEJB1"
resource-adapter="TibcoJMSRAInstanceName">
<resource-ref-mapping name = "jms/queueConnectionFactory" location = "TibcoJMSRASubcontext/MyQCF"
max-instances="10" min-instances="5"/> <!-- don't misspell this or you'll get an RP CF which doesn't work -->
<config-property>
<config-property-name>ConnectionFactoryJndiName</config-property-name>
<config-property-value>TibcoJMSRASubcontext/MyQCF</config-property-value>
</config-property>
<config-property>
<config-property-name>DestinationName</config-property-name>
<config-property-value>TibcoJMSRASubcontext/MyCCQ</config-property-value>
</config-property>
<config-property>
<config-property-name>DestinationType</config-property-name>
<config-property-value>javax.jms.Queue</config-property-value>
</config-property>
<config-property>
<config-property-name>ListenerThreadMaxPollInterval</config-property-name>
<config-property-value>250</config-property-value>
</config-property>
</message-driven-deployment>
Verified - EM console "System MBean Browser" - OC4J>J2EE Server>J2EE Application>EJB Module>MessageDriven Bean> MessageDrivenEJB1
activeInstances is set as 0 (ReadOnly)
activeInstancesHighWaterMark is set to 1 (ReadOnly)
How do we get see that there are always 5 minmum instances ready.
We are connecting to Tibco queue using ra.xml, oc4j-ra.xml (resource adapters) - looking up queues using FileSystemContext - com.sun.jndi.fscontext.RefFSContextFactory
Using - Oracle Enterprise Manager 10g Application Server Control 10.1.3.3.0
Any help/pointers in this regard will be of great help.
Thanks
sunderAshar,
This is expected behavior. Messages are pushed to asynchronous consumers in batches, where the maximum backlog is configurable on the consumer's connection factory via the "MessagesMaximum" setting. If you pushed more than 10 messages at a time, you would start to see the load balance out.
So, to reduce the backlog, create a custom connection factory with
- "MessagesMaximum" set to its minimum
- user and XA transactions enabled (to support transactions)
- acknowledge policy set to "previous" (needed if the connection factory is ever used for non-transactionally topic drive MDBs)
And then modify the MDB's WL descriptor file to refer to the JNDI name of this connection factory.
You can find a nice summary ofMDB descriptor attributes in the 8.1 docs (these docs still apply to 7.0).
I'm fairly sure that in 7.0 even with MessagesMaximum set to its minimum, there still can be a backlog of one message. If this is a problem, you might try contacting customer support - they may have a solution for this...
Tom -
MDB Durables in Cluster Servers
Hello,
we have two managed servers in cluster WebLogic Server8.1 SP4. We need to use MDB´s Durables whit distributed queues.
I have read that there are problems whit distributed topics and MDB´s durables, that only works if the MDB´s have different jms-client-id in each node of cluster.
There are the same problem whit distributed queues?, can we deployed the same MDB in cluster whit distrubuted queues?
Thanks in advance, Lourdes Ruiz.Hi,
I think you're refering to "durable topic subscriptions". The issues surrounding using "durable topic subscriptions" with distributed topics do not apply to distributed queues.
In general, the term "durable" in JMS specifically refers to "long-lived" topic subscriptions, not to queues or persistent messages. Queues don't have the concept of "durable consumers".
Tom -
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.
-
Clustered WebLogic MDB receiving multiple messages...
Hi all,
I have a JMS WebLogic clustering problem.
First, let me describe the problem. The MDB of my application (it's a simple test application to get the clustering kinks worked out) is listening to a Topic and when I publish a message to the Topic the MDB is receiving the message multiple times. I have a max of 4 managed servers in my cluster and when they are all running, each MDB on each managed server gets the message 4 times. If I shut down two of the managed servers, then each MDB on each of the two running managed servers get the message 2 times. So my MDB is receiving the message multiple times equal to the number of manged servers I have running in my cluster.
So my question is what is the proper way to configure JMS Servers for a cluster?
Next I want to explain how I start the managed servers in the cluster. At this time I am unable to use NodeManager so starting of the instances is done manually via command line. Basically it's a wrapper around the startManagedWebLogic.sh script. I know something is wrong with my JMS configuration because when I start the managed servers I will typically see an error which looks like this:
<Warning> <EJB> <BEA-010061> <The Message-Driven EJB: MyMDB is unable to connect ot the JMS destination: jms/myTopic. The error was:
werblogic.jms.common.JMSException: could not find Server NAME_OF_MANAGED_SERVER
Nested exception: weblogic.jms.common.JMSException: could not find Server NAME_OF_MANAGED_SERVER
Nested exception: weblogic.jms.common.JMSException: could not find Server NAME_OF_MANAGED_SERVER
Nested exception: weblogic.jms.common.JMSException: could not find Server NAME_OF_MANAGED_SERVER
Nested exception: weblogic.messaging.dispatcher.DispatcherException: could not find Server NAME_OF_MANAGED_SERVER
Nested excpetion: javax.naming.NameNotFoundException: Unable to resolve 'weblogic.messaging.dispatcher.S:NAME_OF_MANAGED_SERVER'. Resolved 'weblogic.messaging.dispatcher'; remaining name 'S:NAME_OF_MANAGED_SERVER'>
Despite this error message, the MDB on that manged server does still successfully recieve messages posted to the Topic, though, as stated earlier, my problem is the MDB is getting the message more than once.
Also, I've confirmed all managed servers in the cluster can receive the message posted to the Topic no matter which managed server posts the original message.
Next is to explain my cluster configuration. I'm sure I know is is wrong, but not sure where my mistake is. Here is my JMS configuration for the cluster.
4 JMS Servers
Persistence Store:
Each JMS Server has its own persistent store
Each store targets one of the 4 (migratable) managed servers
Each store is a FileStore
Filesystem is not shared between VMs in the cluster
Target:Each JMS server targets one of the 4 (migratable) managed servers
1 JMS ModuleTarget: The cluster - "All servers in the cluster"
1 JMS Topic
Destination type: Uniform
Forwarding Policy: Replicated
Template: None
Target: The cluster - "All servers in the cluster"
Subdeployment: Default Targeting
1 JMS ConnectionFactory
Subscription Sharing Policy: Exclusive
Client ID Policy: Restricted
XA connection factory enabled (YES)
Target: The cluster - "All servers in the cluster"
Subdeployment: Default TargetingHi Michael,
I need to clarify exactly what you want to happen. What you are saying you want is not typical. I expected you to say you wanted Scenario 8 or 9. Those are the most common.
I will try to capture what your words are saying in "graphic text". I'm not sure that the graphic in the document is accurate.
Server 1 Server 2 Server 3 Server 4
JMS svr 1 JMS svr 2 JMS svr 3 JMS svr 4
DistTopic-mem1 DistTopic-mem2 DistTopic-mem3 DistTopic-mem4
MDB listens locally MDB listens locally MDB listens locally MDB listens locally
Events...
1. Message published
on Server 1
2. Message is replicated
to server 2
3. Local MDB get message
4. Message is replicated
to server 3
5. Local MDB gets message
6. Message is replicated
to Server 4
7. Local MDB gets the message
8. Local MDB gets the message.
This is the standard Replicated Distributed Topic flow. Messages are replicated, and every message is forwarded to every member of the distributed topic.
In the case, each message will be processed 4 times - once per server.
This is what your text says you want.
This is scenario 1 in the doc.
I don't really know what is going wrong with your MDB. The topics are getting created per your comment about the ability to publish a message.
Are you seeing errors during deployment?
To answer your question about where to set topicMessagesDistributionMode and distributedDestinationConnection, they are set in a deployment descriptor or in an annotation in the MDB. See http://docs.oracle.com/middleware/1213/wls/WLMDB/summary.htm#WLMDB1385..
Let me know if I described what you want to happen.
If so, a replicated distributed topic and an MDB deployed to the cluster should just work with no need to set the descriptor elements.
Dave -
Development Component (DC) Structuring Issue
Hello,
Following is the scenario where I am facing the problem :
I have J2EE LIB DC which contains JAVA DC--Lets call this DC as LibDC
I have two EP DC--Lets call these dc's as epDC1 and epDC2
I have EAR (EJB) DC..where I am using Message Driven Bean (MDB) --that is subscribed to Topic inorder to read the messages...Lets call this DC as earDC.
LibDC contains the classes that are shared by all the DC's (epDC1,epDC1,earDC) and JMS client is also the part of this DC (LibDC).
Now epDC1 trigger the JMS by calling the method sitting in LibDC..which in turn publish the message to topic and MDB consume the message and do the remaining business process.
Whole scenario works perfect when I deploy all the DC's...but the problem is.. When ever I make changes to epDC1 and deploy it..it won't work and throws the exception as CLASSCASTEXCEPTION or NOCLASSDEFFOUNDERROR...But If I deploy all the DC's than I dont see any problem..
Every time If I deploy any DC that is using LibDC than I am getting the exception...but If I redeploy all the DC's than I dont have any issues.
Please let me know how to resolve this issue.
Thanks
Edited by: hammad khan on Oct 31, 2008 11:57 PMHi,
These errors occurs due to inconsistencies and DC not in sync. check the service packs and versions numbers of the SCA files your are importing. Also import the dependencies into your track.
Regards,
Anil. -
JMS Foregin server configuration with two Weblogic 8.1 AS
Hi,
I have two Weblogic8.1 AS. Box 1 is configured with JMS connection factory and Topic. MDB is deployed on Box 2, which is configured to listen to Box1 JMS Topic. I am running session bean which is publishing JMS message to the Topic on Box1. Also, I have configured JMS foreign Server on Box2 pointing to Box1 connection factory and Topic.
MDB throws error "Destination not found", while deploying. I read somewhere in the net, that We need Weblogic with Clustering licence for configuring Foreign JMS Server.
Pls. help me.
Regards
Anand Bobadehi... can you please send me the java code for messaging part ...... i want to know how you are sending
message from server and it is listened at different server?
I am also in same condition....I have configured JMS foreign server on box 1 .....on box2 my MDB is listening....
My problem is how do i send a message to a foreign queue which is inside JMS Foreign Server..... I am not able to give any JNDI name to this server... so please send me the code from which you are sending the Message.
Thanks in advance -
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.
-
Release jms connection doesn?t release.
Hi All,
Environment: WLS 7.0sp2, JMS: weblogic JMS JMSJDBCStore, database oracle9
We invoke the following sendEvent code from a worker thread invoked by a scheduler
that was started in a servlet init method (this worker thread code is wrapped
with a user tx).
The topic’s MDB is getting the message OK, however the number of connection in
the monitor (mydomain> JMS Servers> NomJMSServer> Active JMS Servers) keep growing.
As you can see we are releasing the connection in a finally block. Can anybody
explain it.?
Second question: Should we cache the jms session? If the answer is yes, can they
expire (close), how do we check if they are still valid?
Thanks
public String sendEvent(SyncOutput event)
String retval = null;
try
init();
topicPublisher.publish( formatMessage(event) );
catch (Exception e)
logger().debug("cannot send event", e);
}finally{
release();
return retval;
private Message formatMessage(SyncOutput output)
throws JMSException, IOException
BytesMessage message = topicSession.createBytesMessage();
GZIPOutputStream gzip = new GZIPOutputStream(new BytesMessageOutputStream(message));
output.flush(new OutputStreamWriter(gzip));
gzip.close();
return message;
private void init()
throws Exception
InitialContext context = new InitialContext();
TopicConnectionFactory conFactory =
(TopicConnectionFactory) context.lookup(JMSConfig.get(JMSConfig.FACTORY));
topicConnection = conFactory.createTopicConnection();
topicSession = topicConnection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
Topic topic = (Topic) context.lookup( this.jndiName );
topicPublisher = topicSession.createPublisher(topic);
topicPublisher.setDeliveryMode( DeliveryMode.PERSISTENT );
private void release()
try{
if (topicPublisher != null){
topicPublisher.close();
topicPublisher = null;
if (topicSession != null){
topicSession.close();
topicSession = null;
if (topicConnection != null) {
topicConnection.close();
topicConnection = null;
System.gc();
}catch(Exception ignore){
ignore.printStackTrace();
We found the problem, it was a bug in our code. Thanks for your help.
Tom Barnes <[email protected]> wrote:
>Its possible the monitor has a bug, but in your case, since
>you now only create one connection how could the
>connection count keep growing?
>
>Perhaps the MDB app or MDB container is failing in some
>unexpected way and not
>closing its connection before attempting to create a new one?
>Check your log for warnings and error messages, and
>consider encapsulating your onMessage() code with a
>try { /* all onMessage code */ }
>catch (Throwable t) { t.printStackTrace(); rethrow}
>
>Meir wrote:
>> Is it possible that the monitor has a bug? I changed my code to cache
>the topic
>> session and topic publisher, so I always use the same one (they are
>static members
>> of the class) but this didn't change the result that I'm seeing in
>the monitor
>> - the number of connections still keep growing.
>> Could it be TX related weirdness (note we set the factory "User Transactions
>Enabled"
>> attribute to true)?
>>
>>
>> "Meir" <[email protected]> wrote:
>>
>>>Thanks for your quick response.
>>>I cahnged the code to catch throwable (both the open and close connection
>>>are
>>>in the try/catch block) and I don't see any problems.
>>>Do you have any other suggestions? Do you need more data?
>>>
>>>
>>>Tom Barnes <[email protected]> wrote:
>>>
>>>>
>>>>Meir wrote:
>>>>
>>>>
>>>>>Hi All,
>>>>>
>>>>>Environment: WLS 7.0sp2, JMS: weblogic JMS JMSJDBCStore, database
>>>>
>>>>oracle9
>>>>
>>>>>We invoke the following sendEvent code from a worker thread invoked
>>>>
>>>>by a scheduler
>>>>
>>>>>that was started in a servlet init method (this worker thread code
>>>>
>>>>is wrapped
>>>>
>>>>>with a user tx).
>>>>>The topic’s MDB is getting the message OK, however the number of
>connection
>>>>
>>>>in
>>>>
>>>>>the monitor (mydomain> JMS Servers> NomJMSServer> Active JMS Servers)
>>>>
>>>>keep growing.
>>>>
>>>>>As you can see we are releasing the connection in a finally block.
>>>>
>>>>Can anybody
>>>>
>>>>>explain it.?
>>>>
>>>>Perhaps you are throwing a RuntimeException or Error without
>>>>catching it. Put trace statements before the connection
>>>>create and right before and after the "connection.close()" to
>>>>verify.
>>>>
>>>>Note that since you are closing the connection, there is no need
>>>>to close the publisher or session.
>>>>
>>>>
>>>>>Second question: Should we cache the jms session?
>>>>
>>>>For performance reasons, yes. But if your performance
>>>>is fine, you don't need to. Since you are doing
>>>>a "zip" per message, which is expensive in terms of CPU,
>>>>the overhead of creating a session per
>>>>message may be negligable in comparison.
>>>>
>>>>
>>>>>If the answer is yes, can they
>>>>>expire (close),
>>>>
>>>>If the host JMS server is adminstratively shutdown
>>>>or the host JVM for the JMS server crashes...
>>>>
>>>>
>>>>>how do we check if they are still valid?
>>>>
>>>>If it fails when you use it, it ain't valid. ;-)
>>>>
>>>>You can detect failures pro-actively by registering
>>>>a connection onException listerner
>>>>and a session onException listener.
>>>>
>>>>Note that WL 8.1 has built in connection/session
>>>>pooling, and the JMS Performance Guide white-paper's
>>>>appendix has sample code for writing your own pool for
>>>>previous WL versions. There is a linke to
>>>>the white-paper here:
>>>>
>>>>http://dev2dev.bea.com/technologies/jms/index.jsp
>>>>
>>>>
>>>>>Thanks
>>>>>
>>>>>
>>>>> public String sendEvent(SyncOutput event)
>>>>> {
>>>>> String retval = null;
>>>>> try
>>>>> {
>>>>> init();
>>>>> topicPublisher.publish( formatMessage(event) );
>>>>> }
>>>>> catch (Exception e)
>>>>> {
>>>>> logger().debug("cannot send event", e);
>>>>> }finally{
>>>>> release();
>>>>> }
>>>>> return retval;
>>>>> }
>>>>>
>>>>> private Message formatMessage(SyncOutput output)
>>>>> throws JMSException, IOException
>>>>> {
>>>>> BytesMessage message = topicSession.createBytesMessage();
>>>>> GZIPOutputStream gzip = new GZIPOutputStream(new BytesMessageOutputStream(message));
>>>>> output.flush(new OutputStreamWriter(gzip));
>>>>> gzip.close();
>>>>> return message;
>>>>> }
>>>>>
>>>>> private void init()
>>>>> throws Exception
>>>>> {
>>>>> InitialContext context = new InitialContext();
>>>>> TopicConnectionFactory conFactory =
>>>>> (TopicConnectionFactory) context.lookup(JMSConfig.get(JMSConfig.FACTORY));
>>>>> topicConnection = conFactory.createTopicConnection();
>>>>> topicSession = topicConnection.createTopicSession(false,
>Session.AUTO_ACKNOWLEDGE);
>>>>>
>>>>> Topic topic = (Topic) context.lookup( this.jndiName );
>>>>> topicPublisher = topicSession.createPublisher(topic);
>>>>> topicPublisher.setDeliveryMode( DeliveryMode.PERSISTENT );
>>>>> }
>>>>>
>>>>> private void release()
>>>>> {
>>>>> try{
>>>>> if (topicPublisher != null){
>>>>> topicPublisher.close();
>>>>> topicPublisher = null;
>>>>> }
>>>>>
>>>>> if (topicSession != null){
>>>>> topicSession.close();
>>>>> topicSession = null;
>>>>> }
>>>>>
>>>>> if (topicConnection != null) {
>>>>> topicConnection.close();
>>>>> topicConnection = null;
>>>>> }
>>>>>
>>>>> System.gc();
>>>>> }catch(Exception ignore){
>>>>> ignore.printStackTrace();
>>>>> }
>>>>> }
>>>>>
>>>>
>>
>
-
How to enable secure transfer of JMS Messages possibly using SSL ?
a. JMS messages from client to Queue/Topic
b. Queue/Topic to MDB
One options seems to be using t3s instead of t3 ? Is this correct ?
If we use EJB3 resource injections for initializing JMS connection factories and Destinations, then how can we configure the app to use t3s protocol instead of t3.
Thanks
-SivaIn SM59 open up a RFC destination and go to Logon & Security. There you can enable Trusted relashionship and activate status of secure protocol.
And yes you have to do it manually for the desired RFC's
Maybe you are looking for
-
Coping Portal objects from Test to production on different Domains
I want to know if anyone besides my company uses separate domain environments to do development, QA, and production. How did you get around the object owner issues that come from this level of security. Did you have to Export OID objects from one env
-
Web as JAVA in Technical System
Hi, I deleted my web as java in technical system for mistake and when I created same information doesn´t show. How I created the web as java? Thanks, Diego
-
hi, What is collect patterns? can u plz tell me for which business process you implement this scenario? Thanks guna
-
Is there a bug that would keep Adobe Reader from being functional in Safari 7.0.1?
Since upgrading to OS X 10.9.1, I sometimes find that Safari cannot open a page but rather opening a black page instead. I thought I was solving the problem by removing Adobe Reader and whatever ancillary files could be found (using either App Cleane
-
I am running Lightroom 5.7 and want to import NEF files from a Nikon D750 directly into LR. How do I do that?