You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Johannes Brucher <Jo...@shi-gmbh.com> on 2018/04/25 08:56:41 UTC

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,

Johannes



AW: System collection - lazy loading mechanism not working for custom UpdateProcessors?

Posted by Johannes Brucher <Jo...@shi-gmbh.com>.
Ty Shawn,

I’m trying to use JustPaste.it to share my screenshots…


Hi all,

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 if you using just one node.

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...

https://justpaste.it/685gf



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:

https://justpaste.it/4t66c



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

Here are the Exceptions I’m constantly getting:

https://justpaste.it/5ziem


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





Johannes


-----Ursprüngliche Nachricht-----
Von: Johannes Brucher [mailto:Johannes.Brucher@shi-gmbh.com]
Gesendet: Mittwoch, 25. April 2018 10:57
An: solr-user@lucene.apache.org<ma...@lucene.apache.org>
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,



Johannes





Re: AW: System collection - lazy loading mechanism not working for custom UpdateProcessors?

Posted by Shawn Heisey <ap...@elyograg.org>.
On 4/26/2018 7:31 AM, Johannes Brucher wrote:
>
> 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.
>

None of your screenshots have made it to the list. Attachments are 
almost always stripped by the mailing list software.

You will need to use a paste website, and/or a file sharing site, to 
share that kind of content on the mailing list.

Thanks,
Shawn


AW: System collection - lazy loading mechanism not working for custom UpdateProcessors?

Posted by Johannes Brucher <Jo...@shi-gmbh.com>.
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...



[cid:image006.jpg@01D3DD73.9B783400]





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

[cid:image007.jpg@01D3DD73.9B783400]



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



[cid:image008.jpg@01D3DD73.9B783400]



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



[cid:image012.jpg@01D3DD73.9B783400]

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





Johannes


-----Ursprüngliche Nachricht-----
Von: Johannes Brucher [mailto:Johannes.Brucher@shi-gmbh.com]
Gesendet: Mittwoch, 25. April 2018 10:57
An: solr-user@lucene.apache.org
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,



Johannes