-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SAI-4837 : In-memory synthetic SolrCore
for QA node
#181
Conversation
@@ -1175,7 +1178,7 @@ private SolrCore( | |||
initSearcher(prev); | |||
|
|||
// Initialize the RestManager | |||
restManager = initRestManager(); | |||
restManager = isSynthetic() ? new RestManager() : initRestManager(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how this is helping here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was a quick prototype so I basically quickly handle NPEs when i ran into them. 😁 I put this one is so it will init w/o throwing exceptions.
I believe for a better implementation, we will need to understand all the init happened in the SolrCore
, there's a fair chance that we can simply bypass most of the init routine for a synthetic core (rest manager, event handler/listener, plugin, searcher etc), as synthetic core does not do any real searching, it simply relays it to the actual data node
@@ -66,6 +66,12 @@ public ZkConfigSetService(SolrZkClient zkClient) { | |||
this.zkClient = zkClient; | |||
} | |||
|
|||
@Override | |||
protected SolrResourceLoader createConfigSetResourceLoader(CoreDescriptor cd, String configSetName) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to understand better, why we need to override here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For synthetic core, the resource loader only needs to load the configset resource, it would have no access to collection specific resource - which is non existent for this new synthetic core/collection, since it does not even exists in ZK.
There are several implementation of ConfigSetService
, and for prototype purpose, we only support this for ZkConfigSetSrvice
e); | ||
} | ||
} | ||
coreContainer.registerCore(syntheticCoreDescriptor, syntheticCore, false, false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not publishing into zk? nice!
Also pushed some fixes, so the unit test case would pass |
@chatman @noblepaul . I would ❤️ to gather some thoughts from you both! Mostly on the idea, as for the implementation details, we might need to further cleanup the logic if we decide to move forward. The synthetic collection was created to avoid excess proxy cores created in 8.x AFAIK, I'm wondering if this proposal could address such concern without raising new ones? |
The biggest challenge is pushing this upstream. Making changes to |
5b7b8c1
to
0d2b744
Compare
That's a good point, totally agree! Even if we do not upstream this, minimizing changes to I have added some minor changes and javadoc to my implementation. The change to |
SolrCore
for QA node
SolrCore
for QA nodeSolrCore
for QA node
I like the fact that the changes to 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
// core's collection from ZK | ||
// which synthetic core is not registered in ZK. | ||
// We do not expect RestManager ops on Coordinator Nodes | ||
return new RestManager(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what restManager enables?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, there is only a tiny feature called "managed resources" being powered by RestManager. It's not even reuired
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
(Thanks @patsonluk , please make sure QA logs are ok (collname, etc), though I don't feel any change in that area)
Ensure only one synthetic core created per config set
Good call on I have committed some fixes:
Would you mind to review the changes in a32a2ac . Many thanks again!!! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (Thanks @patsonluk )
Should open the registered core on first synthetic core creation since it is a getCore op
SolrCore
for QA nodeSolrCore
for QA node
* Experimental QA core as proxy in memory * Experimental QA core as proxy in memory * Experimental QA core as proxy in memory * ./gradlew tidy * Comment out portion that checks for synthetic collection/core existence * Fixes watches and test cases * Refactoring to avoid modifying existing method modifiers * Cleanup * Some refactoring to minimize changes to SolrCore * javadoc * ./gradlew tidy * code cleanup * code cleanup * Fix resource loader issue if configSetName is null * ./gradlew tidy * Fixed issue with incorrect collection name in context Ensure only one synthetic core created per config set * ./gradlew tidy * Correctly use <config set>_core as synthetic core name for clarity Should open the registered core on first synthetic core creation since it is a getCore op * ./gradlew tidy * Fixed issue with incorrect collection name in context
Description
A prototype to attempt using an in-memory
SyntheticSolrCore
similar to theSolrCoreProxy
in our Solr 8.8The synthetic collection/replica introduced in Solr 9 added the collection folder to physically disk and also the zookeeper
solr/collections
.However, it seems that what we essentially need is a
SolrCore
in the memory for each config set, which might be able to simply register it against theCoreContainer
without actually registering to ZK.Solution
Introduced
SyntheticSolrCore
which extendsSolrCore
,SyntheticSolrCore
is only used in Coordinator node to support a subset ofSolrCore
functionalities required by Coordinator operations such as aggregating and writing out response and providing configset info.Such core is only registered to the
CoreContainer
but is no longer register itself to zookeeper.Take note that to minimize code changes, there will still be snapshot/index data directory written to the QA node. We could have overridden
initSnapshotMetaDataManager
andinitIndex
to be no-op to avoid creating them, however, there is currently other code (and possibly future code too) that might rely on the existence of those values. It is safer to just keep them as is.The data folder for the synthetic core would NOT be loaded on QA node start-up as there's no
core.properties
in such directory. This is because instead of going throughCoreContainer#create
for such synthetic core, it's usingSyntheticSolrCore#createAndRegisterCore
, which bypasscore.properties
creation and zk registrationTests
TestCoordinatorRole
passed, which provides good integration test coverage to ensureSyntheticSolrCore
is working as expectedi. Basic query and restart tests from QA node
ii. Shard split and moves and ensure QA node can distribute the requests to new shards
iii. collection name is logged correctly
iv. test on multiple collections to ensure that query work for them all, and the synthetic core should only be created once (by observing the log message
Loading synthetic core for config set...
)