RE: Replicate configoverlay.json
Well. I have mixed cloud and master/slave concepts since solr is supporting. Is there nay way to replicate dynamic confugurations to slave without zookeeper? --Dinesh Sundaram -Original Message- From: Shawn Heisey [mailto:apa...@elyograg.org] Sent: Thursday, March 8, 2018 10:23 AM To: solr-user@lucene.apache.org Subject: Re: Replicate configoverlay.json On 3/8/2018 8:48 AM, Sundaram, Dinesh wrote: > Thanks Shawn for checking this. configverlay.json is not available under > /conf. Actually it is dynamic file which is available in zookeeper log.1 > binary file. So whenever we do the config update via API it will get saved > directly in the zookeeper log.1 binary file. Is there any way to replicate to > Slaves if any update happens to this file. If you're running zookeeper, then you're running SolrCloud. And if you're running SolrCloud, then you cannot (or at least SHOULD NOT) be using master/slave replication to keep things in sync. With collections in SolrCloud, any changes to your config with the config API should take effect on all replicas as quickly as Solr can get them reloaded. This is because the configuration is not on disk, it's in zookeeper, so all replicas should be using exactly the same config. Thanks, Shawn CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.
RE: Replicate configoverlay.json
Thanks Shawn for checking this. configverlay.json is not available under /conf. Actually it is dynamic file which is available in zookeeper log.1 binary file. So whenever we do the config update via API it will get saved directly in the zookeeper log.1 binary file. Is there any way to replicate to Slaves if any update happens to this file. --Dinesh Sundaram -Original Message- From: Shawn Heisey [mailto:apa...@elyograg.org] Sent: Wednesday, March 7, 2018 6:09 PM To: solr-user@lucene.apache.org Subject: Re: Replicate configoverlay.json On 3/6/2018 10:50 AM, Sundaram, Dinesh wrote: > Can you please share the steps to replicate configoverlay.json from > Master to Slave… in other words, how do we replicate from Master to > Slave if any configuration updated via API. If that file is in the same place as solrconfig.xml, then you would add it to the "confFiles" parameter in the master replication config. If it gets saved somewhere else, then I don't know if it would be possible. I've never used the config overlay, but it sounds like it probably gets saved in the conf directory along with the rest of the config files. https://urldefense.proofpoint.com/v2/url?u=https-3A__lucene.apache.org_solr_guide_6-5F6_index-2Dreplication.html-23IndexReplication-2DConfiguringtheReplicationRequestHandleronaMasterServer=DwIDaQ=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY=gCFZFMR7y0gzhIBFz1lKTqHFMl-3R6gq7ojE0Eam2Eg=2esFnHTWn51-I-gU9Ncq0-q5D1G5Y1n22XYkbfOBJOk=tDqgB09Ys3qiifFnM5p1melYpGuo3_HMT7LbYGGjjAE= Thanks, Shawn CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.
Replicate configoverlay.json
Team, Can you please share the steps to replicate configoverlay.json from Master to Slave... in other words, how do we replicate from Master to Slave if any configuration updated via API. Dinesh Sundaram MBS Platform Engineering Mastercard [cid:image001.png@01D3B541.4529DEF0] CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.
RE: SSL configuration with Master/Slave
FYI, This has been resolved. Dinesh Sundaram MBS Platform Engineering Mastercard [cid:image001.png@01D3892A.668B6700] From: Sundaram, Dinesh Sent: Monday, January 8, 2018 1:58 PM To: solr-user <solr-user@lucene.apache.org> Subject: SSL configuration with Master/Slave Team, I'm facing an SSL issue while configuring Master/Slave. Master runs fine lone with SSL and Slave runs fine lone with SSL but getting SSL exception during the synch up. It gives the below error. I believe we need to trust the target server at source. Can you give me the steps to allow inbound calls at source jvm. FYI, the same synch up works fine via http. 2018-01-08 13:57:06.735 WARN (qtp33524623-16) [c:dm-global s:shard1 r:core_node2 x:dm-global_shard1_replica_n1] o.a.s.h.ReplicationHandler Exception while invoking 'details' method for replication on master org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: https://test21.mastercard.int:8983/solr/dm-global_shard1_replica_n1 at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:640) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.handler.IndexFetcher.getDetails(IndexFetcher.java:1823) at org.apache.solr.handler.ReplicationHandler.getReplicationDetails(ReplicationHandler.java:954) at org.apache.solr.handler.ReplicationHandler.handleRequestBody(ReplicationHandler.java:332) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:526) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) at org.eclipse.jetty.server.Server.handle(Server.java:534) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108) at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) at java.lang.Thread.run(Thread.java:745) Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.ssl.Alerts.getSSLException(Alerts.ja
SSL configuration with Master/Slave
Team, I'm facing an SSL issue while configuring Master/Slave. Master runs fine lone with SSL and Slave runs fine lone with SSL but getting SSL exception during the synch up. It gives the below error. I believe we need to trust the target server at source. Can you give me the steps to allow inbound calls at source jvm. FYI, the same synch up works fine via http. 2018-01-08 13:57:06.735 WARN (qtp33524623-16) [c:dm-global s:shard1 r:core_node2 x:dm-global_shard1_replica_n1] o.a.s.h.ReplicationHandler Exception while invoking 'details' method for replication on master org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: https://test21.mastercard.int:8983/solr/dm-global_shard1_replica_n1 at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:640) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.handler.IndexFetcher.getDetails(IndexFetcher.java:1823) at org.apache.solr.handler.ReplicationHandler.getReplicationDetails(ReplicationHandler.java:954) at org.apache.solr.handler.ReplicationHandler.handleRequestBody(ReplicationHandler.java:332) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:526) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) at org.eclipse.jetty.server.Server.handle(Server.java:534) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108) at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) at java.lang.Thread.run(Thread.java:745) Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296) at
RE: Solrcloud with Master/Slave
Thanks Shawn and Erick. I guess now we are in same track. So two independent solrcloud nodes are allowed to sync up via master/slave method without referring any external/embedded zookeepers. I need to use -cloud in the command while starting solr otherwise I'm not able to see the admin console. That console is really cool for tracking solr activities. Dinesh Sundaram MBS Platform Engineering Mastercard -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Friday, January 5, 2018 10:58 AM To: solr-user <solr-user@lucene.apache.org> Subject: Re: Solrcloud with Master/Slave One slight correction. Solr will run perfectly fine with a single ZooKeeper. The recommendation for 3 is that running with a single ZooKeeper creates a single point of failure, i.e. if that node goes down for any reason your Solr cluster won't be able to update anything at all. You can still query, maybe, for a while. Two ZooKeepers will also run, but as Shawn says that's essentially totally wasting one of them as it doesn't buy you anything and makes your system _less_ robust. FWIW, Erick On Fri, Jan 5, 2018 at 7:57 AM, Shawn Heisey <apa...@elyograg.org> wrote: > On 1/4/2018 9:01 AM, Sundaram, Dinesh wrote: > > Thanks Shawn for your prompt response. Assume I have solrcloud A > > server > with 1 node runs on 8983 port and solrcloud B server with 1 node runs > on 8983, here I want to synch up the collection between solrcloud A > and B using the below replication handler. Is this advisable to use at > the solrcloud B ? > > > > > > > > > name="masterUrl">https://urldefense.proofpoint.com/v2/url?u=http-3A__solrcloudA-3A8983_solr_-24-257Bsolr=DwIBaQ=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY=gCFZFMR7y0gzhIBFz1lKTqHFMl-3R6gq7ojE0Eam2Eg=3jqDjqHZnl2sdIUhYF4uQBQQBHzg6zEshRmcDCPcWvM=tEY-h4ureY9H6AkD-b9wGLmOfYQ3NJp3Rg37lNBuPgY=. > core.name}/replication > > 00:00:20 > > > > > > One of the things I said in my last reply, at the beginning of a > paragraph so it should have been quite prominent, was "you can't mix > master-slave replication and SolrCloud." What part of that was not clear? > > You need to be running standalone mode (not cloud) if you want to use > master-slave replication. > > When things are set up correctly, SolrCloud will automatically keep > multiple replicas in sync, and copy the index to new replicas when > they are created. There is no need to manage it with replication config. > For replicating from one SolrCloud cluster to another, there is CDCR > as Erick described. > > Another thing Erick mentioned: What you actually have when you start > Solr the way you did is two completely independent SolrCloud clusters, > each of which only has one Solr server. Each solr instance is running > a zookeeper server embedded within it. There is no redundancy or > fault tolerance of any kind. > > If you want to run a fault-tolerant SolrCloud, you will need three > separate servers. The smallest possible setup would have both Solr > and ZooKeeper running on two of those servers (as separate processes). > The Solr instances would be started with a -z option (or the ZKHOST > environment variable) to locate the three ZK servers, and without the > -cloud option. The third server, which can be a much smaller system, > would only run ZooKeeper. You may also need a load balancer, > depending on what software your clients are using. > > The requirement of three servers comes from ZooKeeper, not Solr. A > two-server ZK ensemble is actually *less* reliable than a single > server, so it's not recommended. I don't know if they even allow such > a setup to work. > > Thanks, > Shawn > > CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.
RE: Solrcloud with Master/Slave
Ok thanks for your valuable reply. I want to see admin console so that I can monitor the collection details, that is the reason going to cloud mode. But here I need replication without zookeeper so had to choose regular master/slave replication. Am I mixing 2 different synchup procedures or this also okay? Dinesh Sundaram MBS Platform Engineering Mastercard -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Thursday, January 4, 2018 2:06 PM To: solr-user <solr-user@lucene.apache.org> Subject: Re: Solrcloud with Master/Slave Yes you do use ZooKeeper. Starting Solr with the -cloud option but _without_ ZK_HOST defined (or the -z parameter) starts an internal ZooKeeper on port 9983 (by default). This is evidenced by the fact that the admin UI has a "cloud" link along the left. In essence you have two separate clusters, each cluster just happens to exist on the same machine. Why bother with SolrCloud? Just configure old-style master/slave. SolrCloud is buying you nothing and running internal ZooKeepers is consuming resources for no good purpose. SolrCloud would help you if you set up a proper cluster with ZooKeeper and just had both of your nodes in the same cluster, one with replicas. That buys you HA/DR, NRT on both leader and follower etc. Up to you of course, but it's really hard to see what the purpose of running the way you are is. Best, Erick On Thu, Jan 4, 2018 at 11:38 AM, Sundaram, Dinesh < dinesh.sunda...@mastercard.com> wrote: > I want to keep both collections in sync always. This is really working > fine without any issue so far. My problem is pretty straight forward. > > I'm starting two solr instances on two servers using the below > command. I believe this command is for solrcloud mode. If so then I > have that shared replication handler config also in in my > _default/solrconfig.xml on one instance so that the slave instance > will synch with master. I don’t use zookeeper at all. Just replication > handler setting in solrconfig.xml. is this good for longtime? If not please > help me understand the issues. > > bin/solr start -cloud -p 8983 -noprompt > > > > Dinesh Sundaram > MBS Platform Engineering > > Mastercard > > > > -Original Message- > From: Erick Erickson [mailto:erickerick...@gmail.com] > Sent: Thursday, January 4, 2018 10:10 AM > To: solr-user <solr-user@lucene.apache.org> > Subject: Re: Solrcloud with Master/Slave > > Whoa. I don't think you should be doing this at all. This really > appears to be an XY problem. You're asking "how to do X" without > telling us what the problem you're trying to solve is (the Y). _Why_ > do you want to set things up this way? A one-time synchronization or > to keep both collections in sync? > > > Cross Data Center Replication (CDCR) is designed to keep two separate > collections in sync on an ongoing basis. > > If this is a one-time deal, you can manually issue a replication API > "fetchindex" command. What I'd do in that case is set up your > collection B with each shard having exactly one replica (i.e. a leader > and no followers). Do the fetch and verify that your new collection is > as you want it then ADDREPLICA to build out your redundancy. > > Best, > Erick > > On Thu, Jan 4, 2018 at 8:01 AM, Sundaram, Dinesh < > dinesh.sunda...@mastercard.com> wrote: > > Thanks Shawn for your prompt response. Assume I have solrcloud A > > server > with 1 node runs on 8983 port and solrcloud B server with 1 node runs > on 8983, here I want to synch up the collection between solrcloud A > and B using the below replication handler. Is this advisable to use at > the solrcloud B ? > > > > > > > > https://urldefense.proofpoint.com/v2/ > url?u=http-3A__solrcloudA-3A8983_solr_-24-257Bsolr.core. > name-257D_replication=DwIFaQ=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jm > CF6SP0bDlmMmY=gCFZFMR7y0gzhIBFz1lKTqHFMl-3R6gq7ojE0Eam2Eg= > qBCZxvmkOHW9jt8JM8dVSQJuulIJp3Xk2hXvC5bL7DM=xGP- > 8z2aGBFGrtjIbBMFB6f2cfE4bukyOctAVK_HkyI= > > 00:00:20 > > > > > > > > > > > > Dinesh Sundaram > > MBS Platform Engineering > > > > Mastercard > > > > > > > > -Original Message- > > From: Shawn Heisey [mailto:apa...@elyograg.org] > > Sent: Tuesday, January 2, 2018 5:33 PM > > To: solr-user@lucene.apache.org > > Subject: Re: Solrcloud with Master/Slave > > > > On 1/2/2018 3:32 PM, Sundaram, Dinesh wrote: > >> I have spun up single solrcloud node on 2 servers. > > > > This makes no sense. If you have two servers, then you probably > > have > more than a single node. > > > >> tried
RE: Solrcloud with Master/Slave
I want to keep both collections in sync always. This is really working fine without any issue so far. My problem is pretty straight forward. I'm starting two solr instances on two servers using the below command. I believe this command is for solrcloud mode. If so then I have that shared replication handler config also in in my _default/solrconfig.xml on one instance so that the slave instance will synch with master. I don’t use zookeeper at all. Just replication handler setting in solrconfig.xml. is this good for longtime? If not please help me understand the issues. bin/solr start -cloud -p 8983 -noprompt Dinesh Sundaram MBS Platform Engineering Mastercard -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Thursday, January 4, 2018 10:10 AM To: solr-user <solr-user@lucene.apache.org> Subject: Re: Solrcloud with Master/Slave Whoa. I don't think you should be doing this at all. This really appears to be an XY problem. You're asking "how to do X" without telling us what the problem you're trying to solve is (the Y). _Why_ do you want to set things up this way? A one-time synchronization or to keep both collections in sync? Cross Data Center Replication (CDCR) is designed to keep two separate collections in sync on an ongoing basis. If this is a one-time deal, you can manually issue a replication API "fetchindex" command. What I'd do in that case is set up your collection B with each shard having exactly one replica (i.e. a leader and no followers). Do the fetch and verify that your new collection is as you want it then ADDREPLICA to build out your redundancy. Best, Erick On Thu, Jan 4, 2018 at 8:01 AM, Sundaram, Dinesh <dinesh.sunda...@mastercard.com> wrote: > Thanks Shawn for your prompt response. Assume I have solrcloud A server with > 1 node runs on 8983 port and solrcloud B server with 1 node runs on 8983, > here I want to synch up the collection between solrcloud A and B using the > below replication handler. Is this advisable to use at the solrcloud B ? > > > > name="masterUrl">https://urldefense.proofpoint.com/v2/url?u=http-3A__solrcloudA-3A8983_solr_-24-257Bsolr.core.name-257D_replication=DwIFaQ=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY=gCFZFMR7y0gzhIBFz1lKTqHFMl-3R6gq7ojE0Eam2Eg=qBCZxvmkOHW9jt8JM8dVSQJuulIJp3Xk2hXvC5bL7DM=xGP-8z2aGBFGrtjIbBMFB6f2cfE4bukyOctAVK_HkyI= > 00:00:20 > > > > > > Dinesh Sundaram > MBS Platform Engineering > > Mastercard > > > > -Original Message- > From: Shawn Heisey [mailto:apa...@elyograg.org] > Sent: Tuesday, January 2, 2018 5:33 PM > To: solr-user@lucene.apache.org > Subject: Re: Solrcloud with Master/Slave > > On 1/2/2018 3:32 PM, Sundaram, Dinesh wrote: >> I have spun up single solrcloud node on 2 servers. > > This makes no sense. If you have two servers, then you probably have more > than a single node. > >> tried to synch up the data b/w those servers via zookeeper > > This is not done with zookeeper. SolrCloud should handle it automatically. > SolrCloud uses the zookeeper database to *coordinate* keeping machines in > sync, but it's Solr that does the work, not zookeeper. > > This makes even less sense when taken in context with the previous sentence. > If you only have a single node, then you can't possibly sync between them. > >> but didn’t work well due to out of memory issues, ensemble issues >> with multiple ports connectivity. So had to move to Master slave >> replication b/w those 2 solrcloud nodes. I couldn’t find any issues >> so far. Is this advisable? Because I’m wondering that looks like >> mixing up solrcloud and master/slave replication. > > If you're getting OOME problems, then whatever program threw the OOME most > likely needs more heap. Or you need to take steps to reduce the amount of > heap that's required. Note that this second option might not actually be > possible ... increasing the heap is probably the only option you have. Since > version 5.0, Solr has shipped with the default heap set to 512MB, which is > extremely small. Most users need to increase it. > > You can't mix master-slave replication and SolrCloud. SolrCloud takes over > the replication feature for its own purposes. Trying to mix these is going > to cause you problems. You may not run into the problems immediately, but it > is likely that you would run into a problem eventually. Data loss would be > possible. > > The latest versions of Solr have new SolrCloud replication types that closely > mimic the old master-slave replication. > > Perhaps you should start over and describe what you've actually seen -- > exactly what you've done and configured, and how the results dif
RE: Solrcloud with Master/Slave
Thanks Shawn for your prompt response. Assume I have solrcloud A server with 1
node runs on 8983 port and solrcloud B server with 1 node runs on 8983, here I
want to synch up the collection between solrcloud A and B using the below
replication handler. Is this advisable to use at the solrcloud B ?
http://solrcloudA:8983/solr/${solr.core.name}/replication
00:00:20
Dinesh Sundaram
MBS Platform Engineering
Mastercard
-Original Message-
From: Shawn Heisey [mailto:apa...@elyograg.org]
Sent: Tuesday, January 2, 2018 5:33 PM
To: solr-user@lucene.apache.org
Subject: Re: Solrcloud with Master/Slave
On 1/2/2018 3:32 PM, Sundaram, Dinesh wrote:
> I have spun up single solrcloud node on 2 servers.
This makes no sense. If you have two servers, then you probably have more than
a single node.
> tried to synch up the data b/w those servers via zookeeper
This is not done with zookeeper. SolrCloud should handle it automatically.
SolrCloud uses the zookeeper database to *coordinate* keeping machines in sync,
but it's Solr that does the work, not zookeeper.
This makes even less sense when taken in context with the previous sentence.
If you only have a single node, then you can't possibly sync between them.
> but didn’t work well due to out of memory issues, ensemble issues with
> multiple ports connectivity. So had to move to Master slave
> replication b/w those 2 solrcloud nodes. I couldn’t find any issues so
> far. Is this advisable? Because I’m wondering that looks like mixing
> up solrcloud and master/slave replication.
If you're getting OOME problems, then whatever program threw the OOME most
likely needs more heap. Or you need to take steps to reduce the amount of heap
that's required. Note that this second option might not actually be possible
... increasing the heap is probably the only option you have. Since version
5.0, Solr has shipped with the default heap set to 512MB, which is extremely
small. Most users need to increase it.
You can't mix master-slave replication and SolrCloud. SolrCloud takes over the
replication feature for its own purposes. Trying to mix these is going to
cause you problems. You may not run into the problems immediately, but it is
likely that you would run into a problem eventually. Data loss would be
possible.
The latest versions of Solr have new SolrCloud replication types that closely
mimic the old master-slave replication.
Perhaps you should start over and describe what you've actually seen -- exactly
what you've done and configured, and how the results differed from your
expectations. Precise commands entered will be helpful.
Thanks,
Shawn
CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the
use of the intended recipient and may contain information that is privileged,
confidential or exempt from disclosure under applicable law. If you are not the
intended recipient, any disclosure, distribution or other use of this e-mail
message or attachments is prohibited. If you have received this e-mail message
in error, please delete and notify the sender immediately. Thank you.
Solrcloud with Master/Slave
Hi, I have spun up single solrcloud node on 2 servers. tried to synch up the data b/w those servers via zookeeper but didn't work well due to out of memory issues, ensemble issues with multiple ports connectivity. So had to move to Master slave replication b/w those 2 solrcloud nodes. I couldn't find any issues so far. Is this advisable? Because I'm wondering that looks like mixing up solrcloud and master/slave replication. Dinesh Sundaram MBS Platform Engineering Mastercard [cid:image001.png@01D383E7.39FA10D0] CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.
RE: Solr ssl issue while creating collection
Thanks Erick for your valuable reply. Much Appreciated !!! Dinesh Sundaram MBS Platform Engineering Mastercard -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Friday, December 15, 2017 5:17 PM To: solr-user <solr-user@lucene.apache.org> Subject: Re: Solr ssl issue while creating collection No. ZooKeeper is an integral part of SolrCloud, without it you don't _have_ SolrCloud. Best, Erick On Fri, Dec 15, 2017 at 1:03 PM, Sundaram, Dinesh <dinesh.sunda...@mastercard.com> wrote: > Thanks again for your valuable reply. Yes that’s correct. Is there a way to > start solr alone without any embedded/external zookeeper in solrcloud mode? > > > Dinesh Sundaram > MBS Platform Engineering > > Mastercard > > > > -Original Message- > From: Shawn Heisey [mailto:apa...@elyograg.org] > Sent: Wednesday, December 13, 2017 4:54 PM > To: solr-user@lucene.apache.org > Subject: Re: Solr ssl issue while creating collection > > On 12/13/2017 3:16 PM, Sundaram, Dinesh wrote: >> Thanks Shawn for your input, Is this errors specific only for zookeeper >> operations? If so is there any way to turn off default zookeeper which runs >> on 9983? > > If you don't want to start the embedded zookeeper, then you want to be sure > that you have a zkHost defined which lists all of the hosts in your external > ensemble. You can either define ZK_HOST in the include script, or use the -z > option when starting Solr manually. When Solr is provided with information > about ZK hosts, it does NOT start the embedded ZK. > > The exceptions you're seeing have nothing to do with zookeeper. The latest > exception you mentioned is caused by one SolrCloud instance sending HTTPS > requests to another SolrCloud instance, and failing to validate SSL because > the hostname doesn't match the info in the certificate. > > Thanks, > Shawn > > > CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for > the use of the intended recipient and may contain information that is > privileged, confidential or exempt from disclosure under applicable law. If > you are not the intended recipient, any disclosure, distribution or other use > of this e-mail message or attachments is prohibited. If you have received > this e-mail message in error, please delete and notify the sender > immediately. Thank you.
RE: Solr ssl issue while creating collection
Thanks again for your valuable reply. Yes that’s correct. Is there a way to start solr alone without any embedded/external zookeeper in solrcloud mode? Dinesh Sundaram MBS Platform Engineering Mastercard -Original Message- From: Shawn Heisey [mailto:apa...@elyograg.org] Sent: Wednesday, December 13, 2017 4:54 PM To: solr-user@lucene.apache.org Subject: Re: Solr ssl issue while creating collection On 12/13/2017 3:16 PM, Sundaram, Dinesh wrote: > Thanks Shawn for your input, Is this errors specific only for zookeeper > operations? If so is there any way to turn off default zookeeper which runs > on 9983? If you don't want to start the embedded zookeeper, then you want to be sure that you have a zkHost defined which lists all of the hosts in your external ensemble. You can either define ZK_HOST in the include script, or use the -z option when starting Solr manually. When Solr is provided with information about ZK hosts, it does NOT start the embedded ZK. The exceptions you're seeing have nothing to do with zookeeper. The latest exception you mentioned is caused by one SolrCloud instance sending HTTPS requests to another SolrCloud instance, and failing to validate SSL because the hostname doesn't match the info in the certificate. Thanks, Shawn CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.
RE: Solr ssl issue while creating collection
Thanks Shawn for your input, Is this errors specific only for zookeeper operations? If so is there any way to turn off default zookeeper which runs on 9983? Dinesh Sundaram MBS Platform Engineering Mastercard -Original Message- From: Shawn Heisey [mailto:apa...@elyograg.org] Sent: Wednesday, December 13, 2017 11:38 AM To: solr-user@lucene.apache.org Subject: Re: Solr ssl issue while creating collection On 12/13/2017 10:06 AM, Sundaram, Dinesh wrote: > Thanks Shawn, this helps. Now getting the below exception, is there any way > to avoid verifying this? > > 2017-12-13 17:00:39.239 DEBUG > (httpShardExecutor-4-thread-1-processing-n:xx.xx.xx.xx:8983_solr > [https://urldefense.proofpoint.com/v2/url?u=https-3Axx.xx.xx.xx-3A8983__solr=DwIDaQ=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY=gCFZFMR7y0gzhIBFz1lKTqHFMl-3R6gq7ojE0Eam2Eg=v4DznkLF4VBvrVleiFON0I41uu_NPGd1TpVYs3q0Hro=eqDSyAa-0UCXm_IT2YoWaZDjMb5zM5Uv8-9Zcidjlec=] > > https://urldefense.proofpoint.com/v2/url?u=https-3Axx.xx.xx.xx-3A8983__solr=DwIDaQ=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY=gCFZFMR7y0gzhIBFz1lKTqHFMl-3R6gq7ojE0Eam2Eg=v4DznkLF4VBvrVleiFON0I41uu_NPGd1TpVYs3q0Hro=eqDSyAa-0UCXm_IT2YoWaZDjMb5zM5Uv8-9Zcidjlec=) > [ ] o.a.h.c.s.DefaultHostnameVerifier Certificate for > doesn't match common name of the certificate subject: xx.xx.xx.xx.com > javax.net.ssl.SSLPeerUnverifiedException: Certificate for > doesn't match common name of the certificate subject: > xx.xx.xx.xx.com If you're running 6.x, then you can disable the hostname verification. But if you're running 7.x, there's a bug that breaks it: https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_SOLR-2D9304=DwIDaQ=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY=gCFZFMR7y0gzhIBFz1lKTqHFMl-3R6gq7ojE0Eam2Eg=v4DznkLF4VBvrVleiFON0I41uu_NPGd1TpVYs3q0Hro=mX_wS19NYYqBsWUI3qCXAXBbY-3p8Vjkzq4K3BFfgdk= There's a patch on the issue, but it hasn't been tested, so I have no idea whether it works. Even if it works, the patch is incomplete because it doesn't have a test to verify the problem doesn't happen again. An alternate idea would be to add all the possible hostnames to the certificate you're using, and make sure the trust stores are valid, so all of the cert verification will work. Thanks, Shawn CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.
RE: Solr ssl issue while creating collection
Thanks Shawn, this helps. Now getting the below exception, is there any way to avoid verifying this? 2017-12-13 17:00:39.239 DEBUG (httpShardExecutor-4-thread-1-processing-n:xx.xx.xx.xx:8983_solr [https:xx.xx.xx.xx:8983//solr] https:xx.xx.xx.xx:8983//solr) [ ] o.a.h.c.s.DefaultHostnameVerifier Certificate for doesn't match common name of the certificate subject: xx.xx.xx.xx.com javax.net.ssl.SSLPeerUnverifiedException: Certificate for doesn't match common name of the certificate subject: xx.xx.xx.xx.com 2017-12-13 17:00:39.242 ERROR (OverseerThreadFactory-8-thread-1-processing-n:xx.xx.xx.xx:8983_solr) [ ] o.a.s.c.OverseerCollectionMessageHandler Error from shard: https://xx.xx.xx.xx:8983/solr org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: https://xx.xx.xx.xx:8983/solr at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:640) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:172) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: javax.net.ssl.SSLPeerUnverifiedException: Certificate for doesn't match any of the subject alternative names: [] Dinesh Sundaram MBS Platform Engineering Mastercard -Original Message- From: Shawn Heisey [mailto:apa...@elyograg.org] Sent: Monday, December 11, 2017 2:26 PM To: solr-user@lucene.apache.org Subject: Re: Solr ssl issue while creating collection On 12/11/2017 12:24 PM, Sundaram, Dinesh wrote: > 1. Configure SSL > using > https://urldefense.proofpoint.com/v2/url?u=https-3A__lucene.apache.org > _solr_guide_7-5F1_enabling-2Dssl.html=DwIDaQ=uc5ZRXl8dGLM1RMQwf7xT > CjRqXF0jmCF6SP0bDlmMmY=gCFZFMR7y0gzhIBFz1lKTqHFMl-3R6gq7ojE0Eam2Eg > =kX8SMKw_W4qlgQyvl3p8pLrhYorEW4_wklVchKw6jAA=Gz_ER-vMMwpE5j1YpqIrjnf > _P3SM7uPI-kpjGdeATR8= > > 2. Restart solr > 3. Validate solr with https url > https://urldefense.proofpoint.com/v2/url?u=https-3A__localhost-3A8983_ > solr=DwIDaQ=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY=gCFZFMR7 > y0gzhIBFz1lKTqHFMl-3R6gq7ojE0Eam2Eg=kX8SMKw_W4qlgQyvl3p8pLrhYorEW4_w > klVchKw6jAA=EJ68RQ28Gn6vNdedX5n0hue_hgqlEWR9jFWoEbkt7J4= - works > fine 4. Create a collection > https://urldefense.proofpoint.com/v2/url?u=https-3A__localhost-3A8983_ > solr_-23_-7Ecollections=DwIDaQ=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP > 0bDlmMmY=gCFZFMR7y0gzhIBFz1lKTqHFMl-3R6gq7ojE0Eam2Eg=kX8SMKw_W4qlg > Qyvl3p8pLrhYorEW4_wklVchKw6jAA=weJY5eOZccSQqlLFr5CAH7PEyWPL1fb5VaWKG > AjYAJs= > <https://urldefense.proofpoint.com/v2/url?u=https-3A__localhost-3A8983 > _solr_-23_-257Ecollections=DwIDaQ=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF > 6SP0bDlmMmY=gCFZFMR7y0gzhIBFz1lKTqHFMl-3R6gq7ojE0Eam2Eg=kX8SMKw_W4 > qlgQyvl3p8pLrhYorEW4_wklVchKw6jAA=CdjOnW9WrZwGNv5Rr3kEke61pipUE8kMVA > 9DzaYluRU=> > 5. here is the response : > Connection to Solr lost > Please check the Solr instance. > 6.Server solr.log: here notice the replica call goes to http port > instead of https > > 2017-12-11 11:52:27.929 ERROR > (OverseerThreadFactory-8-thread-1-processing-n:localhost:8983_solr) [ > ] o.a.s.c.OverseerCollectionMessageHandler Error from > shard: > https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8983_s > olr=DwIDaQ=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY=gCFZFMR7y > 0gzhIBFz1lKTqHFMl-3R6gq7ojE0Eam2Eg=kX8SMKw_W4qlgQyvl3p8pLrhYorEW4_wk > lVchKw6jAA=MjaZgIhWcEaKn00NFazu0zGn3HFKeSuYOlhyKe9RJMs= > This acts like either you did not set the urlScheme cluster property in zookeeper to https, or that you did not restart your Solr instances after making that change. Setting the property is described on the page you referenced in the "SSL with SolrCloud" section. Note that it also appears your Solr instances have registered themselves with the "localhost" name instead of an actual IP address or a "real" hostname. This is going to be a problem if you ever run more than
RE: Solr ssl issue while creating collection
Hi, How do I change the protocol to https everywhere including replica. NOTE: I have just only one node 8983. started solr using this command. bin/solr start -cloud -p 8983 -noprompt 1. Configure SSL using https://lucene.apache.org/solr/guide/7_1/enabling-ssl.html 2. Restart solr 3. Validate solr with https url https://localhost:8983/solr - works fine 4. Create a collection https://localhost:8983/solr/#/~collections 5. here is the response : Connection to Solr lost Please check the Solr instance. 6.Server solr.log: here notice the replica call goes to http port instead of https 2017-12-11 11:52:27.929 ERROR (OverseerThreadFactory-8-thread-1-processing-n:localhost:8983_solr) [ ] o.a.s.c.OverseerCollectionMessageHandler Error from shard: http://localhost:8983/solr org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://localhost:8983/solr at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:640) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:172) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: org.apache.http.client.ClientProtocolException at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:187) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:525) ... 12 more Caused by: org.apache.http.ProtocolException: The server failed to respond with a valid HTTP response at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:149) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163) at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) at org.apache.solr.util.stats.InstrumentedHttpRequestExecutor.execute(InstrumentedHttpRequestExecutor.java:118) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) ... 15 more Dinesh Sundaram MBS Platform Engineering Mastercard [cid:image002.png@01D37287.37BC38F0] CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.
Solr ssl issue while creating collection
Hi, How do I change the protocol to https everywhere including replica. NOTE: I have just only one node 8983. started solr using this command. bin/solr start -cloud -p 8983 -noprompt 1. Configure SSL using https://lucene.apache.org/solr/guide/7_1/enabling-ssl.html 2. Restart solr 3. Validate solr with https url https://localhost:8983/solr - works fine 4. Create a collection https://localhost:8983/solr/#/~collections 5. here is the response : Connection to Solr lost Please check the Solr instance. 6.Server solr.log: here notice the replica call goes to http port instead of https 2017-12-11 11:52:27.929 ERROR (OverseerThreadFactory-8-thread-1-processing-n:localhost:8983_solr) [ ] o.a.s.c.OverseerCollectionMessageHandler Error from shard: http://localhost:8983/solr org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://localhost:8983/solr at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:640) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:172) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: org.apache.http.client.ClientProtocolException at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:187) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:525) ... 12 more Caused by: org.apache.http.ProtocolException: The server failed to respond with a valid HTTP response at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:149) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163) at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) at org.apache.solr.util.stats.InstrumentedHttpRequestExecutor.execute(InstrumentedHttpRequestExecutor.java:118) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) ... 15 more Dinesh Sundaram MBS Platform Engineering Mastercard [cid:image001.png@01D37283.5B72AA80] CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.
