> The problem here is that you may have M requests queued up for the _same_ core, each with a new update request.
With transientCacheSize ==1, as soon as the update request for Core B is received, Core B encounters data corruption not Core A. Both Core A and Core B are receiving update requets. I am presuming this happens on core close after the ref count is decremented for Core B to process the request for Core A. In production number of cores on solr == 100+. Transient cache is sized so jvm heap and os filecache is aligned to a manageable number of open cores we can serve (isOpen != false). So when a random update request comes in, corruption is seen. Very painful since now a restore needs to be invoked. This is happening 5 to 10 times a day. -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
