Durable subscriptions

I am using code similar to this:
aq.connection = topicConnectionFactory.createTopicConnection( "aquser", "aquser");
aq.session = aq.connection.createTopicSession( true,Session.CLIENT_ACKNOWLEDGE);
It works no problem when sending and receiving messages from a queue (Point to Point). It works when publishing a message to a topic, but when trying to creat a durable subscription, it throws a ora-24047 error (invalid agent name, should be type NAME and not string). I am using strings similar to the above example.
This doesn't make sense as PTP works and publishing messages work using strings as the agent name, and not the NAME object.
What could be causing a Durable Subscription to be rejected when using the agent name in string format?

That specific error goes away when there are no special characters such as underscores in the name, and everything is uppercase.

Similar Messages

InvalidClientIdException while creating Durable subscription in weblogic

Hi,
We have scenario to create a durable subscription for an MDB. Here application in weblogic is a subscriber to a Topic present on the Progress Sonic. For integrating to independent platforms we are using Foreign Server mechanism under JMS Modules.
For creating durable subscription, we have changed the MDB code . Below is the MDB code,
package com.test;
import java.util.Enumeration;
import javax.annotation.Resource;
import javax.annotation.Resources;
import javax.ejb.MessageDriven;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.ejb.TransactionManagement;
import javax.ejb.TransactionManagementType;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.TextMessage;
import javax.ejb.ActivationConfigProperty;
* Message-Driven Bean implementation class for: TestMDB
@MessageDriven(description = "mdb for Airline Schedule Change MDB",
name = "AirlineScheduleMDB",
activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType",
propertyValue = "javax.jms.Topic"),
@ActivationConfigProperty(propertyName = "subscriptionDurability",
propertyValue = "Durable")
@TransactionManagement(value = TransactionManagementType.CONTAINER)
@Resources( { @Resource(name = "ConnectionFactoryRef",
mappedName = "TopicConnectionFactory",
type = javax.jms.ConnectionFactory.class) })
public class TestMDB implements MessageListener {
* @see MessageListener#onMessage(Message)
@TransactionAttribute(value = TransactionAttributeType.NOT_SUPPORTED)
public void onMessage(Message message) {
System.out.println("Inside message : ");
try {
Enumeration<Object> messageProperty = message.getPropertyNames();
System.out.println("The request : "+message);
if(message != null){
System.out.println("TestMDB : onMessage : Start");
}else{
System.out.println("Received Input message is empty");
} catch (Exception e) {
System.out.println("Exception Occurred in TestMDB : ");
e.printStackTrace();
System.out.println("TestMDB : onMessage : End.Time taken is :");
Also the following change was included in the weblogic-ejb-jar.xml.
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-ejb-jar
xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">
<weblogic-enterprise-bean>
<ejb-name>TestMDB</ejb-name>
<message-driven-descriptor>
<pool>
<initial-beans-in-free-pool>1</initial-beans-in-free-pool>
</pool>
<destination-jndi-name>DurableJNDI</destination-jndi-name>
<connection-factory-jndi-name>TopicConnectionFactory</connection-factory-jndi-name>
<jms-polling-interval-seconds>30</jms-polling-interval-seconds>
<generate-unique-jms-client-id>true</generate-unique-jms-client-id>
<jms-client-id>DurableTest</jms-client-id>
</message-driven-descriptor>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
Exception we got :
<03-Apr-2012 18:11:02 o'clock UTC> <Warning> <EJB> <BEA-010061> <The Message-Driven EJB: TestMDB is unable to connect to the JMS destination: DurableJNDI. The Error was:
javax.jms.InvalidClientIDException: Invalid client id: DurableTest_drdevwls_TestDomain-wls1_CLEARCF.jarTestMDB
Weblogic is automatically creating a unique id based on the combination of Adminserver/Managedserver/Projectname etc.
However the id created by weblogic seems to have a dot(.) which as per Sonic spec is an invalid character.
eg:- DurableTest_test_domain_AdminServer_CLEARCF.jarTestMDB
Hence we changed the parameter to false and provided our own value.
<generate-unique-jms-client-id>false</generate-unique-jms-client-id>
<jms-client-id>DurableTest</jms-client-id>
At this point of time we were able to see that MDB have created a Durable subscription successfully and it worked as expected.
However when we tried to scale this change to multiple managed servers, there were errors thrown from sonic side.
javax.jms.JMSException: [129] progress.message.client.EUserAlreadyConnected: Administrator/$DURABLE$DurableTest$DurableTest
So we cannot have same clientid for multiple clients(managed server). We arent sure how to proceed with this.
We need to find a way to remove the dot from the dynamic id weblogic creates.
Any help on this is highly appreciated.

Hi Tom,
We have found the solution to this problem and thanks for your suggestion that has partially helped us in solving the problem.
As you have suggested we have defined client-id on the connection factory however we will be having only connection factory instead of multiple with different client-ID's.
Along with the client-id configured at the connection factory level we are now setting the attributes generate-unique-client-id as true at the weblogic end.
By doing this way, I assume that weblogic while making the durable subscription connection is passing the uniquely generated client ID (which has dots '.' included in it ) as subscription name and client-id will be same, that is defined on the connection factory.
A question may arise that - 'why is sonic accepting subscription name with dots but not the client-id ?' - When observed from the sonic end the dots in the subscription name are replaced by '@@@' .
Sonic need to answer the question of why the dots are being replaced for subscription name but not for client-id.
Regards,
Bharat K

Do I really need two connection pools when using two durable subscriptions?

I have a Spring daemon which takes messages from two different topics and stores them in a database.
What irritates me is that I can't get it to work with a single connection pool. I get a message that I can't create durable subscriptions without a unique client id on the connection. It's not enough that the client id be set on the listener container, I have to set it on the underlying ConnectionFactory. I though this was some kind of glitch with openMQ but activeMQ gives me exactly the same behaviour.
This is the important part of the config
    <bean id="realCon" class="org.apache.activemq.ActiveMQConnectionFactory" p:brokerURL="discovery:(multicast://default?group=live)"
    p:clientID="DB_RECORD_CLIENT"/>
    <bean id="realCon2" class="org.apache.activemq.ActiveMQConnectionFactory" p:brokerURL="discovery:(multicast://default?group=live)"
    p:clientID="DB_LOG_CLIENT"/>
    <bean id="jmsConnectionFactory" class="org.springframework.jms.connection.CachingConnectionFactory"
    p:targetConnectionFactory-ref="realCon"/>
    <bean id="jmsConnectionFactory2" class="org.springframework.jms.connection.CachingConnectionFactory"
    p:targetConnectionFactory-ref="realCon2"/>
    <bean id="ocsMessageListener" class="com.cc.mer.ordercatcher.MessageReceived"/>
    <bean id="logMessageListener" class="com.cc.mer.ordercatcher.LogMessageReceived"/>
    <jms:listener-container
        connection-factory="jmsConnectionFactory"
        destination-type="durableTopic"
        transaction-manager="transactionManager"
        acknowledge="transacted"
        >
        <jms:listener ref="ocsMessageListener" destination="OCS_RELAYED"
                      subscription="ocs.db.recording" />
    </jms:listener-container>
    <jms:listener-container
        connection-factory="jmsConnectionFactory2"
        destination-type="durableTopic"
        transaction-manager="transactionManager"
        acknowledge="transacted"
        >
        <jms:listener ref="logMessageListener" destination="OCS_LOG"
                      subscription="ocs.log.recording" />
    </jms:listener-container>

Thank you all for your replies.
Yesterday, I went back to BestBuy and returned the Gigabit Ethernet Switch and exchanged it for a Belkin Share Max N300 router. I chose this one because I want to use the router in WIRED mode and this had a 10/100/1000Mbps Gigabit Ethernet capability. Most other routers that I looked at only had 10/100Mbps. I also liked that it had two USB ports.
I had to call Belkin tech support because the installer from the included CD would not install the software. Nor would the installer that I downloaded from their web site. I ended up actually having to be taken to the IP address' web site and from there I was able to configure everything.
Although it took me a few hours to get all my other wireless devices onto my wireless network (I have a couple of Airport Express(es) for running "Airplay," and a wifi dongle on my TV), things now seem to be working fine.

Durable Subscription with MDB in Weblogic 7.0

Hi,
          I am using WLS 7.0 as the JMS Provider and as the EJB Container(no
          clustering). My question is do I need MDB with durable subscription. I
          cannot think of a instance when the container will be down but JMS
          provider is still running if I am using WLS as both container and JMS
          provider.
          One instance i can think of is if the MDB is not deployed (upon a new
          release of our application, for some strange reason) but rest of the
          application is deployed then the producers will produce messages for
          the off-line subscriber.
          If I assume that the above is not likely to happen, can you think of
          any compelling reason for me to use MDB with durable subcription .
          Thanks for your input.
          ssahu


1) The MDB should only specify "durable" if it is receiving from a
          topic. Durable does not apply to queues.
          2) If messages are non-persistent, then you likely don't need durable.
          As these messages don't survive the shutdown...
          3) Making it durable helps with race-conditions during shutdown or
          startup where messages are sent but the MDB isn't up. It also helps
          with the condition where shutdown occurs before the MDB finishes
          processing all of its messages. (So Durable ensures that the
          MDB does not miss a message. It may even help in the non-persistent
          case if is possible that the MDB is temporarily undeployed (by you)
          while the server is up.
          [email protected] wrote:
          > Hi,
          > I am using WLS 7.0 as the JMS Provider and as the EJB Container(no
          > clustering). My question is do I need MDB with durable subscription. I
          > cannot think of a instance when the container will be down but JMS
          > provider is still running if I am using WLS as both container and JMS
          > provider.
          > One instance i can think of is if the MDB is not deployed (upon a new
          > release of our application, for some strange reason) but rest of the
          > application is deployed then the producers will produce messages for
          > the off-line subscriber.
          >
          > If I assume that the above is not likely to happen, can you think of
          > any compelling reason for me to use MDB with durable subcription .
          >
          > Thanks for your input.
          >
          > ssahu

AQ JMS: non-durable subscriptions not cleaned up

Whenever I create a non-durable subscription I see a TSUB_... subscription in the AQ$ tables. This subscription does not disappear when the client terminates abnormally.
This can be very annoying because these queues fill up quickly and deleting a big subscription locks the queue for a substantial amount of time.
Is there something I missed - should the QMN take care of these orphaned subscriptions ?

We are having exactly the same problem...

My JMS 2 wish list - Part 4, durable subscriptions

I attended the JavaOne 2010 session on future JMS evolutions. During the session I described some current limitations or issues I'd like to be solved in a portable way. I've been adviced to share the issues to get feedback from the community. I will post each issue in a dedicated thread.
Issue 4 - How durable are durable topic subscriptions?
Non durable subscribers receive topic messages only if they are active at the time when the message is received and processed by the JMS engine. Durable subscribers are more complicated, they receive messages if the durable subscription is active when the message is received and processed by the JMS engine.
How do I know when messages are kept or discarded? Simply put, what is the lifecycle of the subscription?
When using synchronous receptions or message listeners, the durable subscription lifecycle is managed by the developper using Session:createDurableSubscriber and Session:unsubscribe.
When using MDB, the durable subscription lifecycle is unspecified and is application server dependant.
With JBoss 4.2, the subscription lifecyle is the same than the MDB. This means that if the application is redeployed (for example copy the new .ear over the old one in the deploy folder), there is a time frame when the subscription in non existent, so messages are lost.
WebLogic 10 also seems to associate the subscription lifecycle to the MDB. WebLogic 10 offers a flag, "durable-subscription-deletion", to allow or not the durable subscription deletion when the MDB is undeployed or removed. True means that when the application is redeployed the subscription is deleted and messages are lost. When false is used (it is the default value) the subscription remains even when the MDB is undeployed. I hope this does not mean that if we permanently undeploy the application, the subscription will stay and messages will continue to stack.
With WebSphere 6 the situation is different. The subscription is not associated to the MDB but to an activation spec that is an administred object. The MDB is merely a client of the activation spec. This way messages are kept as long as the activation spec is active, regardless of application starts/stops/redeploys/etc. Messages are not lost.
We need a portable way to use durable topics subscriptions.

gimbal2 wrote:
A portable solution would be useful.You could already do it now by leveraging the Timer functionality that has been part of the EJB spec since JEE 1.4. In stead of sending the message directly, let the timer do it after the delay you specify. That would make it portable with current tech.
I can't be sure what other implications that might have though, such as in the area of performance and resource usage - I can imagine you wouldn't want to use a timer when you need to send large volumes of messages.In the original requirement, the message is put in the queue immediately by a call to queuesender.send(message) and there's a delivery in delay to a consumer.
Whereas in this solution, the delay is in the message delivery to the queue itself.
IMHO there's a subtle but important difference here.What would for example happen if posting the message to the queue is in the scope of a distributed JTA transaction? You can definitely include the timer call to be in the scope of the transaction, but now you will have to account for the fact and there may be an error when the message is delivered which has to be handled explicitly. In the original scenario the tx would automatically rollback.
cheers,
ram.

Durable subscriptions and windows clients

Hi,
I think I have found a potential problem.
Scenario
MQ: 3.x or 4.x
Clients: windows OS with Durable Subscriptions
Destinations: Topic
Problem:
Disconnect a windows client with a durable subscription (for example, pulling the network cable)
Try to reconnect, and you will get "Client ID already in use". Under unix, this happens only for a few secs and that's fine. Under Windows, you won't be able to reconnect for almost 10 minutes. That means that a windows client can't easily reconnect if it uses a durable subscription, and has to wait the server killing its socket.
The problem seems that the server socket stays ESTABLISHED (just do a netstat -an | grep -i ESTABLISHED on the server) for a longer time when the client is windows. So that is a windows socket problem (I just tried with a Simpel TCP Server and that's the same), but I think a JMS server should circumvent it
Possible solutions:
- MQ client overriding the connection if a client id is already in use AND the connection comes from the same IP. I think that should be the default!
- a configurable heartbeat between client and server
- Something like "imqcmd deactivate dur" could do the job. I haven't found a way to manually DISACTIVATE the connect, but only to destroy it (imqcmd destroy dur), which obviously isn't a viable option (possible msg loss)
- Java API to do the same thing
ciao,
uL

I think that the problem may be with the TTL on the sockets. Basically as far as I know unless there is a traffic on the connection there is no way to detect that the other end of a socket connection is gone. You may try enabling ping on the connection this may speed things up.
Tom

Topic with Durable Subscription Questions...

          Hello all,
          The scenario: WL 7.0 - sp2, a clustered environment. I have a JMS Topic which
          has one MsgBean that is Durable and one MsgBean that is non-durable consuming
          messages off this Topic. Both MsgBeans are deployed on all machines in the cluster,
          and the server (which contains the topic) is targetted to one machine.
          The issue that I am experiencing is that the DurableMsgBean can not connect to
          the jms topic, but the non-durable one gets its messages all the time.
          Any ideas/suggestions?
          C.


Hi,
          The durable subscriber name is derived from the descriptor's ejb name,
          and only one consumer may attach to a particular durable subscription
          at a time. I've attached some notes that should help you out, please
          excuse the jumbled formatting.
          Let me know if this helps,
          Tom, BEA
          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 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 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.
          csw wrote:
          > Hello all,
          >
          > The scenario: WL 7.0 - sp2, a clustered environment. I have a JMS Topic which
          > has one MsgBean that is Durable and one MsgBean that is non-durable consuming
          > messages off this Topic. Both MsgBeans are deployed on all machines in the cluster,
          > and the server (which contains the topic) is targetted to one machine.
          >
          > The issue that I am experiencing is that the DurableMsgBean can not connect to
          > the jms topic, but the non-durable one gets its messages all the time.
          >
          > Any ideas/suggestions?
          >
          > C.
          >

Using MDBs for durable subscriptions

I need to be able to deploy my MDB as a durable subscriber i.e I have my MDB ubscribing to a Topic. For some reason if the application hosting the MDB(message driven bean) fails, I would like the JMS provider to republish all the messages that were already in the Topic in addition to those messages which might have been published when the MDB application was down.
I am trying to achieve this using Weblogic 7.0. The weblogic documentation says that messages will not be accumulated if the MDB using durable subscriptions is not deployed(which would be the case when the MDB application failed).
Any ideas on how I could design around this shortcoming within WLS?
Thanks
Ramdas

The WLS documentation for MDBs says :
"If your bean will demarcate its own transaction
boundaries, set the acknowledge-mode sub-element to
specify the JMS acknowledgment semantics to use. This
element has two possible values: AUTO_ACKNOWLEDGE (the
default) or DUPS_OK_ACKNOWLEDGE."Okay, I missed the part where you were specifying WLS. In the case quoted above, you will have to explicitly rollback the transaction and make sure that your MDB is set to transaction "Required" (or "RequiresNew").
I am not sure what you meant by "concurrency issues"
when using MDBs.
Please could you clarify.Sure, if your BMP, as called from the MDB, blows up, you rollback the transaction. Which means the EXACT SAME message that caused the error will get redelivered, based upon your server settings: either immediately or within the delay period.
This means that while your first MDB is (potentially) still dealing with whatever problems the message caused in the BMP, a second invocation of the MDB can be starting, albeit in another transaction. The state of your BMP could be undefined in this situation - which could cause an entirely different set of problems.
Even though you program EJBs as "single-threaded," you still have to consider the likelyhood of multiple invocations accessing/changing the same "piece" of data. Yes, that's what transactions are for - but there can be programmatic holes where this kind of situation can arise. You just have to be careful about what you're doing.

Persisted messages without durable subscriptions

Does weblogic JMS support PERSISTED MESSAGES without durable subscriptions. As per jms spec message persistence does make sense even without durable subscriptions in case when the JMS server fails before a message is sent and acknowledged.
          "A JMS provider must deliver a PERSISTENT message once-and-only-once. This means a JMS provider failure must not cause it to be lost and it must not deliver it twice."
          This implies that a persisted message will be persisted before sending and if JMS server fails, it resends the message to available consumers when server is back up and has nothing to do with durable/non-durable subscriptions.
          Please let me know what you guys think and if it is supported in weblogic JMS.
          Thanks,
          -Raj

- Topics require durable subcriptions to persist messages. This is a standard part of the JMS API. Nondurable subscribers have absolutely no need for persistence by definition - as such subscriptions exist solely for the life of the client's connection.
          - And yes, queues support persistence. This is required by the JMS spec, which BEA fully implements.
          - True "exactly-once" behavior usually requires the use of transactions in conjunction with JMS. This ensures that the message being processed and any related application work either atomically all fails or all succeeds.
          The above applies to all JMS vendors.
          Tom, BEA

Wls7 GA bridge deletes durable subscriptions on source destination when stopped

          The bridge (with durability enabled) seems to delete its durable subscriptions
          from the source destination when it is stopped in any of the following 3 ways:
          (1) uncheck the "started" box & apply
          (2) untarget the bridge from the server
          (3) gracefully shutdown the server hosting the bridge
          ..whereas if I kill the server the bridge is on, the durable subcription on the
          source destination remains.
          For me the behaviour in (1) (2) & (3) is unwanted: I want the durable subscription
          to remain, so that when I start the bridge again it can pick up messages stored
          for it. Is there some reason you have implemented it this way? Is there a config.xml
          attribute I can set to inhibit this behaviour? Or is there a patch for it?
          In my case the bridge is running on a standalone admin server, with a local target
          destination; the source destination is on a remote wls7 managed server instance.
          I can send you config.xmls for everything but I don't want to post them here.
          We're using lots of bridges to simplify our JMS topology.
          (I'll raise a case for this too, I just wanted to log it here.)
          Regards,
          Jeremy.


It is not the intended behavior and looks like a new bug introduced in 7.0.
          I have filed an internal change request for this (CR082386).
          Thanks,
          Dongbo
          "Jeremy Watson" <[email protected]> wrote in message
          news:[email protected]...
          >
          > The bridge (with durability enabled) seems to delete its durable
          subscriptions
          > from the source destination when it is stopped in any of the following 3
          ways:
          > (1) uncheck the "started" box & apply
          > (2) untarget the bridge from the server
          > (3) gracefully shutdown the server hosting the bridge
          >
          > ..whereas if I kill the server the bridge is on, the durable subcription
          on the
          > source destination remains.
          >
          > For me the behaviour in (1) (2) & (3) is unwanted: I want the durable
          subscription
          > to remain, so that when I start the bridge again it can pick up messages
          stored
          > for it. Is there some reason you have implemented it this way? Is there
          a config.xml
          > attribute I can set to inhibit this behaviour? Or is there a patch for
          it?
          >
          > In my case the bridge is running on a standalone admin server, with a
          local target
          > destination; the source destination is on a remote wls7 managed server
          instance.
          > I can send you config.xmls for everything but I don't want to post them
          here.
          > We're using lots of bridges to simplify our JMS topology.
          >
          > (I'll raise a case for this too, I just wanted to log it here.)
          >
          > Regards,
          > Jeremy.

Durable subscriptions with UMS?

Is it possible to create durable subscirptions for a topic using UMS?
Or if not, can I use UMS to read from a durable subscription if I create and manage it with another JMS client application?
Thanks for any help

Doing some more research, I found messaging patterns that do what I'm looking for without durable subscriptions.
Apache's ActiveMQ uses something called [Virtual Topics|http://activemq.apache.org/virtual-destinations.html] that allows forwardig messages to multiple queues so that every consumer can read messages from its "own" durable queue without managing unique client IDs.
OpenAMQ with RestMS works similar. Messages are send to a write-only "feed" and forwarded to one ore more read-only "pipes". Again, each consumer can read from its own queue/pipe.
Is there something similar in OpenMQ?
M.S.

Regarding destroying durable subscription using JMX

Hi,
I have web based application in which i m using JMS. For JMS, i am using ActiveMQ as a Message Broker.Here, i want to delete Durable topics using JMX remote connection to my broker,where activeMQ should not be stopped. I can delete durable topics but how to remove subscription of that topic that i dont know and because of subscription
when i restart my standalone component it gives an error such as
'mail_topic is already connected because of that subscription".
Here, whenever i try to destroyDurableSubscriber it gives error such as
Durable consumer is in use.
How to overcome to this problem,please tell me,
Thanks in advance.

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 ?

How to configure MDB as Durable Subscriber

          I can't seem to find any documentation on how to set up an MDB as a Durable Subscriber.
          I tried using the Edit EJB Descriptor link in the console. I then drilled down
          to Message Driven Destination. For Subscription Durability, I selected Durable.
          I clicked Apply. I also went back to the jar and pressed the Persist button to
          "Persist changes made to the Descriptor(s)".
          I check the Topic to see if there were any Durable Subscribers listed. No. I bounced
          the server. Still no.
          What am I missing? The only info I can find in the documentation about setting
          up Durable Subscriptions is via the JMS API (http://e-docs.bea.com/wls/docs61/jms/implement.html#1097632)
          Using WL v6 SP5, not clustered.
          Any help would be appreciated.
          Jim


Hi James,
          I'm unfamiliar with the console ejb xml editor. I suggest
          posting to the ejb newsgbroup, which is more familiar
          with these things. Meanwhile, the attached notes
          and the following example may help if your willing
          to hand-edit the xml.
          Tom, BEA
          <ejb-jar>
          <enterprise-beans>
          <message-driven>
          <ejb-name>exampleMessageDrivenA</ejb-name>
          <ejb-class>MessageBean</ejb-class>
          <transaction-type>Container</transaction-type>
          <message-driven-destination>
          <destination-type>javax.jms.Queue</destination-type>
          
          </message-driven-destination>
          </message-driven>
          </enterprise-beans>
          <assembly-descriptor>
          <container-transaction>
          <method>
          <ejb-name>exampleMessageDrivenA</ejb-name>
          <method-name>onMessage()</method-name>
          </method>
          <trans-attribute>Required</trans-attribute>
          </container-transaction>
          </assembly-descriptor>
          </ejb-jar>
          
          <weblogic-ejb-jar>
          <weblogic-enterprise-bean>
          <ejb-name>exampleMessageDrivenA</ejb-name>
          <message-driven-descriptor>
          <pool>
          <max-beans-in-free-pool>5</max-beans-in-free-pool>
          <initial-beans-in-free-pool>5</initial-beans-in-free-pool>
          </pool>
          
          <destination-jndi-name>MDBQ</destination-jndi-name>
          
          </message-driven-descriptor>
          <jndi-name>someid</jndi-name>
          </weblogic-enterprise-bean>
          </weblogic-ejb-jar>
          James Goodwin wrote:
          > I can't seem to find any documentation on how to set up an MDB as a Durable Subscriber.
          > I tried using the Edit EJB Descriptor link in the console. I then drilled down
          > to Message Driven Destination. For Subscription Durability, I selected Durable.
          > I clicked Apply. I also went back to the jar and pressed the Persist button to
          > "Persist changes made to the Descriptor(s)".
          >
          > I check the Topic to see if there were any Durable Subscribers listed. No. I bounced
          > the server. Still no.
          >
          > What am I missing? The only info I can find in the documentation about setting
          > up Durable Subscriptions is via the JMS API (http://e-docs.bea.com/wls/docs61/jms/implement.html#1097632)
          >
          > Using WL v6 SP5, not clustered.
          >
          > Any help would be appreciated.
          >
          > Jim
          A durable topic subscriber MDB uses its name to generate its client-id.
          Since JMS enforces uniqueness on this client-id, this means that if a durable
          subscriber MDB is deployed to multiple servers only one server will be able
          to connect. Some applications want a different behavior where
          each MDB pool on each server gets its own durable subscription.
          The MDB durable subscription id, which must be unique on its topic, comes from:
          1) <jms-client-id>MyClientID</jms-client-id>
          (the weblogic dtd)
          2) if (1) is not set then the client-id
          comes from the ejb name.
          The durable subscription is uniquely identified within a cluster by a
          combination of "connection-id" and "subscription-id". Only one active
          connection may use a particular "connection-id" within a WebLogic cluster.
          The connection id comes from:
          1) The "ClientId" attribute configured on the WebLogic connection factory.
          This defaults to null. Note that if the ClientId is set on a connection
          factory, only one connection created by the factory
          may be active at a time.
          2) If (1) is not set, then, as with the subscriber-id,
          the connection-id is derived from jms-client-id descriptor attribute:
          <jms-client-id>MyClientID</jms-client-id>
          (the weblogic dtd)
          3) If (1) and (2) are not set, then, as with the subscriber-id,
          the connection-id is derived from the ejb name.
          Work-around:
          A) Create a custom connection-factory for each server:
          1) configure "JNDIName" to the same value across all servers
          ("myMDBCF" in this example)
          2) configure "ClientId" to a unique value per server
          3) enable "UserTransactionsEnabled"
          4) enable "XAConnectionFactoryEnabled"
          5) set "AcknowledgePolicy" to "ACKNOWLEDGE_PREVIOUS"
          6) target the CF at a single WebLogic server
          (Number 5 is required for non-transactional topic MDBs)
          B) In the MDB's weblogic-ejb-jar.xml descriptor, set the MDB's connection
          factory to the JNDI name of the custom connection factories configured in
          (A). Optionally, also specify the subscriber-id via the jms-client-id
          attribute.
          <weblogic-ejb-jar>
          <weblogic-enterprise-bean>
          <ejb-name>exampleBean</ejb-name>
          <message-driven-descriptor>
          <connection-factory-jndi-name>myMDBCF</connection-factory-jndi-name>
          <jms-client-id>myClientID</jms-client-id>
          </message-driven-descriptor>
          </weblogic-enterprise-bean>
          </weblogic-ejb-jar>
          C) Target the application at the same servers that have the custom connection
          factories targeted at them.
          Notes/Limitations:
          1) If the MDB is moved from one server to another, the MDB's corresponding
          connection-factory must be moved with it.
          2) This work-around will not work if the destination is not in the same
          cluster as the MDB. (The MDB can not use the local connection factory, which
          contains the connection-id, as connection factories do not work unless they
          are in the same cluster as the destination.)
          3) This work-around will not work for non-WebLogic JMS topics.

