Mailing-List: contact lucy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Tue, 22 Nov 2011 12:33:03 -0800
From: Marvin Humphrey <marvin@rectangular.com>
To: lucy-user@incubator.apache.org
Message-ID: <20111122203303.GA22588@rectangular.com>
References: 
 <CAKn6EF-YnkJ7iRSgA6L8bJLY_x3i7sn--ZfwsdOoKkHxAXffBA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAKn6EF-YnkJ7iRSgA6L8bJLY_x3i7sn--ZfwsdOoKkHxAXffBA@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [lucy-user] lucy-dev and 0.3.0

On Tue, Nov 22, 2011 at 09:25:48PM +0200, goran kent wrote:
> My radar picked up some chatter from the dev list (to which I'm not
> subscribed, so sorry for the cross-post):
> 
> > perhaps we can disable the select loop and just go with serial collection of responses -- the remotes still work in parallel that way.
> 
> I'm curious about the apparent dichotomy in the above:  serial
> collection <--> remote parallel?

PolySearcher model: 

    for my $remote (@remote_nodes) {
        $poly_searcher->send_request($remote, $request);
        $poly_searcher->retrieve_response($remote);
    }

ClusterSearcher model:

    for my $remote (@remote_nodes) {
        $cluster_searcher->send_request($remote, $request);
    }
    for my $remote (@remote_nodes) {
        $cluster_searcher->retrieve_response($remote);
    }

In the PolySearcher model, we wait for a response from each remote node before
even sending the request to the next remote node; under ClusterSearcher we
fire off all requests, then gather all responses.  It's far from perfect, but
it's better than before and at least it wouldn't be crashing outright the way
the select loop is for you at the moment.

Marvin Humphrey