Sorry - need to correct myself - updates worked the same as read requests - they also needed to hit a SolrCore in order to get forwarded to the right node. I was not thinking clearly when I said this applied to just reads and not writes. Both needed a SolrCore to do their work - with the request proxying, this is no longer the case, so you can hit Solr instances with no SolrCores or with SolrCores that are not part of the collection you are working with, and both read and write side requests are now proxied to a suitable node that has a SolrCore that can do the search or forward the update (or accept the update).
- Mark On Apr 23, 2013, at 3:38 PM, Mark Miller <markrmil...@gmail.com> wrote: > We have a 3rd release candidate for 4.3 being voted on now. > > I have never tested this feature with Tomcat - only Jetty. Users have > reported it does not work with Tomcat. That leads one to think it may have a > problem in other containers as well. > > A previous contributor donated a patch that explicitly flushes a stream in > our proxy code - he says this allows the feature to work with Tomcat. I > committed this feature - the flush can't hurt, and given the previous > contributions of this individual, I'm fairly confident the fix makes things > work in Tomcat. I have no first hand knowledge that it does work though. > > You might take the RC for a spin and test it our yourself: > http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/ > > - Mark > > On Apr 23, 2013, at 3:20 PM, Furkan KAMACI <furkankam...@gmail.com> wrote: > >> Hi Mark; >> >> All in all you say that when 4.3 is tagged at repository (I mean when it is >> ready) this feature will work for Tomcat too at a stable version? >> >> >> 2013/4/23 Mark Miller <markrmil...@gmail.com> >> >>> >>> On Apr 23, 2013, at 2:49 PM, Shawn Heisey <s...@elyograg.org> wrote: >>> >>>> What exactly is the 'request proxying' thing that doesn't work on >>> tomcat? Is this something different from basic SolrCloud operation where >>> you send any kind of request to any server and they get directed where they >>> need to go? I haven't heard of that not working on tomcat before. >>> >>> Before 4.2, if you made a read request to a node that didn't contain part >>> of the collection you where searching, it would return 404. Write requests >>> would be forwarded to where they belong no matter what node you sent them >>> to, but read requests required that node have a part of the collection you >>> were accessing. >>> >>> In 4.2 we added request proxying for this read side case. If a piece of >>> the collection you are querying is not found on the node you hit, a simple >>> proxy of the request is done to a node that does contain a piece of the >>> collection. >>> >>> - Mark >
