Hi Shreedhar.
I would like to explain JMS's clustering case in our WAS. Of course, this is on an experimental basis.
Assume that "WAS_A" and "WAS_B" are members of "TestCluster" group.
When WAS_A and WAS_B are booted, each one of components which belongs to WAS first registers interest Shoal's Action Factories.
WAS_A and WAS_B have JMS component and the JMS component registers JoinedAndReadyNotificationActionFactory with own callback in Shoal.
Then each JMS stores own configurations into Shoal's DSC. ex) destinations, durable subscriptions. Then JMS reports ready state.
When all components are ready, WAS calls GroupManagementService.reportJoinedAndReadState().
In shutdown case , first all components removes own configurations and reports Shutdown state. When all components shutdown, WAS calls GroupManagementService.shutdown().
JMS has three configurations.
1. Connection factory
2. Destination
3. Durable subscription
Some of configurations should be shared in clustered JMS. In other words, WAS_A's JMS should know WAS_B's configurations of JMS and WAS_B's JMS should know WAS_A's.
Now I want to describe Destination and Durable subscription's use case above 2, 3.
* Destination
After JMS registered listeners in Shoal, JMS stores own configuration into Shoal's DSC. ex) destinations, durable subscriptions
WAS_A has only Destination_A and stores it into Shoal's DSC. WAS_B has only Destination_B and stores it into Shoal's DSC.
But WAS_A should know what destinations WAS_B has. WAS_B should also know what destinations WAS_A has in this clustered JMS, because though JMS's client sends messages to WAS_B with Destination_A, messages should be delivered to proper Destination.
If Destinations of all members and member informations are shared, a member can find proper member though the member does't have proper Destination.
At this time, because only JMS needs destinations, destinations should be stored with component's scope. So if GMS API supports MemberDetail API with component's scope or addToCache(component, memberToken, key, value) or etc... about DSC API, JMS can use it easily without DSC's knowledes included group handle API.
* Durable subscription
Durable subscription's use case is different with destination's.
If WAS_A has Topic destination which had DurableSubscription_A and DurableSubscription_B, WAS_B should also have Topic destination which had DurableSubscription_A and DurableSubscription_B.
Durable subscription has the following informations.
1. Client ID
2. Durable subscription name
3. Selector
4. etc...
When JMS's Producer puts messages into Topic destination, messages can be distributed into both WAS_A and WAS_B.
Assume that "1" ,"2" ,"3" means messages and WAS_A's Topic destination has "1" and "2" messages and WAS_B's Topic destination has "3" message after JMS's Producer put messages.
Two Topic destinations had the same durable subscription.
If the durable subscription was changed by client request in WAS_B, as JMS spec, all messages which related the durable subscription should be removed.
In other words, though the durable subscription was changed in only WAS_B, "1" and "2" in WAS_A as well as "3" in WAS_B should be removed at this time.
If "Selector"(above 3) of the durable subscription was changed by client request in WAS_B, WAS_B's JMS updates own durable subscription locally. Then because the durable subscription uses Shoal's DSC, WAS_A's durable subscription will be also updated. But WAS_A can't know the point of time without callback function or checking DSC's data periodically. So WAS_A can't remove "1" and "2"'s messages when the durable subscription is changed in WAS_B.
If DSC can have listeners like GMSMessage, WAS_A can be aware of changes of WAS_B's durable subscription and remove messages.
I am wondering whether my reply can be enough scenarios or not.
If you think that my descriptions is not clear or have some strange logic, please let me know.
Thanks.
--
Bongjae Chang
----- Original Message -----
From: Shreedhar Ganapathy
To: dev_at_shoal.dev.java.net
Sent: Thursday, June 19, 2008 2:41 AM
Subject: Re: [Shoal-Dev] About MemberDetails API and DSC's notification
Hi Bongjae
I am trying to understand your use case. Can you walk me through an end-to-end example covering both sending and receiving side and covering startup to shutdown scenarios?
Thanks
Shreedhar
Bongjae Chang wrote:
Hi.
I have some questions about DSC and MemberDetails
I am trying to apply Shoal to our WAS(Web Application Server)
WAS has many components. ex) JMS, Security, JNDI, etc...
A componet has own configuration. If many WAS are clustered, I want to share configurations between same components.
I know DSC is applied to this case. But because GroupManagementService interface provides users with MemberDetails API, if MemberDetails API has component parameter, I can only use GroupManagementService interface without using DSC directly.
Of course, I know MemberDetails API is not for components but because DSC supports memory repository for components, I think it is not bad that MemberDetails API is used for components. Actually I wanted to use only GMS API without DSC's knowledge in this case.
ex)
pubic void updateMemberDetails( final String memberToken, final String componentName, final Serializable key, final Serializable value ) {
if ( componentName == null )
componentName = MEMBER_DETAILS;
ctx.getDistributedStateCache().addToCache( componentName, memberToken, key, value );
}
And Assuming components already shared all configuration, if a component's configuration is changed dynamically, the component will maybe call updateMemberDetails() or DSC.addToCache() for renewing own configuration. Then other component will receive the change and the change will be updated locally in other component finally.
But other component can't be aware of the change at this point of time. Of course the change will be updated well, but I just want to know this point of time in order to execute some logic.
Of course, I know I can resolve this usecase if I use MessageActionFactory and GroupHandle's sendMessage(componentName, message) and own memory repository.
But I think that if DSC provides some listeners like GMSMessage, this usecase can be resolved easily.
ex)
gms.addActionFactory( new DistributedStateCacheFactoryImpl( callBack) ), componentName );
I am eager to know your opinions about this. Please advice me.
Thanks.
--
Bongjae Chang