Good suggestion, but unfortunately it does not address this issue as we are not using the time-based partitioning in this project.
It would be useful to know in which case is the configuration created with <collectionname><id> in Solr, what scenario does lead to that so we can investigate further. Any other suggestions? Thanks On Wed, Dec 7, 2016 at 1:53 PM, Erik Hatcher <erik.hatc...@gmail.com> wrote: > Looks best to file that as a Lucidworks support ticket. > > But are you using the time-based sharding feature of Fusion? If that's > the case that might explain it as that creates collections for each time > partition. > > Erik > > > On Dec 7, 2016, at 00:31, Nicole Bilić <nicole.bil...@gmail.com> wrote: > > > > Hi all, > > > > > > We are using Lucidworks Fusion on top of Solr and recently we’ve > > encountered an unexpected behavior. We’ve created bash scripts which we > use > > to create collections in Solr using the Fusion API and upload the > > collection configuration (with bash $ZKCLIENT -cmd upconfig -confdir > $path > > -confname $collection -z $HOST:$ZKPORT). > > > > We had issues that the index fields of our custom configurations were not > > available (ie. our custom field types and fields we’ve defined in > > managed-schema). So we checked in Solr admin and found out that the > > configuration folder for the collection was generated with > > <collectionname><id> instead of just <collectionname> (eg. > > https://drive.google.com/file/d/0B9Nu5vSE4ep8OUdyckZoV2FMdlE/ > view?usp=sharing). > > > > > > Our collection configurations are under the one with the id in the end. > So > > the configuration set that was uploaded by our scripts was never used and > > therefore the index fields were not existing. Also, we did not manage to > > discover a pattern (or cause) for when does this happen (because > sometimes > > the issue does not occur and sometimes it does and to us it seems pretty > > nondeterministic). > > > > Furthermore, in the screenshot above, it’s possible to see the same thing > > happened with system_metrics collection configs, which we do not create > or > > modify with our scripts. Therefore, the scripts should not be the cause > of > > this behavior. > > > > What we are trying to determine is if this issue is coming from Fusion, > > Solr or Zookeeper. Does someone know in which case the collection > > configuration folder is generated with the id in the end and how to avoid > > it? Thank you! > > > > > > Nicole >
