* Remove SRL.listConfigDir (unused)
* Remove SRL.getDataDir
* Remove SRL.getCoreName
* Remove SRL.getCoreProperties
XmlConfigFile needs to be passed in the substitutableProperties
IndexSchema needs to be passed in the substitutableProperties
Remove redundant Properties from CoreContainer constructors
* Remove SRL.newAdminHandlerInstance (unused)
* Remove SRL.openSchema and openConfig
* Avoid SRL.getConfigDir
Also harmonized similar initialization logic between DIH Tika processor & ExtractingRequestHandler.
* Ensure SRL.addToClassLoader and reloadLuceneSPI are called at most once
Don't auto-load "lib" in constructor; wrong place for this logic.
* Avoid SRL.getInstancePath
Added SolrCore.getInstancePath instead
Use CoreContainer.getSolrHome instead
NodeConfig should track solrHome separate from SolrResourceLoader
* Simplify some SolrCore constructors
* Move locateSolrHome to new SolrPaths
* Move "User Files" stuff to SolrPaths
* Create properties for PublicKeyHandler to read existing keys from disk
* Move pregenerated keys from core/test-files to test-framework
* Update tests to use existing keys instead of new keys each run
SOLR-13996: Refactor HttpShardHandler.prepDistributed method into smaller pieces
This commit introduces an interface named ReplicaSource which is marked as experimental. It has two sub-classes named CloudReplicaSource (for solr cloud) and LegacyReplicaSource for non-cloud clusters. The prepDistributed method now calls out to these sub-classes depending on whether the cluster is running on cloud mode or not.
* Use Caffeine impl and weak values (to the schema). Previously the cache never evicted!
* now populating the configSet name from ZK into CloudDescriptor when CloudDescriptor is loaded
* actual schema name needs to be deterministic now; fallback from non-existent managed-schema to schema.xml will thwart this cache
* a test conf/core.properties wasn't actually used and became a problem in it's weird location after I refactored some logic
Jetty 9.4.16.v20190411 and up introduced separate
client and server SslContextFactory implementations.
This split requires the proper use of of
SslContextFactory in clients and server configs.
This fixes the following
* SSL with SOLR_SSL_NEED_CLIENT_AUTH not working since v8.2.0
* Http2SolrClient SSL not working in branch_8x
Signed-off-by: Kevin Risden <krisden@apache.org>
Solr tests now have a similar policy to Lucene, loopback use only. If a
test tries to resolve or connect to the internet, it will get SecurityException.
Some solr tests explicitly try to talk to dead nodes with real
networking. This is not good and asking for trouble, but use low loopback port numbers instead of
multicast addresses. The idea is that it fails faster. Move these to
constants so that stuff isn't copy-pasted everywhere, in case we have to
do something different later.
This removes the Solr security manager hacks
for Hadoop. It does so by:
* Using a fake group mapping class instead of ShellGroupMapping
* Copies a few Hadoop classes and modifies them for tests with no Shell
* Nulls out some of the static variables in the tests
The Hadoop files were copied from Apache Hadoop 3.2.0
and copied to the test package to be only picked up
during tests. They were modified to remove the need to
shell out for access. The assumption is that these
HDFS integration tests only run on Unix based systems
and therefore Windows compatibility was removed in some
of the modified classes. The long term goal is to remove
these custom Hadoop classes. All the copied classes are
in the org.apache.hadoop package.
Signed-off-by: Kevin Risden <krisden@apache.org>
This groundwork commit allows tests to randomize request content-type
more flexibly. This will be taken advantage of by subsequent commits.
Co-Authored-By: Thomas Woeckinger
Closes: #755
* Refactor existing work around in BasicAuthIntegrationTest up into SolrCloudAuthTestCase for re-use in JWTAuthPluginIntegrationTest
* Simplify BasicAuthOnSingleNodeTest and PKIAuthenticationIntegrationTest to use their existing (static) security settings on creation of MiniSolrCloud. Since they no longer modify security.json once the nodes are alive, the issue no longer affects them
* SOLR-13565: initial commit
* SOLR-13565: updated with testcase
* SOLR-13565: removed unused methods
* SOLR-13565: better logging
* SOLR-13565: disable SSL
* SOLR-13565: more tests
* SOLR-13565: syncing with master
* SOLR-13565: fixing tests
* SOLR-13565: fixing tests
* SOLR-13534: Fix test
Remove buggy 'port roulette' code that can easily fail if OS gives the selected port to a different process just before creating the server
Use jetty's built in support for listining on an OS selected port instead
Also increase timeouts to better account for slow/heavily loaded (ie:jenkins) VMs where SolrCore reloading may take longer then 10 seconds
* SOLR-13565: set proper permission name
* SOLR-13565: syncing with master
* SOLR-13565: syncing with master
* SOLR-13565: removed accidental change
* SOLR-13565: removed accidental change
* SOLR-13565: removed accidental change
* SOLR-13565: more tests
* SOLR-13565: Tests with key signing tests
* SOLR-13565: fixing concurrency issues in tests
* SOLR-13565: add tests with 512 bit RSA
* SOLR-13565: fixing concurrency issues
* SOLR-13565: remove unused code
* When ramPerThreadHardLimitMB is not specified, then Lucene's
default value 1945 is used. The specified value should be
greater than 0 and less than 2048MB
This reverts commit 6d6f14d391.
Reason for revert: after doing more testing I realized there are tests I overlooked which can (with randomized SSL usage) trigger NullPointerException
(or other related failures) in After/AfterClass due assumptions about cleanup that isn't actaully neccessary due to the AssumptionFailure
that may occur during Before/BeforeClass
This specific commit affects all points in the casebase where the argument of a StringBuilder.append() call is itself a regular String concatenation.
This defeats the purpose of using StringBuilder and also introduces an extra alloction.
These changes should avoid that.
ant tests have run, succeeded on local machine.
Removing test files from the changes.
Another suggested rework.
When performing an async CREATE requests, responses to internal requests are also included inside the "success" or "failed" elements of the general response. This will make the operation cleanup in case of failure, the same way as we do when the request is synchronous.
Solr 7.5 enabled autoscaling based replica placement by default but in the absence of default cluster policies, autoscaling can place more than 1 replica of the same shard on the same node. Also, the maxShardsPerNode and createNodeSet was not respected. Due to these reasons, this issue reverts the default replica placement policy to the 'legacy' assignment policy that was the default until Solr 7.4.