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