lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Brucher <>
Subject AW: System collection - lazy loading mechanism not working for custom UpdateProcessors?
Date Thu, 26 Apr 2018 13:31:12 GMT
Maybe I have found a more accurate example constellation to reproduce the error.

By default the .system-collection is created with 1 shard and 1 replica.

In this constellation, everything works as expected and no matter how often I try to restart
the Solr Cloud,

the error "SolrException: Blob loading failed: .no active replica available for .system collection"
is never thrown...


But once I started to add one more replica to the .system collection things are messing up!


With this setup, I'm not able to start the Solr Cloud server without any error:


Sometimes one or two collections are Active but most of the time all collections are permanently
marked as Down…


Are there any restrictions how to setup the .system collection?


-----Ursprüngliche Nachricht-----
Von: Johannes Brucher []
Gesendet: Mittwoch, 25. April 2018 10:57
Betreff: System collection - lazy loading mechanism not working for custom UpdateProcessors?

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?

Pls let me know if it helps sharing my configuration!

Many thanks,


  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message