: norms, term vectors, field caches, etc. It almost sounds like one : would want multiple instances of Solr in the same app container. But : if that's the case, you aren't saving much over just having multiple : app servers.
I didn't say anything yesterday because i pretty much agreed with yonik ... but it occured to me this morning that if you have a finite amout of ram on a box (which we all do) 'R' gigs, and you want to run a variable number of solr indexs 'N", the only way to do this currently is to run N appserver instances and explicitly configure the JVM for each to use at most R/N Gigs max heap ... which would bnot only make addign a new index a pain (you have to reconfigure every appserver instance) but it also means that you are managine your memory instead of letting java do it. if it was possible to run several indexes in one appserver, then you wouldn't have to wworry about this (but if you wnated to worry about it, you could run some or all of your indexes in their own appserver instances) perhaps one way to go would be if solr paid attention to what webapp name it was being run in, and used that to determine the directory it looked in for it's configs/index? ... so most people would just intall "solr.war" and it would look for everything in ./solr/ -- but if i want multiple idexes i copy solr.war was solr-people.war, solr-places.war, and solr-things.war, and now i've got 3 webapps running solr, and 3 seperate directories containing 3 seperate indexes and configs... ./solr-people/, ./solr-places/, ./solar-things, etc... -Hoss
