Unfortunately, I am still on legacy mode and not cloud mode. So, I can't take advantage of this feature :(
In the meantime, I have implemented the Solr plugin and it is working as expected but the only issue is that it needs to be called in the context of some core. I wonder if we can reference cores with numbers? e.g. /solr/0/my/api/call instead of /solr/<some_core_name>/my/api/call where - refers to first core in some sense (say alphabetical) That would alleviate the issue at least a bit because I don't need to know the name of any particular core to get some node level info. On Wed, Nov 16, 2022 at 7:03 AM Charlie Hull < ch...@opensourceconnections.com> wrote: > Once you figure this out it would be awesome if you could write up what > you did - a blog would be a fantastic resource for people writing > plugins in the future. > > Best > > Charlie > > On 16/11/2022 11:52, Jan Høydahl wrote: > > Yes > > > > Seehttps:// > solr.apache.org/guide/solr/latest/configuration-guide/cluster-plugins.html > for the docs. > > > > Jan > > > >> 16. nov. 2022 kl. 00:43 skrev gnandre<arnoldbron...@gmail.com>: > >> > >> Also, is this supported only in SolrCloud mode? > >> > >> On Tue, Nov 15, 2022 at 6:42 PM gnandre<arnoldbron...@gmail.com> > wrote: > >> > >>> Thanks, Ishan. Is this available only in Solr 8.6+? I am using 8.5.0 :( > >>> > >>> On Tue, Nov 15, 2022 at 2:19 PM Ishan Chattopadhyaya < > >>> ichattopadhy...@gmail.com> wrote: > >>> > >>>> https://issues.apache.org/jira/browse/SOLR-14404 > >>>> > >>>> On Wed, Nov 16, 2022 at 12:46 AM Ishan Chattopadhyaya < > >>>> ichattopadhy...@gmail.com> wrote: > >>>> > >>>>> Here's a core container level plugin, for example: > >>>>> https://github.com/yasa-org/yasa/tree/master/yasa-solr-plugin > >>>>> > >>>>> On Mon, Nov 14, 2022 at 10:07 PM Gus Heck<gus.h...@gmail.com> > wrote: > >>>>> > >>>>>> In 9.x it should be possible to write a separate servlet that can > >>>> answer > >>>>>> custom non-search queries. Then all you need to edit is web.xml. You > >>>> can > >>>>>> now get hold of a core container > >>>>>> via org.apache.solr.servlet.CoreContainerProvider#getCoreContainer. > >>>>>> > >>>>>> Looking at the code, it seems you still need to live in the apache > >>>> package > >>>>>> because that method is not public, but if you've got a demonstrable > use > >>>>>> case for it I don't see why that couldn't be made public in future > >>>>>> versions. If that's tweaked to be public you could avoid changing > >>>> implicit > >>>>>> plugins, would not need to live under admin, and it should be > possible > >>>> to > >>>>>> load from a separate jar if the jar is inserted > >>>>>> into /server/solr-webapp/webapp/WEB-INF/lib > >>>>>> > >>>>>> A question to consider when choosing is whether you want the end > point > >>>> to > >>>>>> be protected by authentication. If so then you're going to want to > do > >>>> it > >>>>>> Shawn's way. If you want something publicly visible (say to > >>>> infrastructure > >>>>>> systems without login) then a servlet might be more useful since it > >>>> will > >>>>>> live outside of all our security stuff. > >>>>>> > >>>>>> On Mon, Nov 14, 2022 at 2:16 AM gnandre<arnoldbron...@gmail.com> > >>>> wrote: > >>>>>>> Thanks, Shawn. I think what you propose there will be very helpful. > >>>>>> There > >>>>>>> are definitely usecases where we want to work at the solr node > level > >>>> and > >>>>>>> not core level. Fieldcache is one other example. > >>>>>>> > >>>>>>> In my case, I am trying to write a simple health check request > >>>> handler > >>>>>> that > >>>>>>> makes sure that all cores on a particular node are loaded and are > >>>>>>> queriable. The ping request handler works on a core level. The > >>>>>>> /solr/admin/cores api works for me but it returns with the ok > status > >>>>>> even > >>>>>>> if some other cores are still loading after solr restart. > >>>>>>> > >>>>>>> Ps. I am using legacy setup (non-cloud) > >>>>>>> > >>>>>>> On Mon, Nov 14, 2022, 2:04 AM Shawn Heisey<apa...@elyograg.org> > >>>> wrote: > >>>>>>>> On 11/13/22 23:55, Shawn Heisey wrote: > >>>>>>>>> If you want to create your own global handler, then you can add a > >>>>>>>>> definition to ImplicitPlugins.json, which is embedded in the > >>>>>> solr-core > >>>>>>>>> jar. Unless you want to do jar surgery, it's best to make that > >>>>>> change > >>>>>>>>> in the source code and recompile Solr. > >>>>>>>> Seehttps://issues.apache.org/jira/browse/SOLR-15859 for an > >>>> example > >>>>>>>> where I am creating a new global handler. > >>>>>>>> > >>>>>>>> I am wondering if ImplicitPlugins.json could be put in a location > >>>> like > >>>>>>>> server/lib/ext so recompiling Solr or jar surgery isn't required. > >>>> I > >>>>>>>> think server/lib/ext is searched on the classpath before WEB-INF. > >>>>>> Even > >>>>>>>> better would be to have another json where user-specified implicit > >>>>>>>> handlers can be defined. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Shawn > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> -- > >>>>>> http://www.needhamsoftware.com (work) > >>>>>> http://www.the111shift.com (play) > >>>>>> > > > -- > Charlie Hull - Managing Consultant at OpenSource Connections Limited > Founding member of The Search Network <http://www.thesearchnetwork.com> > and co-author of Searching the Enterprise > < > https://opensourceconnections.com/wp-content/uploads/2020/08/ES_book_final_journal_version.pdf > > > tel/fax: +44 (0)8700 118334 > mobile: +44 (0)7767 825828 > > OpenSource Connections Europe GmbH | Pappelallee 78/79 | 10437 Berlin > Amtsgericht Charlottenburg | HRB 230712 B > Geschäftsführer: John M. Woodell | David E. Pugh > Finanzamt: Berlin Finanzamt für Körperschaften II
