[infinispan-dev] ISPN 200

[Navin Surtani]

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