manifoldcf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Tavard <olivier.tav...@francelabs.com>
Subject Re: ZK based synchronization questions
Date Thu, 02 Nov 2017 07:40:39 GMT
Hi Karl,

OK it makes senses, thanks for the explanation !

Best regards,

Olivier TAVARD


> Le 31 oct. 2017 à 17:53, Karl Wright <daddywri@gmail.com> a écrit :
> 
> Hi Olivier,
> 
> Zookeeper connections are pooled, so they are pulled out of the pool at will by ManifoldCF
and returned when the lock etc is done.  This means you really should need only a total number
of outstanding Zookeeper handles that is on the same order as the number of operating threads
in your ManifoldCF cluster.  We do have some users, though, who have hundreds of worker threads
in the mistaken assumption that more threads makes the system faster, and when people do stuff
like that, we often get tickets because the number of zookeeper handles runs out.  That is
why there is such a large number.
> 
> Thanks,
> Karl
> 
> 
> On Tue, Oct 31, 2017 at 12:23 PM, Olivier Tavard <olivier.tavard@francelabs.com <mailto:olivier.tavard@francelabs.com>>
wrote:
> Hi all,
> Just to clarify my concern on ZK:
> To my knowledge, best practices concerning ZK connections are to not go beyond 60. Is
there any rationale for setting it at 1000 for MCF ? 
> Could this can have side effects on our ZK cluster shared by MCF and SolrCloud ?
> 
> Thanks,
> 
> Olivier
> 
> 
>> Le 23 oct. 2017 à 17:19, Olivier Tavard <olivier.tavard@francelabs.com <mailto:olivier.tavard@francelabs.com>>
a écrit :
>> 
>> Hello,
>> 
>> We configured MCF to use ZK sync instead of file sync. We noticed a huge improvement
regarding the stability of the MCF jobs in every case especially for large data to index (15M
of files using the Windows Share repository connector). Before that, we had some errors when
the job was running randomly. With that change, we did not notice any error on the job so
far.
>> However, after testing that configuration on several servers, we had errors reported
and I would like to know what you suggest for that.
>> We installed MCF on servers that already have Solr 6.6.X on them. I saw on other
threads on the mailing list that it was OK to use existing ZK installation rather than using
a new ZK instance dedicated to MCF so we use the same ZK for both Solr and MCF.
>> After starting MCF and Solr, we noticed some errors on the MCF log for few servers
: Session 0x0 for server localhost/127.0.0.1:2181 <http://127.0.0.1:2181/>, unexpected
error, closing socket connection and attempting reconnect
>> java.io.IOException: Connection reset by peer
>> Then after checking the ZK log we saw this message : "WARN 2017-10-23 08:53:35,431
(NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181 <http://0.0.0.0/0.0.0.0:2181>) - ZooKeeper|ZooKeeper|zookeeper.server.NIOServerCnxnFactory|Too
many connections from /127.0.0.1 <http://127.0.0.1/> - max is 60"
>> Therefore we changed the parameter maxClientCnxns from 60 in our ZK configuration
to 1000 as in the MCF zookeeper.cfg default file and there is no problem anymore.
>> I  would just like to know why this parameter needs to be so high for MCF needs and
if other people share their ZK cluster with both Solr and MCF too without any problem. And
last question I had : MCF uses Zookeeper 3.4.8 while Solr 6.6+ uses ZK 3.4.10.  As written
above our ZK cluster version is 3.4.10 and we use MCF on it, is it ok to do that or would
it be best to use a ZK installation with version 3.4.8 only for MCF ?  So far we did not see
any problems using it.
>> 
>> Thanks,
>> Best regards, 
>> 
>> Olivier TAVARD
> 
> 


Mime
View raw message