On Fri, Nov 18, 2011 at 4:14 PM, Marvin Humphrey <[email protected]> wrote: >> Then fails with: >> at >> /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/LucyX/Remote/SearchServer.pm >> 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/ClusterSearcher.pm >> 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 ClusterSearcher.pm (only needed on the > client node): > > +++ b/perl/lib/LucyX/Remote/ClusterSearcher.pm > @@ -53,7 +53,7 @@ sub new { > my $sock = IO::Socket::INET->new( > PeerAddr => $shard, > Proto => 'tcp', > - Blocking => 0, > + #Blocking => 0, > );
I've got some time to kill and would like to help debug what's occurring between the client and server. Any pointers on what I should look for? The locus is obviously around SearchServer::serve and ClusterSearcher::_multi_rpc and surrounding brush. I think I've narrowed it down to the server not handling the top_docs method (handshake, doc_max, doc_freq all seem ok), or more likely, the client not waiting for a response wrt top_docs - it also looks like the server never actually *gets* the top_doc method request. ...more to follow.
