Hi,

On Wed, Nov 26, 2014 at 5:27 PM, Udara Liyanage <ud...@wso2.com> wrote:

> Reading from registry frequently might be more expensive than distributed
> locking since a number of database queries are executed.
> +1 for distributed collections.
>
> Are we going to use Hazlecast or any other framework ?
>

We are planning to use Carbon clustering (abstraction) which internally use
Hazelcast.

On Wed, Nov 26, 2014 at 5:30 PM, Akila Ravihansa Perera <raviha...@wso2.com>
wrote:

>
>> We don't have to refresh the whole data structure, but only the
> invalidated object(s). We have to have a good registry structure for the
> topology in order for this to be effective.
>

A distributed map does this OOB.

>
>
>> - If above happens, when serving multiple requests (with a high
>> frequency) on different instances of CC, the system might come to an
>> inconsistent state because the in memory data structures have not updated
>> properly.
>>
>
> Good point, thanks for pointing out. But the same problem will occur when
> using cluster messages to replicate the state, right? I guess we will have
> to resort to a distributed lock in either case to avoid consistencies. I
> remember Isuru was working on a hierarchical locking approach for the
> topology. Perhaps we can incorporate that for this scenario as well.
>

We actually don't use cluster messages with a distributed map. However yes
in either approach we will need a distributed lock. Indeed, for topology we
should be able to change the existing locks to distributed ones if
clustering is enabled.

>
> If you're going to use a distributed map, how do you plan to utilize that
> to distribute the topology data structure? I think replicating the complete
> topology object on change would be very expensive, wdyt?
>
> No, by design it will only send the modifications.

Thanks



-- 
Imesh Gunaratne

Technical Lead, WSO2
Committer & PMC Member, Apache Stratos

Reply via email to