incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron McCurry <amccu...@gmail.com>
Subject Re: sessions
Date Sun, 03 Feb 2013 13:52:12 GMT
-It seems to me if we promote long-lived sessions, then the
QueryStatusContainer
lookup map grows unbounded?

Currently yes they would, we will need to place a cap on how long the query
status can live after it's complete.

-On the other hand, if short sessions are promoted, the BlurServer session
map grows unbounded?

Current yes if the user doesn't close the session on each of servers.  This
is bad and incomplete, if close on the session is called on one server then
it needs to be pushed to all.  Also there really needs to be a session
manager to cleanup old sessions that are not in use.

-I also don't yet see how the sessions work with multiple controllers?

Yep you are right.  Overall I don't like the session idea.  The only reason
it exists is because of the natural of Lucene indexes changes.

The problem it attempts to solve is the following.  Search arrives at the
controller, then it gets sprayed to all the other servers.  Those servers
respond with the document locations (shard id + lucene doc id) and the
controller picks the top N number of documents to respond to the client.
 The client then in turn fetches the correct documents from the servers,
however if the indexes how changed on those servers the document location
id may be invalid.  The with session object a user can be insured to have a
static view of the data and the indexes throughout the lifetime of the
session.

I really would love to hear about any other thoughts on how to deal with
this issue.  No matter how radical.

Aaron


On Sat, Feb 2, 2013 at 10:03 PM, Tim Williams <williamstw@gmail.com> wrote:

> It seems to me if we promote long-lived sessions, then the
> QueryStatusContainer lookup map grows unbounded?  On the other hand,
> if short sessions are promoted, the BlurServer session map grows
> unbounded? I also don't yet see how the sessions work with multiple
> controllers?
>
> --tim
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message