lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicole Bilić <nicole.bil...@gmail.com>
Subject Re: Configuration folder for the collection generated with <collectionname><id> instead of just <collectionname>
Date Wed, 07 Dec 2016 14:06:08 GMT
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.hatcher@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.bilic1@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message