[
https://issues.apache.org/jira/browse/SOLR-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249061#comment-17249061
]
Joel Bernstein commented on SOLR-12182:
---------------------------------------
Just posted on different ticket but I'll post here as well. Currently I'm not
able to create collections from a branch_8x build. Here are the steps to
reproduce:
Pull branch_8x.
{code}
ant server
bin/solr create -c test -s 1 -d _default
{code}
Gives this error:
{code}
org.apache.solr.client.solrj.SolrServerException: IOException occurred when
talking to server at: https://10.0.0.238:8983/solr
at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:695)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:266)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1290)
at
org.apache.solr.handler.component.HttpShardHandlerFactory$1.request(HttpShardHandlerFactory.java:169)
at
org.apache.solr.handler.component.ShardRequestor.call(ShardRequestor.java:130)
at
org.apache.solr.handler.component.ShardRequestor.call(ShardRequestor.java:41)
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:180)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLException: Unsupported or unrecognized SSL message
at
sun.security.ssl.SSLSocketInputRecord.handleUnknownRecord(SSLSocketInputRecord.java:448)
at sun.security.ssl.SSLSocketInputRecord.decode(SS
{code}
> Can not switch urlScheme in 7x if there are any cores in the cluster
> --------------------------------------------------------------------
>
> Key: SOLR-12182
> URL: https://issues.apache.org/jira/browse/SOLR-12182
> Project: Solr
> Issue Type: Bug
> Affects Versions: 7.0, 7.1, 7.2
> Reporter: Anshum Gupta
> Assignee: Timothy Potter
> Priority: Major
> Fix For: 8.8, master (9.0)
>
> Attachments: SOLR-12182.patch, SOLR-12182_20200423.patch
>
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> I was trying to enable TLS on a cluster that was already in use i.e. had
> existing collections and ended up with down cores, that wouldn't come up and
> the following core init errors in the logs:
> *org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> replica with coreNodeName core_node4 exists but with a different name or
> base_url.*
> What is happening here is that the core/replica is defined in the
> clusterstate with the urlScheme as part of it's base URL e.g.
> *"base_url":"http:hostname:port/solr"*.
> Switching the urlScheme in Solr breaks this convention as the host now uses
> HTTPS instead.
> Actually, I ran into this with an older version because I was running with
> *legacyCloud=false* and then realized that we switched that to the default
> behavior only in 7x i.e while most users did not hit this issue with older
> versions, unless they overrode the legacyCloud value explicitly, users
> running 7x are bound to run into this more often.
> Switching the value of legacyCloud to true, bouncing the cluster so that the
> clusterstate gets flushed, and then setting it back to false is a workaround
> but a bit risky one if you don't know if you have any old cores lying around.
> Ideally, I think we shouldn't prepend the urlScheme to the base_url value and
> use the urlScheme on the fly to construct it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
