Nicole -
Since this is probably off-topic for the solr-user list, let’s take this
offline and over to your Lucidworks support. But while we’re here, here’s an
example of using the Fusion API to create a collection and then the Solr API to
configure the schema. In this example, it’s not using the zkcli to upconfig,
though I’ve done that technique as well with no problems. Something is fishy,
obviously, with the discrepancy of your config set and your collection name,
but I’m not sure where that is coming from. Feel free to reply to me offline
at "erik <dot> hatcher @ lucidworks.com" with the exact commands that you’ve
issued and I’ll get a support ticket opened for you.
Erik
> On Dec 7, 2016, at 6:06 AM, Nicole Bilić <nicole.bil...@gmail.com> wrote:
>
> 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
>>
