What client state? Solr servers are stateless, they don't keep any information specific to particular clients so this doesn't seem to be a problem.
What Solr _does_ do is cache things like fq clauses, but these are not user-specific. Which actually argues for going to the same slave on the theory that requests from a user are more likely to have the same fq clauses. Consider faceting on shoes. The user clicks "mens" and you add an fq like &fq=gender:mens. Then the user wants dress shoes so you submit another query &fq=gender:mens&fq=style:dress. The first fq clause has already been calculated and cached so doesn't have to be re-calculated for the second query... But the stickiness is usually the way Solr is used, so this seems like a red herring. FWIW, Erick On Thu, Sep 27, 2012 at 7:06 AM, Lee Carroll <lee.a.carr...@googlemail.com> wrote: > Hi > > We have the following solr http server > > <bean class="org.apache.solr.client.solrj.impl.CommonsHttpSolrServer" > id="solrserver" > > <constructor-arg value="urlToSlaveLoadBalancer" /> > <property name="soTimeout" value="1000" /> > <property name="connectionTimeout" value="1000" /> > <property name="defaultMaxConnectionsPerHost" value="5" /> > <property name="maxTotalConnections" value="20" /> > <property name="allowCompression" value="true" /> > </bean> > > The issue we face is the f5 balancer is returning a cookie which the client > is hanging onto. resulting in the same slave being hit for all requests. > > one obvious solution is to config the load balancer to be non sticky > however politically a "non-standard" load balancer is timescale suicide. > (It is an out sourced corporate thing) > > I'm not keen to use the LB http solr server as i don't want this to be a > concern of the software and have a list of servers etc. (although as a stop > gap may well have to) > > My question is can I configure the solr server to ignore client state ? We > are on solr 3.4 > > Thanks in advance lee c
