Re: AEM SOLR integaration
Hi, Maybe this could help you out http://www.aemsolrsearch.com/ Regards, Nicole On Sep 22, 2017 05:41, "Gunalan V" wrote: > Hello, > > I'm looking for suggestion in building the SOLR infrastructure so Kindly > let me know if anyone has integerated AEM (Adobe Experience Manager) with > SOLR? > > > > Thanks, > GVK >
Duplicate suggestions when having multiple shards
Hi all, We are using Suggester (and Solr 6.3.0) to implement autocomplete. We are using TSTLookupFactory lookup implementation and HighFrequencyDictionaryFactory dictionary implementation. If our index consists of only one shard, everything works perfectly fine. However, when index is split in 2 shards, we start getting duplicated suggestions. We've done some testing and it is peculiar that even when we have exactly the same documents in both shards (just for testing purposes), we get duplicated terms, but their weights are slightly different. We haven't found any solution that works (we've tried FieldCollapsing as well). Due to some limitations, it is not an option to solve this (ie. throw out the duplicates) client-side. Is there a way to solve this issue solr-side? Thanks!
Re: Configuration folder for the collection generated with instead of just
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 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 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ć 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 > > instead of just (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 >
Configuration folder for the collection generated with instead of just
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 instead of just (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
