Then until you can try to fix the code, you need to increase your transient cache size.
Having 100+ cores on a Solr node and a transient cache size of 1 to "so jvm heap and os filecache is aligned to a manageable number of open cores we can serve" implies that you are trying to compensate for an under-provisioned installation by using transient cores in a way they were never intended. True, nothing in the docs tells you that explicitly, frankly it never occurred to me that people would use it that way. Best, Erick On Wed, Aug 22, 2018 at 11:43 AM, mmb1234 <m...@vmware.com> wrote: >> 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
