[infinispan-dev] ISPN 200

[Israel Lacerra]

>I think if we allways block iterator.next() until we have at least a value
of each node , we can apply sort in this values (since every node already
made this).
I mean, the idea is to make a "merge" of the results... and the next()
blocks until we have some results already sorted.

Emmanuel, do you think this can work?

On Wed, Sep 15, 2010 at 8:54 AM, Israel Lacerra <israeldl at gmail.com> wrote:

> >You give up any hope of implementing sorting (explicit or using
> relevance).
>
> I think if we allways block iterator.next() until we have at least a value
> of each node , we can apply sort in this values (since every node already
> made this). That's what you said, Navin?
>
>
> On Wed, Sep 15, 2010 at 8:16 AM, Navin Surtani <nsurtani at redhat.com>wrote:
>
>> Isn't that an issue that comes with lots of hits in a lazyIterator anyway?
>>
>> I mean, if you're only going to load up a 'few hits at a time' then you
>> can in theory only sort the few hits that you have loaded up anyway
>> right? :S
>>
>> On 15/09/10 12:01, Emmanuel Bernard wrote:
>> > You give up any hope of implementing sorting (explicit or using
>> relevance).
>> >
>> > On 15 sept. 2010, at 12:16, Manik Surtani 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
>> >>>
>>
>>
>> --
>> Navin Surtani
>> Intern Infinispan
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100915/1cda4cc4/attachment.html