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.
          >
          

Similar Messages

  • 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
              

  • 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

  • JMS Messages keep on growing for a Topic with non-durable consumers

    I have a JMS Server whose "Messages Current" keeps on growing after every message send to the topic. All the consumers are non-durable. The session is a non-transacted session with Auto Accknowledge parameter. My client does recieve the message, but it does not go down from the "Messages Current" in the WLS console. Also once the server is restarted, the messages go down to 0.
    I am using 9.2 SP2 on a Solaris environment.
    Any insight would be helpful

    It's possible that one or more the subscribers is stalled for some reason and so is not actually receiving and processing messages. This would cause messages to accumulate. You can examine statistics for individual consumers on the console to see if this is an issue.
    Also, there could be a durable subscription on the topic left over from some previous application you used with the topic. There are statistics for these as well.
    Yet another possibility is that the clients are receiving the messages but are failing to acknowledge/commit them. You wrote that the sessions are "auto-acknowledge" but they could accidentally be "transacted". Check to make sure that the first parameter passed to "createSession" is true (it should be false), and that the second parameter is set to auto-acknowledge.
    Finally, if you happen to be using a distributed topic, keep in mind that if one of the topic members is unavailable/crashed/down messages will accumulate on the other distributed topic members until the unavailable member is restarted (at which point they will be forwarded to the restarted member).
    Tom

  • 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.

  • Anyone using durable topics with high data volumes?

    We're evaluating JMS implementations, and our requirements call for durable subscribers, where subscribers can go down for several hours, while the MQ server accumulates a large number of messages.
    Is anyone using Sun MQ in a similar scenario? How is it holding up?
    Sun folks, do you know of production installations that use durable topics with high data volumes?
    thanks,
    -am

    We are using a cluster of Sun�s JMS MQ 3.6 with durable message queues and persistent topics. In a 4 hour window each night we run over 20,000 messages through a queue. The cluster sits on two Windows servers, the producer client is on a AIX box and the consumer is running on a iSeries. Within the 20,000 messages are over 400,000 transactions. Each message can have many transactions. Yes, the iSeries client has gone down twice and the producer continued with the message queue pilling up, as it should. We just use the topic to send and receive command and status inquiries to the clients. So every thing works fine. We have only had a couple issues with a client locking and that maybe fixed with sp3, we are in the process of installing that. The only other issue we have had is that once in a while the producer tries to send an object message with to many transactions and it throws and JMS exceptions. So we put a cap on the size of the messages, if its over a set number of transactions it send each transaction as separately, otherwise it sends all the transactions in one object type (linked list of transactions) message. Compare the cost of this JMS system with Tibco or Sonic and you�re looking at big savings.

  • 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

  • Durable subscriber question

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

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

  • How to retreive all unconsumed messages from a topic with a MDB?

    Hello!
    I have a webapp that stores TextMessages in a Topic in WebLogic.
    I have an ejbapp (Message driven bean) that reads messages from the topic.
    If both are up and running the ejbapp reads all messages sent from the webapp to the topic.
    But if I stop the ejbapp for a while and sends a couple of messages to the topic and then deploy the ejbapp again, then the ejbapp does not read the unconsumed messages. If I send a new message to the topic the ejbapp reads that new messages but it does not get the previous messages that are on the topic.
    Is this the way it should work? Or could I get the message driven bean to consume all the messages that it has not consumed from the topic when it starts?
    My weblogic-ejb-jar.xml looks like:
    <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 8.1.0 EJB//EN' 'http://www.bea.com/servers/wls810/dtd/weblogic-ejb-jar.dtd'>
    <weblogic-ejb-jar>
    <weblogic-enterprise-bean>
    <ejb-name>OrderManagerMDB</ejb-name>
    <message-driven-descriptor>
    <pool>
    <max-beans-in-free-pool>200</max-beans-in-free-pool>
    <initial-beans-in-free-pool>20</initial-beans-in-free-pool>
    </pool>
    <destination-jndi-name>jms/OrdersTopic</destination-jndi-name>
    <connection-factory-jndi-name>jms/OrdersConnectionFactory</connection-factory-jndi-name>
    </message-driven-descriptor>
    <enable-call-by-reference>True</enable-call-by-reference>
    </weblogic-enterprise-bean>
    </weblogic-ejb-jar>And my ejb-jar.xml looks like:
    <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
    <ejb-jar>
    <enterprise-beans>
    <message-driven>
    <ejb-name>OrderManagerMDB</ejb-name>
    <ejb-class>brownbagwarehouse.OrderManagerMDB</ejb-class>
    <transaction-type>Container</transaction-type>
    <acknowledge-mode>Auto-acknowledge</acknowledge-mode>
    <message-driven-destination>
    <destination-type>javax.jms.Topic</destination-type>
    </message-driven-destination>
    </message-driven>
    </enterprise-beans>
    </ejb-jar>My MDB onMessage looks like:
    public void onMessage(Message message)
    try
    TextMessage textMessage = (TextMessage)message;
    System.out.println(textMessage.getText());
    catch(Exception e)
    e.printStackTrace();
    }Best regards
    Fredrik

    I am not much familiar with Weblogic, but i would suggest, you do a search for how to setup "Durable Subscriptions" in Weblogic. This will ensure the the messages that were sent when the consumer was not available, will be delivered once the consumer is available

  • 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 subscribers questions

    Hello,
              I am building an application that has two WebLogic servers
              communicating certain information between them using JMS. I am using
              WebLogics implementation of JMS including destinations and messaging
              bridges.
              I am experiencing some problems.
              Server 1 takes files and puts them in a Stream Message and publishes
              them to a topic as shown here:
              Context context = new InitialContext();
              TopicConnectionFactory topicFactory = (TopicConnectionFactory)
              context.lookup(sourceDescriptor.getConnectionFactory());
              connection = topicFactory.createTopicConnection();
              session = connection.createTopicSession(false,
              Session.CLIENT_ACKNOWLEDGE);
              Topic topic = (Topic)
              context.lookup(sourceDescriptor.getTopicJNDIName());
              TopicPublisher publisher = session.createPublisher(topic);
              publisher.setDeliveryMode(DeliveryMode.PERSISTENT);
              StreamMessage message = session.createStreamMessage();
              for (int i = 0; i < files.length; i++)
              Loop through reading a set of files into the StreamMessage publishing
              each.
              publisher.publish(message);
              Topic config.xml
              <JMSTopic JNDIName="topic/topicName"
              Name="Topic Name" StoreEnabled="default"/>
              Destination config.xml
              <JMSBridgeDestination
              AdapterJNDIName="eis.jms.WLSConnectionFactoryJNDINoTX"
              ConnectionFactoryJNDIName="ConnectionFactory"
              ConnectionURL="t3://localhost:7001"
              DestinationJNDIName="queue/queueName" Name="Queue Destination
              Name"/>
              <JMSBridgeDestination
              AdapterJNDIName="eis.jms.WLSConnectionFactoryJNDINoTX"
              ConnectionFactoryJNDIName="ConnectionFactory"
              ConnectionURL="t3://machinename:8001"
              DestinationJNDIName="topic/topicName"
              DestinationType="Topic" Name="Topic Source Name"/>
              Messaging Bridge config.xml
              <MessagingBridge
              Name="The Bridge"
              QOSDegradationAllowed="true" QualityOfService="Duplicate-okay"
              SourceDestination="Topic Source Name"
              TargetDestination="Queue Destination Name" Targets="server1"/>
              Connection Factory
              <JMSConnectionFactory JNDIName="ConnectionFactory"
              Name="Server1 Connection Factory" Targets="server1"/>
              All settings in WebLogic are default for the configuration of this as
              far as I know.
              The bridge is using Duplicate Ok QOS at this point.
              This works like a charm as long as server which has the destination
              queue is up and running and has received messages in the past.
              The first problem is the first set of messesages are sent to the Queue
              on Server 2 but the MDB does not pick them up. I have left it running
              for an hour and these messages sit in the pending state for the
              monitoring of the Queue. In order to get this first set of messages
              to be processed I have to restart Server 2 at which point the initial
              messages are processed. Any subsequent messages are processed by the
              MDB immediately upon delivery. What is the cause of this and is there
              any way around having to restart after the first messages are received
              creating the file in the message store? Does this have anything to do
              with the fact that there is no file in the message store until the
              first messages are received and thus the MDB is not looking since
              there was nothing there on start up? This seems very odd....
              The second problem has to do with durability. I start Server 1 and it
              waits for a finish file and when it sees it it takes the files and
              puts them on the topic as described. As long as Server 2 is up and
              running at that time everything is fine. If However Server 2 is not
              running at that moment and is started at a later time then the
              messages seem to be lost. What could cause this? Is there any way I
              can visually see that the message is being held on Server 1? The
              bridge from this topic on Server 1 to the queue on Server 2 is
              configured on Sever 1 and you can see that it is working when Server 2
              is not running due to the connection refused messages the bridge
              throws. Is the bridge accepting the messages from the topic enough
              for the topic to decide it is done with them and delete them? Could
              the acknowledgement from the queue on another bridge for the same
              topic be confusing the topic and deleteing the message before all
              subscribers get it? This is a big issue since it seems that durabilty
              is only guarenteed when both servers are running and a message is
              created.
              Any help on this would be appreciated...If you wouldn't mind cutting
              and pasting any responses to my email as well it would be appreciated
              as I use google for groups and it has a long turn around.
              TIA...
              

    Hi Kartheek,
    Once we create a TOPIC in NWA.In durable subscribers tab subscription ID and Subscription name will be automatically created once you publish the message in to TOPIC.
    check in NWA-->jms server configuration-->durable subscribers.
    thanks
    Purna

  • 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.

  • 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

  • Registering for a Topic with own stream & queue in Pub/Sub

    Hi *.
    I'm working with MQSeries 5.3 on WinXP.
    I don't know, how to register a subscriber to a topic with the JMS-classes. I found a sample from IBM, but it uses the native (MQ)classes and it does not work, when I try to register an own queue or stream. Everything works fine with system-queues/streams, but I shouldn't work with the defaults in my application.
    Does anybody know, where I can find a sample to register a subscriber to a topic, which is based on JMS ?
    Thank you very much in advance.
    Jo

    Yes, the script is provided by IBM when you install the java for mqseries for websphere MQ. It is under MQ_JAVA_INSTALL_PATH/bin directory called MQJMS_PSQ.mqsc.
    I am copying the contents of the file if you want:
    * IBM Websphere MQ Support for Java Message Service */ */
    * Sample MQSC source defining JMS Publish/Subscribe queues. */
    * Installation Verification Test - Setup script */
    * Licensed Materials - Property of IBM */
    * 5648-C60 5724-B4 5655-F10 */
    * (c) Copyright IBM Corp. 1999. All Rights Reserved. */
    * US Government Users Restricted Rights - Use, duplication or */
    * disclosure restricted by GSA ADP Schedule Contract with IBM Corp.*/
    * JMS Publish/Subscribe Administration Queue */
    ** Create a local queue
    DEFINE QLOCAL('SYSTEM.JMS.ADMIN.QUEUE') REPLACE +
    DESCR('Websphere MQ - JMS Classes - admin queue') +
    * Persistent messages OK
    DEFPSIST(YES) +
    * Non-Shareable
    NOSHARE
    * JMS Publish/Subscribe Subscriber Status Queue */
    ** Create a local queue
    DEFINE QLOCAL('SYSTEM.JMS.PS.STATUS.QUEUE') REPLACE +
    DESCR('Websphere MQ - JMS Classes - PS status queue') +
    * Persistent messages OK
    DEFPSIST(YES) +
    * Shareable
    SHARE DEFSOPT(SHARED)
    * JMS Publish/Subscribe Report Queue */
    ** Create a local queue
    DEFINE QLOCAL('SYSTEM.JMS.REPORT.QUEUE') REPLACE +
    DESCR('Websphere MQ - JMS Classes - Report queue') +
    * Persistent messages OK
    DEFPSIST(YES) +
    * Shareable
    SHARE DEFSOPT(SHARED)
    * JMS Publish/Subscribe Subscribers Model Queue */
    * Create model queue used by subscribers to create a permanent */
    * queue for subsciptions */
    * General reply queue */
    DEFINE QMODEL('SYSTEM.JMS.MODEL.QUEUE') REPLACE +
    DESCR('Websphere MQ - JMS Classes - Model queue') +
    * Queue Definition Type
    DEFTYPE(PERMDYN) +
    * Shareable
    SHARE DEFSOPT(SHARED)
    * JMS Publish/Subscribe Default Non-Durable Shared Queue */
    * Create local queue used as the default shared queue by */
    * non-durable subscribers */
    ** Create a local queue
    DEFINE QLOCAL('SYSTEM.JMS.ND.SUBSCRIBER.QUEUE') REPLACE +
    DESCR('Websphere MQ - JMS Classes - PS ND shared queue') +
    * Persistent messages OK
    DEFPSIST(YES) +
    * Shareable
    SHARE DEFSOPT(SHARED) +
    * Maximum queue depth
    MAXDEPTH(100000)
    * JMS Publish/Subscribe Default Non-Durable Shared Queue for */
    * ConnectionConsumer functionality */
    * Create local queue used as the default shared queue by */
    * non-durable connection consumers */
    ** Create a local queue
    DEFINE QLOCAL('SYSTEM.JMS.ND.CC.SUBSCRIBER.QUEUE') REPLACE +
    DESCR('Websphere MQ - JMS Classes - PS ND CC shared q') +
    * Persistent messages OK
    DEFPSIST(YES) +
    * Shareable
    SHARE DEFSOPT(SHARED) +
    * Maximum queue depth
    MAXDEPTH(100000)
    * JMS Publish/Subscribe Default Durable Shared Queue */
    * Create local queue used as the default shared queue by durable */
    * subscribers */
    ** Create a local queue
    DEFINE QLOCAL('SYSTEM.JMS.D.SUBSCRIBER.QUEUE') REPLACE +
    DESCR('Websphere MQ - JMS Classes - PS D shared queue') +
    * Persistent messages OK
    DEFPSIST(YES) +
    * Shareable
    SHARE DEFSOPT(SHARED) +
    * Maximum queue depth
    MAXDEPTH(100000)
    * JMS Publish/Subscribe Default Durable Shared Queue for */
    * ConnectionConsumer functionality */
    * Create local queue used as the default shared queue by durable */
    * connection consumers */
    ** Create a local queue
    DEFINE QLOCAL('SYSTEM.JMS.D.CC.SUBSCRIBER.QUEUE') REPLACE +
    DESCR('Websphere MQ - JMS Classes - PS D CC shared q') +
    * Persistent messages OK
    DEFPSIST(YES) +
    * Shareable
    SHARE DEFSOPT(SHARED) +
    * Maximum queue depth
    MAXDEPTH(100000)

Maybe you are looking for