Hi Alex & Andrea for the reply. But Alex, Our main idea was to reduce network latency, since the only processing needed is only i/p to the next call, which is totally Solr params, like facets, sorting query etc. Thats the reason I am looking for the same. Thanks, Andrea but in my case the cores are different. Ex. /reqHandler1 => core1 /reqHandler2 => core2
On Mon, Dec 3, 2018 at 6:01 PM Andrea Gazzarini <a.gazzar...@sease.io> wrote: > > Hi, > What Alexander said is right, but if in your scenario you would still go > for that, you could try this [1], that should fit your need. > > Best, > Andrea > > [1] https://github.com/SeaseLtd/composite-request-handler > > On Mon, 3 Dec 2018, 13:26 Alexandre Rafalovitch <arafa...@gmail.com wrote: > > > You should not be exposing Solr directly to the client, but treating > > it more as a database. > > > > Given that, why would you not write your processing code in that > > middle-ware layer? > > > > Regards, > > Alex. > > On Mon, 3 Dec 2018 at 06:43, Lucky Sharma <goku0...@gmail.com> wrote: > > > > > > Hi have one scenario, > > > where I need to make a sequential call to the solr. Both the requests > > > are sequential and output of the first will be required to set some > > > params of the second search request. > > > > > > So for such scenarios, I am writing a plugin which will internally > > > handle both the requests and gives the final response as output. > > > > > > Is this the correct approach? > > > The only assumption I am making here is that both the cores are > > > locally available. > > > > > > -- > > > Warm Regards, > > > > > > Lucky Sharma > > > Contact No: +91 9821559918 > > -- Warm Regards, Lucky Sharma Contact No :+91 9821559918
