Hi Shreedhar
Responses inline.
Shreedhar Ganapathy wrote:
> Hi Siva
> Some responses below:
>
>>> In such a case, the RA or JCA or possibly an object representing a
>>> collection of Adapters (lets call it a RAFacade) is simply a client
>>> component for GMS within a clustered instance. And gets notified
>>> when it can participate in the group of instances.And once in the
>>> group, the RAFacade can take actions to manage its state and RAs in
>>> different instances can talk to each other in a cluster if need be.
>>> That said, solution for clustered instance access to a backend EIS
>>> could be in found through more than one approach.
>> Do we have any samples/documentation showing how components deployed
>> in GlassFish [EJB/Connectors] could use GMS to co-ordinate activities
>> within themselves in a cluster?
> In GlassFish we have components such as transaction recovery, Iiop
> failover loadbalancer using Shoal. That may help. Additionally, the
> Shoal example uses a mock Application server along with two service
> threads named "EJBContainer" and "TransactionService" to demonstrate how
> these components in an app server coordinate with each other.
>
> Look here :
> https://shoal.dev.java.net/source/browse/shoal/gms/tests/com/sun/enterprise/ee/cms/tests/
Thanks, this helps.
>
> more below:
>>
>>>>
>>>> The question really is that, are our clustering infrastructure like
>>>> GMS and in-memory replication reusable?
>>> GMS is certainly designed for reusability assuming that within a VM,
>>> multiple components can use it for their own purposes in a
>>> group/collection context. I am not sure I understand how in-memory
>>> replication comes into the picture here.
>> I think they were wanting some form of in-memory replication to keep
>> track of RA state that could be shared across RA instances in a cluster.
> Does not seem like a high throughput activity. Shoal provides the
> ability to send (and receive) messages to (from) target components in
> target instances thus allowing an RA component to address a message to
> the group( or individual member) with target component, say "RA". This
> is one way to track RA state.
> Another way is to use the provided default implementation of
> DistributedStateCache which is a shared cache across all instances.
> Putting the RA state in the DSC would make it available in all
> instances. An RA manager could simply then consult the DSC, for
> instance, to find out which RA is in active state.
This DistributedStateCache should work. Thanks.
>
> Caveat: I am not sure if this RA caching is something we should consider
> for 9.1 FCS at this late stage. We should take into account testing
> resources(or lack thereof) and the riskiness of adding such features
> late in the day.
I am sorry if I was not clear. This discussion was to figure out what a resource
adapter [a 3rd party RA deployed in GlassFish] could do to achieve the above
requirements. I don't think the connector container in GlassFish should provide
this feature as of now.
Thanks
--Siva.
>>
>> Thanks
>> --Siva
>>>>
>>>> thanks,
>>>> Binod.
>>>>
>>>>> Do you mean Shoal <https://shoal.dev.java.net>GMS ?
>>>>> I would need more data to talk about how JCA connectors could be
>>>>> clustered.
>>>>> Shoal GMS is a generalized component that is independently
>>>>> employable in-process in a java application or appserver or any
>>>>> component in a VM to group VMs.
>>>>>
>>>>> glassfish_at_javadesktop.org wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Incidentally, I recently ran into a similar situation.
>>>>>>
>>>>>> Can the mechanism that the HTTP session replication / SFSB uses,
>>>>>> i.e. GSM, memory replication, etc. be generalized so that it can
>>>>>> be reused in other components?
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Frank Kieviet
>>>>>> http://blogs.sun.com/fkieviet
>>>>>> [Message sent by forum member 'fkieviet' (fkieviet)]
>>>>>>
>>>>>> http://forums.java.net/jive/thread.jspa?messageID=203962
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>