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
