[infinispan-dev] staggered_get Question

[Sanne Grinovero]

Thanks, got it now. Definitely makes sense.
This order could even be resolved just once at each view change, and
so store the pre-calculated "preferred node" in the metadata we have
for each segment.

 -Sanne

On 12 July 2013 19:40, Erik Salter <an1310 at hotmail.com> wrote:
> Hi Sanne,
>
> By "proximate", I'd like to fetch from an owner on the same
> machine/rack/site (as defined by the TACH) as the originator.    The idea is
> to minimize the network traffic and any assorted latency as much as
> possible.  This doesn't involve XSite.  FWIW, if I use XSite, it won't be
> for reading.
>
> Thanks,
>
> Erik
>
>
> -----Original Message-----
> From: infinispan-dev-bounces at lists.jboss.org
> [mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Sanne Grinovero
> Sent: Friday, July 12, 2013 12:54 PM
> To: infinispan -Dev List
> Subject: Re: [infinispan-dev] staggered_get Question
>
> Hi Erik,
> could you elaborate on how "proximate" would look like please? I'm not
> understanding how X-Site is relating to this.
>
> Mircea,
> how is a secondary owner going to behave when setting MAIN_OWNER ?
>
>  -Sanne
>
> On 12 July 2013 17:21, Erik Salter <an1310 at hotmail.com> wrote:
>> - my boss and others.
>>
>> Why not proximate?  I may only want to get data from the same
>> machine/site and retry if necessary.
>>
>> Erik
>>
>> -----Original Message-----
>> From: infinispan-dev-bounces at lists.jboss.org
>> [mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Mircea
>> Markus
>> Sent: Friday, July 12, 2013 11:56 AM
>> To: Hammad Said; infinispan -Dev List
>> Cc: Bryan Perrotti (bperrott); Erik Salter (esalter); Michael Walker;
>> Balaji Rajam
>> Subject: Re: [infinispan-dev] staggered_get Question
>>
>>
>> On 12 Jul 2013, at 18:22, Mircea Markus <mmarkus at redhat.com> wrote:
>>
>>> (Adding -dev)
>>>
>>> On 12 Jul 2013, at 05:04, Hammad Said <hsaid at redhat.com> wrote:
>>>
>>>> I have implemented the change for address ordering in and created
>>>> the
>> topic branch optimize_staggered-get in:
>>>> https://github.com/hsaid4327/infinispan.git
>>>
>>> which branch do you want me to look at?
>>> Or better can you please issue a pull request with your change?
>>>
>>>>
>>>> The next part is the configuration change. For the configuration
>>>> change,
>> there are certain design decisions that need to be made:
>>>> a) We need to introduce two configuration params staggered_get_flag
>>>> and
>> staggered_get_timeout. Where exactly are these params specified in the
>> cache configuration file. At the global or the cache level and under what
> element.
>> Are they be implemented as attributes of clustering element, separate
>> element as a child of clustering or cache.
>>>
>>> What about something like:
>>> <cluseter>
>>>  <remoteReads policy="ALL|STAGGER|MAIN_OWNER" staggerTimeout="50"/>
>>
>> to clarify there are 3 ways of doing remote reads: all owners (like we
>> currently do), staggered (as discussed) and only to the main owner.
>>
>>> </cluster>
>>>
>>> What others think?
>>>
>>>> b) once we read the properties second big question is how to pass
>>>> them on
>> to the dispatcher in question i.e CommandAwareRpcDispatacher. There
>> are two choices here:
>>>>  1- We change the method signature of invokeRemoteCommands and pass
>>>> on
>> these two params. This choice involves making up the calling stack in
>> the classes that invoke this method  namele JGroupsTransport and
>> possible up the calling stream.
>>>> 2- Another option is to set it on the ResponseFilter which is passed
>>>> to
>> CommandAwareRpcDispatcher.
>>>
>>> I'm not sure the CARD needs to be aware of the staggering. I'd think
>>> it is
>> the responsibility of the caller (DistributionInterceptor) to
>> orchestrate staggering..
>>>
>>>>
>>>> Also, would the changes in configuration would require making a
>>>> change in
>> XSD schema file?
>>>>
>>>> Thanks!
>>>> Hammad
>>>>
>>>>
>>>> `
>>>
>>> Cheers,
>>> --
>>> Mircea Markus
>>> Infinispan lead (www.infinispan.org)
>>>
>>>
>>>
>>>
>>
>> Cheers,
>> --
>> Mircea Markus
>> Infinispan lead (www.infinispan.org)
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev