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!
No worries. I'll only be able to look at it in the first week of Jan, but I'm
sure others on this list will be able to comment in the meanwhile. :-)
Cheers
Israel
On Wed, Dec 15, 2010 at 5:23 PM, Manik Surtani <manik(a)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(a)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(a)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(a)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(a)jboss.org
>> > <mailto:manik@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(a)jboss.org <mailto:manik@jboss.org>
>> > Lead, Infinispan
>> > Lead, JBoss Cache
>> >
http://www.infinispan.org
>> >
http://www.jbosscache.org
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
>> >
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev(a)lists.jboss.org
>> >
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> --
>> Navin Surtani
>> Intern Infinispan
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
>
http://www.infinispan.org
>
http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org