Re: shareSchema="true" - location of schema.xml?
I have 300 cores so I feel your pain :-) What we do is use a relative path for the file. It works if you use ../../common/schema.xml for each core, then just create a common directory off your solr home and put your schema file there. I found this works great with solrconfig.xml and all of it's dependencies as well. Another choice is to look at the sharedLib parameter, which adds some directory to your classpath. I played with this for a little bit and couldn't get it working, so I went with the relative path solution. -- View this message in context: http://lucene.472066.n3.nabble.com/shareSchema-true-location-of-schema-xml-tp3297392p3364809.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: matching reponse and request
I don't think you can do this. If you are sending multiple GET requests, you are doing it across different HTTP connections. The web service has no way of knowing these are related. One solution would be to pass a spare, unused parameter to your request, like sequenceId=NNN and get the response to echo that back. Then at least you can tell which one is coming back and fix the order up in your program. -- View this message in context: http://lucene.472066.n3.nabble.com/matching-reponse-and-request-tp3363976p3364816.html Sent from the Solr - User mailing list archive at Nabble.com.
RE: JdbcDataSource and threads
My guess on this is that you're making a LOT of database requests and have a million TIME-WAIT connections, and your port range for local ports is running out. You should first confirm that's true by running netstat on the machine while the load is running. See if it gives a lot of output. One way to solve this problem is to use a connection pool. Look at adding a pooled JNDI connection into your web service and connect with that instead. The best way is to avoid making the extra connections. If the data in the subqueries is really short, look into caching the results using a CachedSqlEntityProcessor instead. I wasn't able to use this approach because I had a lot of data in the inner queries. What I ended out doing was writing my own OrderedSqlEntityProcessor which correlates an outer ordered query with an inner ordered query. This ran a lot faster and reduced my load times from 20 hours to 20 minutes. Let me know if you're interested in that code. -- View this message in context: http://lucene.472066.n3.nabble.com/JdbcDataSource-and-threads-tp3359874p3364831.html Sent from the Solr - User mailing list archive at Nabble.com.
