[infinispan-dev] ISPN 200

Israel Lacerra israeldl at gmail.com
Thu Dec 16 06:15:11 EST 2010


Hi Manik,

I've finished the LazyIterator. Now I need to:

- Code some good tests (now I'm testing using InfinispanDemo with some
changes)
- Implement all methods of iterators (the most simple are not ready yet)
- Migrate to git

I will send the code to you in the end of the next week (I think git will
help with this) and probably you will show a lot of things to improve!

Cheers
Israel

On Wed, Dec 15, 2010 at 5:23 PM, Manik Surtani <manik at jboss.org> wrote:

> Hi Israel
>
> Any updates on ISPN-200?  How are you getting on?
>
> Cheers
> Manik
>
> On 15 Sep 2010, at 12:56, Israel Lacerra wrote:
>
> Thanks Manik!! I just did not understand the last item..
>
> > - on an implementation level, the GetHItsCommand (or something like that)
> could return with a single hit, or N hits, with a flag of whether more hits
> are available or not.
>
>
> Israel
>
> On Wed, Sep 15, 2010 at 7:16 AM, Manik Surtani <manik at jboss.org> wrote:
>
>> How about something like:
>>
>> - Broadcast the query
>> - Every node creates the QueryHits inst, runs the query and collects
>> results.  Starts streaming the results back immediately.
>> - The lazy iterator returns to the user immediately, and maintains an
>> internal cache of results coming in from N remote QueryHits instances
>> - iterator.next() blocks until this cache has available entries to return.
>> - on an implementation level, the GetHItsCommand (or something like that)
>> could return with a single hit, or N hits, with a flag of whether more hits
>> are available or not.
>>
>> Does that help?
>>
>> Manik
>>
>>
>> On 14 Sep 2010, at 20:46, Israel Lacerra wrote:
>>
>> Hi guys,
>>
>> I'm still thinking about it, but I don't have a really good idea about the
>> lazy iterator yet. The only way (that I see) I could make it more lazily is:
>>
>> - Broadcast the query.
>> - Every node creates a QueryHits instance with the query and keep it in a
>> simple little cache (array, hash, etc)
>> - A "state" of the query is created and every lazyIterator.next() must
>> send a command to a node and get the next hit (the next key).
>> - After a certain time, the instances of queryHits "dies".
>>
>> It seems to me that this is not too efficient. But I don't have any other
>> ideas.
>>
>> Do you have any suggestions about it?
>>
>> thanks!
>> Israel
>>
>> AnyoneOn Tue, Aug 31, 2010 at 9:14 AM, Israel Lacerra <israeldl at gmail.com
>> > wrote:
>>
>>> Hi Navin,
>>>
>>> I'm trying to do ISPN-200 (https://jira.jboss.org/browse/ISPN-200) and I
>>> don't know how to implement a good lazy iterator in a "distributed way".
>>>
>>> (Sorry... my english is not soo good. If you don't understand again,
>>> please just ask again!  :)
>>>
>>>
>>> Israel
>>>
>>>
>>> On Tue, Aug 31, 2010 at 6:27 AM, Navin Surtani <nsurtani at redhat.com>wrote:
>>>
>>>> Hi Israel,
>>>>
>>>> Just a quick question to your issue. What do you mean by you do not have
>>>> the LazyIterator? I suppose I'm not really understanding what your issue
>>>> is. Is it just that you don't want the lazy version or you don't know
>>>> how to use it? :S
>>>>
>>>>
>>>> On 25/08/10 14:39, Israel Lacerra wrote:
>>>> > Ok, Manik!
>>>> >
>>>> > I've already have a code working, but not too "lazy" (and without the
>>>> > "sort" part). I get the keys on all nodes, and then I use them. So I
>>>> > have a EagerIterator, but not the LazyIterator. :/
>>>> >
>>>> > I'll think about it...
>>>> >
>>>> > thanks
>>>> >
>>>> > On Wed, Aug 25, 2010 at 10:23 AM, Manik Surtani <manik at jboss.org
>>>> > <mailto:manik at jboss.org>> wrote:
>>>> >
>>>> >
>>>> >     On 24 Aug 2010, at 17:20, Israel Lacerra wrote:
>>>> >
>>>> >      > Manik,
>>>> >      >
>>>> >      > What you mean by:
>>>> >      > "   * The calling node returns a CacheQuery impl that lazily
>>>> fetches
>>>> >      > and collates results from the cluster." (JIRA)
>>>> >      >
>>>> >      > Is enough if each node returns a list of keys and then, we
>>>> lazily
>>>> >     get the values using the keys? Or the process has to be more lazy
>>>> yet?
>>>> >
>>>> >     I think it can be "more lazy" as you said.  :)
>>>> >     --
>>>> >     Manik Surtani
>>>> >     manik at jboss.org <mailto:manik at jboss.org>
>>>> >     Lead, Infinispan
>>>> >     Lead, JBoss Cache
>>>> >     http://www.infinispan.org
>>>> >     http://www.jbosscache.org
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >     _______________________________________________
>>>> >     infinispan-dev mailing list
>>>> >     infinispan-dev at lists.jboss.org <mailto:
>>>> 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
>>>>
>>>>
>>>> --
>>>> Navin Surtani
>>>> Intern Infinispan
>>>> _______________________________________________
>>>> 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
>>
>>
>>  --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.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
>
>
>  --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20101216/c7ab44c7/attachment-0001.html 


More information about the infinispan-dev mailing list