This discussion is archived
4 Replies Latest reply: Oct 17, 2012 1:42 AM by 921672 RSS

Durable Subscription Advice for Replicated Distributed Topic

921672 Newbie
Currently Being Moderated
Hi All

In our production topology, we have 10 OSB managed servers. To connect to these 10 OSB managed servers we have around 400 store applications. One of the interfaces, uses a replicated distributed topic to send a message to all these 400 stores (The store application is basically a synchronous JMS dequeue stand alone java code). Since there is no listener, we have created durable subscription on the replicated distributed topic. I just wanted to know how can we split these stores across the cluster (each OSB server has a JMS Server). Should we keep the first 40 stores on JMSServer1 on OSb Server1, next 40 on JMSServer2 on OSB Server2 and so on.

1) I know this is not highly available (coz of the store application limitation). I just wanted to know, say if one of the OSB servers say OSB server 5 goes down. At that moment, one of our internal OSB proxy publishes the message on this replicated distributed queue. A replicated distributed topic sends a copy of each message to all the physical members. At this movement OSB server 5 is down it will not receive the copy (This puts store 161 to 200 in danger). Once the osb server 5 is back up, will it get the copy of the message or not. How do i ensure that we dont miss out on the messages (i dont mind if the message are delayed, but should not be lost).

Please let me know. What else can be done with this type of application (considering there are no MDBs here)? Is there any scope for further improvement. Thanks
  • 1. Re: Durable Subscription Advice for Replicated Distributed Topic
    Tom B Expert
    Currently Being Moderated
    When a server that hosts a Replicated Topic goes down, the remaining servers in the Replicated Topic will store all new messages until the non-running server restarts. At that point, they will forward the messages to the now restarted server, which, in turn, will place the messages on the waiting subscriptions. This means that as long as the messages are sent with a persistent QOS, no messages are lost (if they are non-persistent, they are destroyed if a server that currently them in a durable subscription goes down).

    If performance and high availability is a concern, I recommend looking into using "partitioned distributed topics" instead of a "replicated topic", plus using MDBs. See the 12.1.2 MDB programmer's guide for details.

    HTH,

    Tom
  • 2. Re: Durable Subscription Advice for Replicated Distributed Topic
    921672 Newbie
    Currently Being Moderated
    Thanks Tom! Highly appreciated.

    before i close this question, i have a few doubts

    1) Do you think it makes sense to split the standalone java durable subscribers over the cluster. I mean 400 such clients over a 10 node OSB clsuter. Client 1 to 40 create a durable subscription on OSB JMS Server 1, Client 41 to 80 create a durable subscription on OSB JMS Server 2 etc. Will this help splitting the load on JMS Servers. What is your take on this. Also if oen of the nodes go down, only 40 stores dont receive the message till it is back up. Right!

    2) We are using OSB business service to put a message on the topic. By default the Enable Message Persistance is ticked on the business services in advanced JMS properties. I hope this ensures that if one of the nodes are down, when ever it is back up, the clients would get the message (durable subscriptions). No message is lost. Please clarify this as it is very imporant we dont loose any message.

    3) Also i wanted to know that on the connection factory, how does the client id policy (restricited or unrestricted) and subscription policy (sharing and exclusive) effect our scenario. What should be the values for these for a replicated distributed topic in the above scenario.

    Thanks a lot!
  • 3. Re: Durable Subscription Advice for Replicated Distributed Topic
    Tom B Expert
    Currently Being Moderated
    1) Do you think it makes sense to split the standalone java durable subscribers over the cluster. I mean 400 such clients over a 10 node OSB clsuter. Client 1 to 40 create a durable subscription on OSB JMS Server 1, Client 41 to 80 create a durable subscription on OSB JMS Server 2 etc. Will this help splitting the load on JMS Servers. What is your take on this. Also if oen of the nodes go down, only 40 stores dont receive the message till it is back up. Right!
    Right! I agree on all counts.
    2) We are using OSB business service to put a message on the topic. By default the Enable Message Persistance is ticked on the business services in advanced JMS properties. I hope this ensures that if one of the nodes are down, when ever it is back up, the clients would get the message (durable subscriptions). No message is lost. Please clarify this as it is very imporant we dont loose any message.
    Seems like a logical conclusion, but I'm not familiar with OSB's settings. When OSB uses the JMS layer, the messages need to be sent with a Persistent delivery mode QOS and the subscriptions need to be durable in order to guard against data loss.
    3) Also i wanted to know that on the connection factory, how does the client id policy (restricited or unrestricted)
    Use the default restricted if you want the standard JMS session "unsubscribe" verb to work, otherwise you'll need to use our weblogic.jms.WLSession.unsubscribe(Topic, String) extension to clean up subscriptions.

    The problem with restricted is that it places somewhat of a burden on WL JNDI (we internally use WL's clustered JNDI to track restricted client-ids), but this is probably not much of an issue since your use case only has 80 long lived subscriptions.

    Another issue is that restricted requires that each separate connection use a different client-id. This can be a bit of an inconvenience or limit your ability to scale via shared subscriptions.
    and subscription policy (sharing and exclusive) effect our scenario. What should be the values for these for a replicated distributed topic in the above scenario.
    Per the JMS spec, a single subscription may only push messages to a single subscriber. Sharing is helpful if you need to multi-thread the processing of messages from a single subscription.

    HTH,

    Tom
  • 4. Re: Durable Subscription Advice for Replicated Distributed Topic
    921672 Newbie
    Currently Being Moderated
    Thanks Tom.

    One last doubt that I forgot to ask. what about the t3 URL for all the 400 clients. Should i use the cluster URL for all the stores or individual URLs, since clients 1 to 40 our pointing to OSB JMS Server 1, clients 41 to 80 and pointing to OSB JMS Server 2 and ..........................Clients 361 to 400 are pointing to OSB JMS Server 10.

    Does this impact anything? Currently we are using the same t3 URL for all 400 stores as mentioned below:

    PROVIDER_URL: t3://hostA:portA,hostB:portB,hostC:portC,hostD:portD,hostE:portE,hostF:portF,hostG:portG,hostH:portH,hostI:portI,hostJ:portJ

    or like this:
    JMSServer_osb_server1@jms.rltp.employee.topic for Clients 1 to 40 (t3://hostA:portA)
    JMSServer_osb_server2@jms.rltp.employee.topic for Clients 41 to 80 (t3://hostB:portB)
    JMSServer_osb_server3@jms.rltp.employee.topic for Clients 81 to 120 (t3://hostC:portC)
    JMSServer_osb_server4@jms.rltp.employee.topic for Clients 121 to 160 (t3://hostD:portD)
    JMSServer_osb_server5@jms.rltp.employee.topic for Clients 161 to 200 (t3://hostE:portE)
    JMSServer_osb_server6@jms.rltp.employee.topic for Clients 201 to 240 (t3://hostF:portF)
    JMSServer_osb_server7@jms.rltp.employee.topic for Clients 241 to 280 (t3://hostG:portG)
    JMSServer_osb_server8@jms.rltp.employee.topic for Clients 281 to 320 (t3://hostH:portH)
    JMSServer_osb_server9@jms.rltp.employee.topic for Clients 321 to 360 (t3://hostI:portI)
    JMSServer_osb_server10@jms.rltp.employee.topic for Clients 361 to 400 (t3://hostJ:portJ)

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points