Imqadmin: No. of messages not displayed correctly in durable subs screen

This question applies to the standalone platform edition of Message Queue v3.5 SP2 running on solaris.
I have a number of durable subscribers connecting to a topic. Each & all subscriber have a selector set to filter the data.
From imqadmin I can select the topic and bring up the broker destination properties. If I happen to have messages that have not been consumed (I halt my consumer code to test this), the count on the "basic" screen shows the current and correct number of messages waiting.
If I drill down and go to the Durable Subscriptions screen, the number of messages for the durable subscriber with the relevant selector is always 0... and doesn't seem to reflect that there are messages that haven't been consumed. (Even though my code does see the data come in when I reconnect the consumer).
Is this a bug in the imqadmin display or is there a reason why it can't display the message count correctly at the durable sub screen for consumers with a selector set?

I don't think I'm seeing the same bug... in my app the producer and consumer are both active.
Relevant information for this test:
1) My producer and consumer are both active at the same time.
2) My consumer is using a transacted session and it is also consuming messages synchronously
3) I produce 250 messages and send them to my destination (a topic)
4) For this test I force the consumer to fail on its handling of the data. Say it was trying to handle 50 messages - it rollsback the session and tries again. Therefore leaving 250 messages still in the topic.
The result is that when I display the destination properties screen using imqadmin:
1) The current number of messages count is displayed correctly as 250.
2) However, the count for the durable subscriber with the correct selector is still showing 0.
Once I allow the consumer to resume its work, all 250 messages are handled correctly by that consumer only and the count (in 1) is shown as 0.
So the producer, consumer process works fine but the imqadmin gui seems a little confused.

Durable subscriptions

Similar Messages

Maybe you are looking for