But again, why do you want to do this? I really think you don't. I'm assuming that when you say this: "...resulting in the same slave being hit for all requests."
you mean "all requests _from the same client_". If that's not what's happening, then disregard my maundering because when it comes to setting up LBs, I'm clueless. But I can say that many installations have LBs set up with sticky sessions on a per-client basis...... Consider another scenario; replication. If you have 2 slaves, each with a polling interval of 5 minutes note that they are not coordinated. So slave 1 can poll at 14:00:00. Slave 2 at 14:01:00. Say there's been a commit at 14:00:30. Requests to slave 2 will have a different view of the index than slave 1, so if your user resends the exact same request, they may see different results. I could submit the request 5 times in a row and the results would not only be different each time, they would flip-flop back and forth. I wouldn't do this unless and until you have a demonstrated need. Best Erick On Thu, Sep 27, 2012 at 8:07 AM, Lee Carroll <lee.a.carr...@googlemail.com> wrote: > Hi Erick, > > the load balancer in front of the solr servers is dropping the cookie not > the solr server themselves. > > are you saying the clients http connection manager builds will ignore this > state ? it looks like they do not. It looks like the > client is passing the cookie back to the load balancer > > I want to configure the clients not to pass cookies basically. > > Does that make sense ? > > > > On 27 September 2012 12:54, Erick Erickson <erickerick...@gmail.com> wrote: > >> 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 >>
