atom feed27 messages in org.apache.lucene.lucy-userRe: [lucy-user] Concurrent searching
FromSent OnAttachments
goran kentNov 14, 2011 2:59 am 
Marvin HumphreyNov 14, 2011 5:14 am 
goran kentNov 14, 2011 6:42 am 
Nathan KurzNov 14, 2011 2:58 pm 
goran kentNov 17, 2011 12:37 am 
Marvin HumphreyNov 17, 2011 3:24 pm 
goran kentNov 17, 2011 11:50 pm 
goran kentNov 18, 2011 1:19 am 
Marvin HumphreyNov 18, 2011 6:13 am 
goran kentNov 18, 2011 6:36 am 
goran kentNov 18, 2011 10:18 am 
goran kentNov 23, 2011 2:30 am 
goran kentNov 23, 2011 3:24 am 
goran kentNov 23, 2011 3:49 am 
goran kentNov 23, 2011 4:05 am 
Nick WellnhoferNov 23, 2011 4:27 am 
goran kentNov 23, 2011 4:30 am 
Marvin HumphreyNov 23, 2011 4:40 am 
goran kentNov 23, 2011 4:51 am 
goran kentNov 23, 2011 4:59 am 
goran kentNov 23, 2011 5:55 am 
Marvin HumphreyNov 23, 2011 12:34 pm 
goran kentNov 24, 2011 12:50 am 
Nick WellnhoferNov 24, 2011 2:16 am 
goran kentNov 24, 2011 2:49 am 
goran kentNov 24, 2011 3:57 am 
Marvin HumphreyNov 26, 2011 10:23 am 
Subject:Re: [lucy-user] Concurrent searching
From:goran kent (gora@gmail.com)
Date:Nov 18, 2011 6:36:54 am
List:org.apache.lucene.lucy-user

On Fri, Nov 18, 2011 at 4:14 PM, Marvin Humphrey <mar@rectangular.com> wrote:

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.

No worries at all - this is to be expected.

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'll let you know when I think it's safe to make the i/o non-blocking once
again.

cool.

Thanks for the feedback!