[ 
https://issues.apache.org/jira/browse/SOLR-18055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18079731#comment-18079731
 ] 

ASF subversion and git services commented on SOLR-18055:
--------------------------------------------------------

Commit b1c386fd8b38c10a114ec56f0a3b608e35819750 in solr's branch 
refs/heads/main from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=b1c386fd8b3 ]

SOLR-18055: Fix test to prevent suite failures due to object (and thread) leaks 
when SSL is randomized

In the prior code the assumptions thrown by the helper methods would prevent 
the SolrZkClient (and all associated zk threads) from being closed

this change also ensures that the testUrlSchemeWithSystemProperties (which is 
designed to support ssl) is not skipped if the helpers that don't work with ssl 
are skipped


> Use SOLR_SSL_ENABLED to auto-set urlScheme appropriately
> --------------------------------------------------------
>
>                 Key: SOLR-18055
>                 URL: https://issues.apache.org/jira/browse/SOLR-18055
>             Project: Solr
>          Issue Type: Improvement
>          Components: security
>            Reporter: David Smiley
>            Priority: Major
>              Labels: newdev, pull-request-available
>          Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> A user uses SOLR_SSL_ENABLED to enable https / SSL.  It ought to be enough 
> but today it isn't.  For standalone mode, the solr.xml 
> httpShardHandlerFactory has a urlScheme to manually set.  I propose it need 
> not; that component can examine solr.ssl.enabled prop to choose between http 
> and https as a default.  For SolrCloud, ZkStateReader.getBaseUrlForNodeName 
> can do similarly, as the default if the urlScheme cluster property isn't set. 
>  CloudSolrClient can do the same if someone sets the system property.  Thus a 
> SolrCloud user need not feel compelled to set the urlScheme in a cluster 
> property, which is an annoying step.  That might eventually be deprecated.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to