On 7/14/2017 10:48 AM, Erick Erickson wrote: > I haven't seen anything like that, unsightly indeed. > > I like the idea of the button to remove failed messages. The only > thing you see is the write lock exception, correct? > > And since you say it fails on different cores at different times that > seems to rule out somehow you have more than one core pointing to the > same data dir. > > Two questions: > 1> I don't see "inc_1" in the list of cores discovered by the > corePropertiesLocator. Is this perhaps an alias? > 2> Are you absolutely sure that you don't somehow have more than one > core pointing to the same data dir? this latter is unlikely as you say > all the cores work, just covering bases.
The core is named inclive, its instanceDir ends in inc_1. At the moment, the core named incbuild is pointed at inc_0. When those cores are swapped, that will be reversed. I went with this directory naming scheme because cores get swapped on every full index rebuild and I did not want to have a situation where a live core was pointed at a directory with "build" in the name. It's not running in cloud mode, so there are no aliases. There were no problems with 6.3.0 pointing at the same solr home. Seeing the "write.lock" problem after the upgrade, I initially assumed that lockfiles were left over from 6.3.0 ... so I stopped Solr, deleted all the lockfiles, and started it back up. That's when I saw that it was being held by the running VM, not the previous one. Thanks, Shawn
