lucy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-user] Concurrent searching
Date Fri, 18 Nov 2011 14:14:10 GMT
On Fri, Nov 18, 2011 at 11:19:34AM +0200, goran kent wrote:
> More accurately, the remote servers are still using the older
> pre-ClusterSearcher code, which expects a cleartext pw.  New version
> expects the pw in a serialised packet, and possibly other important
> stuff as well...
The internal application protocol changed incompatibly.  Sorry, this is part
of living on trunk.  It would be ideal if we could support rolling updates
during development, but particularly at this stage, imposing that constraint
would slow down innovation, wouldn't be 100% reliable, and wouldn't always be
practical in any case.

I'll try to give you a heads-up when you can cheat and only update the node
running ClusterSearcher without updating the remotes.

> Have now upgraded to latest trunk on the remote machines, and here's
> the latest (testing with a single shard):
> Then fails with:
>  at /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/LucyX/Remote/
> line 104
> 	LucyX::Remote::SearchServer::serve('LucyX::Remote::SearchServer=SCALAR(0xb8d5190)')
> called at ./lucy_remote_search_server line 212
> The client fails with:
> Use of uninitialized value in numeric eq (==) at
> /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/LucyX/Remote/
> line 158.

This is almost certainly happening because we have enabled non-blocking i/o
but not yet taken all the necessary precautions to detect and retry when
reads/writes do not succeed.  I expect to work on this soon.  In the meantime,
I suggest commenting out one line in (only needed on the
client node):

    +++ b/perl/lib/LucyX/Remote/
    @@ -53,7 +53,7 @@ sub new {
             my $sock = IO::Socket::INET->new(
                 PeerAddr => $shard,
                 Proto    => 'tcp',
    -            Blocking => 0,
    +            #Blocking => 0,

I'll let you know when I think it's safe to make the i/o non-blocking once again.

Marvin Humphrey

View raw message