[ https://issues.apache.org/jira/browse/SOLR-12294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487455#comment-16487455 ]
Noble Paul commented on SOLR-12294: ----------------------------------- cloud can use {{updateProcessorChain}} or {{updateRequestProcessorChain}} this is an implementation detail about the dynamic class loading > System collection - Lazy loading mechanism not working for custom > UpdateProcessors > ---------------------------------------------------------------------------------- > > Key: SOLR-12294 > URL: https://issues.apache.org/jira/browse/SOLR-12294 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors > Affects Versions: 7.3 > Reporter: Johannes Brucher > Assignee: Noble Paul > Priority: Critical > Attachments: no_active_replica_available.png, schema.xml, > solrconfig.xml, update-processor-0.0.1-SNAPSHOT.jar > > > Hi all, > I'm facing an issue regarding custom code inside a .system-collection and > starting up a Solr Cloud cluster. > I thought, like its stated in the documentation, that in case using the > .system collection custom code is lazy loaded, because it can happen that a > collection that uses custom code is initialized before the .system collection > is up and running. > I did all the necessary configuration and while debugging, I can see that the > custom code is wrapped via a PluginBag$LazyPluginHolder. So far its seems > good, but I still get Exceptions when starting the Solr Cloud with the > following errors: > SolrException: Blob loading failed: .no active replica available for .system > collection... > In my case I'm using custom code for a couple of UpdateProcessors. So it > seems, that this lazy mechanism is not working well for UpdateProcessors. > Inside the calzz LazyPluginHolder the comment says: > "A class that loads plugins Lazily. When the get() method is invoked the > Plugin is initialized and returned." > When a core is initialized and you have a custom UpdateProcessor, the > get-method is invoked directly and the lazy loading mechanism tries to get > the custom class from the MemClassLoader, but in most scenarios the system > collection is not up and the above Exception is thrown... > So maybe it’s the case that for UpdateProcessors while initializing a core, > the routine is not implemented optimal for the lazy loading mechanism? > > Here are the steps to reproduce the issue: > # Unpack solr 7.3.0 > 1.1 Add SOLR_OPTS="$SOLR_OPTS -Denable.runtime.lib=true" to solr.in.sh > 1.2 Start Solr with -c option > # Setup .system collection: > 2.1 Upload custom test jar --> curl -X POST -H 'Content-Type: > application/octet-stream' --data-binary @<path to custom > jar>/update-processor-0.0.1-SNAPSHOT.jar http://<your > solr>/solr/.system/blob/test_blob > 2.2 Alter maxShardsPerNode --> > .../admin/collections?action=MODIFYCOLLECTION&collection=.system&maxShardsPerNode=2 > 2.2 Add Replica to .system collection --> > .../admin/collections?action=ADDREPLICA&collection=.system&shard=shard1 > # Setup test collection: > 3.1 Upload test conf to ZK --> ./zkcli.sh -zkhost <your ZK host> -cmd > upconfig -confdir <your config dir> -confname test_conf > 3.2 Create a test1 collection with commented UP-chain inside solrconfig.xml > via Admin UI > 3.3 Add blob to test collection --> curl http://<your > Solr>/solr/test1/config -H 'Content-type:application/json' -d > '\{"add-runtimelib": { "name":"test_blob", "version":1 }}' > 3.4 Uncomment the UP-chain and upload test-conf again --> ./zkcli.sh -zkhost > <your ZK host> -cmd upconfig -confdir <your config dir> -confname test_conf > 3.5 Reload test1 collection > 3.6 Everything should work as expected now (no erros are shown) > # Restart SOLR > 4.1 Now you can see: SolrException: Blob loading failed: No active replica > available for .system collection > Expected: The lazy loading mechanism should work for UpdateProcessors inside > core init routine, but it isn't due to above Exception. > Sometimes you are lucky and the test1 collection will be initialize after the > .system collection. But in ~90% of the time this isn't the case... > Let me know if you need further details here, > > Johannes -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org