Re: Corrupt Index error on Target cluster
Hmm, when this occurred for me I was also on 6.6 between minor releases. So unclear if it's connected to 6.6 specifically. If you want to resolve the problem, you should be able to use the collection api delete that node from the collection, and then re-add it which will trigger resync. On Fri, Sep 7, 2018, 10:35 AM Susheel Kumar wrote: > No. The solr i have is 6.6. > > On Fri, Sep 7, 2018 at 10:51 AM Stephen Bianamara < > sdl1tinsold...@gmail.com> > wrote: > > > I've gotten incorrect checksums when upgrading solr versions across the > > cluster. Or in other words, when indexing into a mixed version cluster. > Are > > you running mixed versions by chance? > > > > On Fri, Sep 7, 2018, 6:07 AM Susheel Kumar > wrote: > > > > > Anyone has insight / have faced above errors ? > > > > > > On Thu, Sep 6, 2018 at 12:04 PM Susheel Kumar > > > wrote: > > > > > > > Hello, > > > > > > > > We had a running cluster with CDCR and there were some issues with > > > > indexing on Source cluster which got resolved after restarting the > > nodes > > > > (in my absence...) and now I see below errors on a shard at Target > > > > cluster. Any suggestions / ideas what could have caused this and > whats > > > the > > > > best way to recover. > > > > > > > > Thnx > > > > > > > > Caused by: org.apache.solr.common.SolrException: Error opening new > > > searcher > > > > at > > > > org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2069) > > > > at > > org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2189) > > > > at > > org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1926) > > > > at > > org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1826) > > > > at > > > > > > > > > > org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:127) > > > > at > > > > > > > > > > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:310) > > > > at > > > > > > > > > > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:296) > > > > at > > > > > > > > > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173) > > > > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477) > > > > at > > > > > > > > > > org.apache.solr.handler.PingRequestHandler.handlePing(PingRequestHandler.java:267) > > > > ... 34 more > > > > Caused by: org.apache.lucene.index.CorruptIndexException: Corrupted > > > > bitsPerDocBase: 6033 > > > > > > > > > > (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/app/solr/data/COLL_shard8_replica1/data/index.20180903220548447/_9nsy.tvx"))) > > > > at > > > > > > > > > > org.apache.lucene.codecs.compressing.CompressingStoredFieldsIndexReader.(CompressingStoredFieldsIndexReader.java:89) > > > > at > > > > > > > > > > org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.(CompressingTermVectorsReader.java:126) > > > > at > > > > > > > > > > org.apache.lucene.codecs.compressing.CompressingTermVectorsFormat.vectorsReader(CompressingTermVectorsFormat.java:91) > > > > at > > > > > > > > > > org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:128) > > > > at > > > > org.apache.lucene.index.SegmentReader.(SegmentReader.java:74) > > > > at > > > > > > > > > > org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:145) > > > > at > > > > > > > > > > org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:197) > > > > at > > > > > > > > > > org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:103) > > > > at > > > > org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:467) > > > > at > > > > > org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:103) > > > > at > > > > org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:79) > > > > at > > > > > > > > > > org.apache.solr.core.StandardIndexReaderFactory.newReader(StandardIndexReaderFactory.java:39) > > > > at > > > > org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2033) > > > > ... 43 more > > > > Suppressed: org.apache.lucene.index.CorruptIndexException: > > > > checksum failed (hardware problem?) : expected=e5bf0d15 > actual=21722825 > > > > > > > > > > (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/app/solr/data/COLL_shard8_replica1/data/index.20180903220548447/_9nsy.tvx"))) > > > > at > > > > org.apache.lucene.codecs.CodecUtil.checkFooter(CodecUtil.java:419) > > > > at > > > > org.apache.lucene.codecs.CodecUtil.checkFooter(CodecUtil.java:462) > > > > at > > > > > > > > > > org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.(CompressingTermVectorsReader.java:131) > > > > ... 54 more > > > > > >
Re: parent/child rows in solr
On 9/7/2018 7:44 PM, John Smith wrote: Thanks Shawn, for your comments. The reason why I don't want to go flat file structure, is due to all the wasted/duplicated data. If a department has 100 employees, then it's very wasteful in terms of disk space to repeat the header data over and over again, 100 times. In this example there is only a few doc types, but my real-life data is much larger, and the problem is a "scaling" problem; with just a little bit of data, no problem in duplicating header fields, but with massive amounts of data it's a large problem. If your goal is data storage, then you are completely correct. All that data duplication is something to avoid for a data storage situation. Normalizing your data so it's relational makes perfect sense, because most database software is designed to efficiently deal with those relationships. Solr is not designed as a data storage platform, and does not handle those relationships efficiently. Solr's design goals are all about *search*. It often gets touted as filling a NoSQL role ... but it's not something I would personally use as a primary data repository. Search is a space where data duplication is expected and completely normal. This is something that people often have a hard time accepting. Thanks, Shawn
Re: parent/child rows in solr
Thanks Shawn, for your comments. The reason why I don't want to go flat file structure, is due to all the wasted/duplicated data. If a department has 100 employees, then it's very wasteful in terms of disk space to repeat the header data over and over again, 100 times. In this example there is only a few doc types, but my real-life data is much larger, and the problem is a "scaling" problem; with just a little bit of data, no problem in duplicating header fields, but with massive amounts of data it's a large problem. My understanding of both graph traversal and block joins, is that the header data would only be present once, so that's why I'm gravitating towards those solutions. I just can't seem to line up the "fq" and queries correctly such that I am able to join 3+ document types together, filter on them, and return my requested columns. On Fri, Sep 7, 2018 at 9:32 PM Shawn Heisey wrote: > On 9/7/2018 3:06 PM, John Smith wrote: > > Hi, I have a document structure like this (this is a made up schema, my > > data has nothing to do with departments and employees, but the structure > > holds true to my real data): > > > > department 1 > > employee 11 > > employee 12 > > employee 13 > > room 11 > > room 12 > > room 13 > > > > department 2 > > employee 21 > > employee 22 > > room 21 > > > > ... etc > > > > I'm trying to figure out the best way to index this, and perform queries. > > Due to the sheer volume of data, I cannot do a simple "flat file" > approach, > > repeating the header data for each child entry. > > Why not? > > For the precise use case you have outlined, Solr will work better if you > only have the child documents and simply have every document contain a > "department" field which contains an identifier for the department. > Since this precise structure is not what you are doing, you'll need to > adapt what I'm saying to your actual data. > > The volume of data should be irrelevant to this decision. Solr will > always work best with a flat document structure. > > I have never used the parent/child document feature in Solr, so I cannot > offer any advice on it. Somebody else will need to help you if you > choose to use that feature. > > Thanks, > Shawn > >
Re: local "q.op=AND" ignored for edismax query
On 9/7/2018 6:59 PM, dshih wrote:
Query:
/select?q={!q.op=AND}mysearchtext*&defType=edismax&debugQuery=true
Result:
"querystring": "{!q.op=AND}mysearchtext*",
"parsedquery": "+DisjunctionMaxQuery(((Synonym(text:q
text:qopandmysearchtext text:{!q.op=and}mysearchtext*) text:op text:and
text:mysearchtext)))"
In the above, I'm just trying to set the query operator to AND while leaving
the default as OR. It looks like q.op is being completely ignored (and ends
up as part of the search terms).
Since 7.2, you can only use certain localparams if defType is lucene or
func. The lucene parser is the default. Since you have changed defType
to edismax, localparams will not work. Just add q.op as a separate
parameter.
/select?q=mysearchtext*&defType=edismax&debugQuery=true&q.op=AND
Or use mm=100% instead. Which is effectively what q.op=AND does.
This is the issue that made the change in 7.2:
https://issues.apache.org/jira/browse/SOLR-11501
Thanks,
Shawn
Re: parent/child rows in solr
On 9/7/2018 3:06 PM, John Smith wrote: Hi, I have a document structure like this (this is a made up schema, my data has nothing to do with departments and employees, but the structure holds true to my real data): department 1 employee 11 employee 12 employee 13 room 11 room 12 room 13 department 2 employee 21 employee 22 room 21 ... etc I'm trying to figure out the best way to index this, and perform queries. Due to the sheer volume of data, I cannot do a simple "flat file" approach, repeating the header data for each child entry. Why not? For the precise use case you have outlined, Solr will work better if you only have the child documents and simply have every document contain a "department" field which contains an identifier for the department. Since this precise structure is not what you are doing, you'll need to adapt what I'm saying to your actual data. The volume of data should be irrelevant to this decision. Solr will always work best with a flat document structure. I have never used the parent/child document feature in Solr, so I cannot offer any advice on it. Somebody else will need to help you if you choose to use that feature. Thanks, Shawn
local "q.op=AND" ignored for edismax query
SOLR 7.4.0
Apologies if this has been answered, but I can't find the answer for the
life of me if it has been.
Query:
/select?q={!q.op=AND}mysearchtext*&defType=edismax&debugQuery=true
Result:
"querystring": "{!q.op=AND}mysearchtext*",
"parsedquery": "+DisjunctionMaxQuery(((Synonym(text:q
text:qopandmysearchtext text:{!q.op=and}mysearchtext*) text:op text:and
text:mysearchtext)))"
In the above, I'm just trying to set the query operator to AND while leaving
the default as OR. It looks like q.op is being completely ignored (and ends
up as part of the search terms).
I did read https://lucene.apache.org/solr/guide/7_2/solr-upgrade-notes.html
regarding switching the query parser using local parameters, but that is not
what is happening here. Incidentally, if I set luceneMatchVersion=7.1.0, I
can workaround this issue by doing "{!edismax q.op=and}", but that doesn't
work with 7.4.0.
I also read a number of threads/bugs about changes to the "mm" option, but I
don't think that's relevant here either.
The above works in 4.10.3 (long time ago - I know). What is the recommended
way to get the same functionality?
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: SolrCloud CDCR with 3+ DCs
Yeah, I am not sure about how the Authentication band aid feature will work, the mentioned stackoverflow link. It is about time we include basic authentication support in CDCR. On Thu, 6 Sep 2018, 8:41 pm cdatta, wrote: > Hi Amrit, Thanks for your response. > > We wiped out our complete installation and started a fresh one. Now the > multi-direction replication is working but we are seeing errors related to > the authentication sporadically. > > Thanks & Regards, > Chandi Datta > > > > -- > Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html >
unregistered
unregistered
Solr CDCR replication not working
Basic Authentication in clusters is not supported as of today in CDCR.
On Fri, 7 Sep 2018, 4:53 pm Mrityunjaya Pathak,
wrote:
> I have setup two solr cloud instances in two different Datacenters Target
> solr cloud machine is copy of source machine with basicAuth enabled on
> them. I am unable to see any replication on target.
>
> Solr Version :6.6.3
>
> I have done config changes as suggested on
> https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
>
> Source Config Changes
>
>
>
> ...
>
>
> serverIP:2181,serverIP:2182,serverIP:2183
> sitecore_master_index
> sitecore_master_index
>
>
>
> 8
> 1000
> 128
>
>
>
> 1000
>
>
>
>
>
> ${solr.ulog.dir:}
>name="numVersionBuckets">${solr.ulog.numVersionBuckets:65536}
>
>
>
>
> ${solr.autoCommit.maxTime:15000}
> false
>
>
>
> ${solr.autoSoftCommit.maxTime:-1}
>
>
>
> ...
>
>
> Target Config Changes
>
>
>
> ...
>
>
> disabled
>
>
>
>
>
>
>
>
> cdcr-proc-chain
>
>
>
>
>
> ${solr.ulog.dir:}
>name="numVersionBuckets">${solr.ulog.numVersionBuckets:65536}
>
>
>
> ${solr.autoCommit.maxTime:15000}
> false
>
>
>
> ${solr.autoSoftCommit.maxTime:-1}
>
>
>
>
> ...
>
>
> Below are logs from Source target.
>
> ERROR (zkCallback-4-thread-2-processing-n:sourceIP:8983_solr) [ ]
> o.a.s.c.s.i.CloudSolrClient Request to collection collection1 failed due to
> (510) org.apache.solr.common.SolrException: Could not find a healthy node
> to handle the request., retry? 5
> 2018-09-07 10:36:14.295 WARN
> (zkCallback-4-thread-2-processing-n:sourceIP:8983_solr) [ ]
> o.a.s.h.CdcrReplicatorManager Unable to instantiate the log reader for
> target collection collection1
> org.apache.solr.common.SolrException: Could not find a healthy node to
> handle the request.
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1377)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1134)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073)
> at
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> at
> org.apache.solr.handler.CdcrReplicatorManager.getCheckpoint(CdcrReplicatorManager.java:196)
> at
> org.apache.solr.handler.CdcrReplicatorManager.initLogReaders(CdcrReplicatorManager.java:159)
> at
> org.apache.solr.handler.CdcrReplicatorManager.stateUpdate(CdcrReplicatorManager.java:134)
> at
> org.apache.solr.handler.CdcrStateManager.callback(CdcrStateManager.java:36)
> at
> org.apache.solr.handler.CdcrLeaderStateManager.setAmILeader(CdcrLeaderStateManager.java:108)
> at
> org.apache.solr.handler.CdcrLeaderStateManager.checkIfIAmLeader(CdcrLeaderStateManager.java:95)
> at
> org.apache.solr.handler.CdcrLeaderStateManager.access$400(CdcrLeaderStateManager.java:40)
> at
> org.apache.solr.handler.CdcrLeaderStateManager$LeaderStateWatcher.process(CdcrLeaderStateManager.java:150)
> at
> org.apache.solr.common.cloud.SolrZkClient$3.lambda$process$0(SolrZkClient.java:269)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2018-09-07 10:36:14.310 INFO
> (coreLoadExecutor-8-thread-3-processing-n:sourceIP:8983_solr) [ ]
> o.a.s.c.SolrConfig Using Lucene MatchVersion: 6.6.3
> 2018-09-07 10:36:14.315 INFO
> (zkCallback-4-thread-1-processing-n:sourceIP:8983_solr) [ ]
> o.a.s.c.c.ZkStateReader A cluster state change: [WatchedEvent
> state:SyncConnected type:NodeDataChanged
> path:/collections/collection1/state.json] for collection [sitecore] has
> occurred - updating... (live nodes size: [1])
> 2018-09-07 10:36:14.343 WARN
> (cdcr-replicator-211-thread-
parent/child rows in solr
Hi, I have a document structure like this (this is a made up schema, my data has nothing to do with departments and employees, but the structure holds true to my real data): department 1 employee 11 employee 12 employee 13 room 11 room 12 room 13 department 2 employee 21 employee 22 room 21 ... etc I'm trying to figure out the best way to index this, and perform queries. Due to the sheer volume of data, I cannot do a simple "flat file" approach, repeating the header data for each child entry. So that leaves me with "graph traversal" or "block joins". I've played with both of those, but I'm running into various issues with each approach. I need to be able to run filters on any or all of the header + child rows in the same query, at once (can't seem to get that working in either graph or block join). One problem I had with graph is that I can't force solr to return the header, then all the children for that header, then the next header + all it's children, it just spits them out without keeping them together. block join seems to return the children nested under the parents, which is great, but then I can't seem to filter on parent + children in the same query: I get the dreaded error message "Parent query must not match any docs besides parent filter" Kinda lost here, any tips/suggestions?
Re: Solr metric for finding number of merges in progress
Actually, i found this after posting; (still if someone has more to offer, please reply) https://lucene.apache.org/solr/guide/7_0/metrics-reporting.html#index-merge-metrics On Fri, Sep 7, 2018 at 12:13 PM Nawab Zada Asad Iqbal wrote: > Hi, > > Does Solr expose a metric to find the number of segment merges which are > in progress? > > > Thanks > Nawab >
Solr metric for finding number of merges in progress
Hi, Does Solr expose a metric to find the number of segment merges which are in progress? Thanks Nawab
Re: Corrupt Index error on Target cluster
No. The solr i have is 6.6. On Fri, Sep 7, 2018 at 10:51 AM Stephen Bianamara wrote: > I've gotten incorrect checksums when upgrading solr versions across the > cluster. Or in other words, when indexing into a mixed version cluster. Are > you running mixed versions by chance? > > On Fri, Sep 7, 2018, 6:07 AM Susheel Kumar wrote: > > > Anyone has insight / have faced above errors ? > > > > On Thu, Sep 6, 2018 at 12:04 PM Susheel Kumar > > wrote: > > > > > Hello, > > > > > > We had a running cluster with CDCR and there were some issues with > > > indexing on Source cluster which got resolved after restarting the > nodes > > > (in my absence...) and now I see below errors on a shard at Target > > > cluster. Any suggestions / ideas what could have caused this and whats > > the > > > best way to recover. > > > > > > Thnx > > > > > > Caused by: org.apache.solr.common.SolrException: Error opening new > > searcher > > > at > > > org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2069) > > > at > org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2189) > > > at > org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1926) > > > at > org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1826) > > > at > > > > > > org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:127) > > > at > > > > > > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:310) > > > at > > > > > > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:296) > > > at > > > > > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173) > > > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477) > > > at > > > > > > org.apache.solr.handler.PingRequestHandler.handlePing(PingRequestHandler.java:267) > > > ... 34 more > > > Caused by: org.apache.lucene.index.CorruptIndexException: Corrupted > > > bitsPerDocBase: 6033 > > > > > > (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/app/solr/data/COLL_shard8_replica1/data/index.20180903220548447/_9nsy.tvx"))) > > > at > > > > > > org.apache.lucene.codecs.compressing.CompressingStoredFieldsIndexReader.(CompressingStoredFieldsIndexReader.java:89) > > > at > > > > > > org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.(CompressingTermVectorsReader.java:126) > > > at > > > > > > org.apache.lucene.codecs.compressing.CompressingTermVectorsFormat.vectorsReader(CompressingTermVectorsFormat.java:91) > > > at > > > > > > org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:128) > > > at > > > org.apache.lucene.index.SegmentReader.(SegmentReader.java:74) > > > at > > > > > > org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:145) > > > at > > > > > > org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:197) > > > at > > > > > > org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:103) > > > at > > > org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:467) > > > at > > > org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:103) > > > at > > > org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:79) > > > at > > > > > > org.apache.solr.core.StandardIndexReaderFactory.newReader(StandardIndexReaderFactory.java:39) > > > at > > > org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2033) > > > ... 43 more > > > Suppressed: org.apache.lucene.index.CorruptIndexException: > > > checksum failed (hardware problem?) : expected=e5bf0d15 actual=21722825 > > > > > > (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/app/solr/data/COLL_shard8_replica1/data/index.20180903220548447/_9nsy.tvx"))) > > > at > > > org.apache.lucene.codecs.CodecUtil.checkFooter(CodecUtil.java:419) > > > at > > > org.apache.lucene.codecs.CodecUtil.checkFooter(CodecUtil.java:462) > > > at > > > > > > org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.(CompressingTermVectorsReader.java:131) > > > ... 54 more > > > > > >
Re: Solr range faceting
Oh, indeed if you changed anything about the field definition and did
_not_ reindex everything from scratch your results are unreliable.
I'm overstating the case, but it'll do for now. For instance, your
facet counts should be find if you changed the stored parameter for
instance, but anything else
And it's best to index into a new collection (or core in stand-alone)
rather then re-use the current one just for paranoia's sake.
Best,
Erick
On Fri, Sep 7, 2018 at 12:18 AM Dwane Hall wrote:
>
> Thanks Erick,
>
> The field is defined as a pfloat.
>
> indexed="true" stored="true"/>
>
> I took your advice and tried smaller result range and the counts look good.
> I might try an index rebuild I’m wondering if the data has somehow been
> corrupted by a combination of old and new index mappings.
>
> Thanks again for your assistance.
>
>
> "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":7},
> "response":{"numFound":3,"start":0,"docs":[
> {
> "Value":34.0},
> {
> "Value":34.0},
> {
> "Value":34.0}]
> },
> "facet_counts":
> "facet_queries":{},
> "facet_ranges":{
> "Value:{
> "counts":[
> "0.0",3],
> "gap":100.0,
> "before":0,
> "after":0,
> "between":3,
> "start":0.0,
> "end":2000.0}}
>
> From: Erick Erickson
> Sent: Friday, 7 September 2018 12:54:48 PM
> To: solr-user
> Subject: Re: Solr range faceting
>
> Indeed this doesn't look right. By my count, you're missing 599 counts
> you'd expect in that range, although the after and between numbers
> total the numFound.
>
> What kind of a field is Value? Given the number of docs missing, I'd
> guess you could get the number of docs down really small and post
> them. Something like
> values 1, 2, 3, 4, 5,
> and your range query so we could try it.
>
> What is the fieldType definition and field for Value?
>
> And finally, do you get different results if you use json faceting?
>
> Best,
> Erick
> On Thu, Sep 6, 2018 at 5:51 PM Dwane Hall wrote:
> >
> > Thanks Jan that has fixed the bucket issue but I'm a little confused at why
> > zero counts exist for some buckets when they appear to be values in them?
> >
> > "response":{"numFound":869,"start":0,"docs":[
> > {
> > "Value":9475.08},
> > {
> > "Value":780.0},
> > {
> > "Value":9475.08},
> > {
> > "Value":1000.0},
> > {
> > "Value":50.0},
> > {
> > "Value":50.0},
> > {
> > "Value":0.0},
> > {
> > "Value":800.0},
> > {
> > "Value":0.0},
> > {
> > "Value":1000.0},
> > {
> > "Value":1000.0},
> > {
> > "Value":5000.0},
> > {
> > "Value":2000.0},
> > {
> >"Value":4000.0},
> > {
> > "Value":1500.0},
> > {
> > "Value":0.0},
> > {
> > "Value":1.0},
> > {
> > "Value":5000.0},
> > {
> > "Value":1000.0},
> > {
> > "Value":0.0},
> > {
> > "Value":1200.0},
> > {
> > "Value":9000.0},
> > {
> > "Value":1500.0},
> > {
> > "Value":1.0},
> > {
> > "Value":5000.0},
> > {
> > "Value":4000.0},
> > {
> > "Value":5000.0},
> > {
> > "Value":5000.0},
> > {
> > "Value":1.0},
> > {
> > "Value":1000.0}]
> > },
> >
> > "facet_counts":{
> > "facet_queries":{},
> > "facet_ranges":{
> > "Value":{
> > "counts":[
> > "0.0",9,
> > "100.0",0,
> > "200.0",0,
> > "300.0",0,
> > "400.0",80,
> > "500.0",0,
> > "600.0",0,
> > "700.0",69,
> > "800.0",0,
> > "900.0",0,
> > "1000.0",0,
> > "1100.0",0,
> > "1200.0",0,
> > "1300.0",0,
> > "1400.0",0,
> > "1500.0",0,
> > "1600.0",0,
> > "1700.0",0,
> > "1800.0",0,
> > "1900.0",9],
> > "gap":100.0,
> > "before":0,
> > "after":103,
> > "between":766,
> > "start":0.0,
> > "end":2000.0}
> >
> > Cheers,
> >
> > Dwane
> >
> > From: Jan H?ydahl
> > Sent: Friday, 7 September 2018 9:23:44 AM
> > To: solr-user@lucene.apache.org
> > Subject: Re: Solr range faceting
> >
> > Try facet.minCount=0
> >
> > Jan
> >
> > > 7. sep. 2018 kl. 01:07 skrev Dwane Hall :
> > >
> > > Good morning Solr community. I'm having a few facet range issues for
> > > which I'd appreciate some advice when somebody gets a spare couple of
> > > minutes.
> > >
> > > Environment
> > > Solr Cloud (7.3.1)
> > > Single Shard Index, No replicas
> > >
> > > Facet Configuration (I'm using the request params API and useParams at
>
Re: MLT in Cloud Mode - Not Returning Fields?
If this is still a problem in master/7x then a JIRA is in order. On Fri, Sep 7, 2018 at 7:40 AM Doug Turnbull wrote: > > Looks like this is indeed a bug > > My colleague debugged this behavior and it turns out that Solr only > requests id and score from the shards, and not the user-specified field > list. You can see that on this line > > https://github.com/apache/lucene-solr/blob/branch_7_4/solr/core/src/java/org/apache/solr/handler/component/MoreLikeThisComponent.java#L342 > > Happy to create a Jira ticket > > -Doug > > On Mon, Sep 3, 2018 at 5:23 AM Charlie Hull wrote: > > > On 31/08/2018 19:36, Doug Turnbull wrote: > > > Hello, > > > > > > We're working on a Solr More Like This project (Solr 6.6.2), using the > > More > > > Like This searchComponent. What we note is in standalone Solr, when we > > > request MLT using the search component, we get every more like this > > > document fully formed with complete fields in the moreLikeThis section. > > > > Hey Doug, > > > > IIRC there wasn't a lot of support for MLT in cloud mode a few years > > ago, and there are certainly still a few open issues around cloud support: > > https://issues.apache.org/jira/browse/SOLR-4414 > > https://issues.apache.org/jira/browse/SOLR-5480 > > Maybe there are some hints in the ticket comments about different ways > > to do what you want. > > > > Cheers > > > > Charlie > > > > > > > > In cloud, however, with the exact same query and config, we only get the > > > doc ids under "moreLikeThis" requiring us to fetch the metadata > > associated > > > with each document. > > > > > > I can't easily share an example due to confidentiality, but I want to > > check > > > if we're missing something? Documentation doesn't mention any > > limitations. > > > The only interesting note I've found is this one which points to a > > > potential difference in behavior > > > > > >> The Cloud MLT Query Parser uses the realtime get handler to retrieve > > the > > > fields to be mined for keywords. Because of the way the realtime get > > > handler is implemented, it does not return data for fields populated > > using > > > copyField. > > > > > > https://stackoverflow.com/a/46307140/8123 > > > > > > Any thoughts? > > > > > > -Doug > > > > > > > > > -- > > Charlie Hull > > Flax - Open Source Enterprise Search > > > > tel/fax: +44 (0)8700 118334 <+44%20870%20011%208334> > > mobile: +44 (0)7767 825828 <+44%207767%20825828> > > web: www.flax.co.uk > > > -- > CTO, OpenSource Connections > Author, Relevant Search > http://o19s.com/doug
Re: Solr 7.4 and log4j2 JSONLayout
On 9/6/2018 7:46 AM, Michael Aleythe, Sternwald wrote: I'm trying to edit the log4j2 logging configuration for solr. The goal is to get a log file in json format. I configured the the JSONLayout for this purpose inside the rollingFile appender in the log4j2.xml. After this solr stops logging entirely. Solr.log file is empty. Only the solr-8983-console.log file contains 10 lines. The line "2018-09-06 13:22:25.378:INFO:oejs.Server:main: Started @2814ms" is the last one. My first guess was that the jackson-core and jackson-databind jars were missing, but that did not fix the problem. As Varun said, jackson is already included in Solr. You won't need to add any jars for that. Does anyone know where to find error-messages or exceptions that point me towards whats going wrong here? Start Solr in the foreground, with the -f option. This will cause Solr to log to the console. When Solr is started in the background, it suppresses console logging. I see that you have changed the logfile rollover size to 1MB. If your Solr server sees much traffic, this is going to result in an extremely fast rollover, which may mean that you lose access to logged events VERY quickly. This will especially be the case with JSON logging -- each event will take up a lot more space. Thanks, Shawn
Re: Expected mime type application/octet-stream but got text/html
On 9/6/2018 12:29 PM, nalsrini wrote:
Here is the error message I am getting:
https://screencast.com/t/XwEjA22jX
Alexandre covered things quite well. It looks like you're using an
invalid URL.
Your original message shows this code:
SolrClient client = new HttpSolrClient("http://:/solr-master";);
That is not a valid URL. It is missing the hostname, the port, and
/solr-master is not the correct URL path. The correct path would be
/solr and MIGHT need to be /solr/indexname ... depending on exactly how
the other code is written. I prefer to use /solr and specify the
collection name when making the requests.
Also, this is a Tomcat error page. Is it Solr that's running in Tomcat,
or are you running another application in Tomcat that is accessing Solr?
Running Solr in Tomcat became an unsupported configuration as of Solr
5.0. It is something you can do, but we don't support it.
https://wiki.apache.org/solr/WhyNoWar
Thanks,
Shawn
Re: Solr memory reqs for time-sorted data
On 9/7/2018 8:39 AM, Pavel Micka wrote: I found on wiki (https://wiki.apache.org/solr/SolrPerformanceProblems#RAM) that optimal amount of RAM for SOLR is equal to index size. This is lets say the ideal case to have everything in memory. I wrote that page. We plan to have small installation with 2 nodes and 8shards. We'll have inside the cluster 100M of documents. We expect that each document will take 5kB to index. With in-memory index this would mean that those two nodes would require ~500GB RAM. This would mean 2x 256GB to have everything in memory. And those are really big machines... Is this calculation even correct in new Solr versions? And we do have a bit restricted problem: Our data are time based logs and we generally have a restricted search for last 3 months. Which will match let's say 10M of documents. How will this affect SOLR memory requirements? Will we still need to have the whole inverted indexes in memory? Or is there some internal optimization, which will ensure that only some part will need to be in memory? The questions: 1) Is the 500GB of memory reqs correct assumption? There are two things that Solr needs memory for. One is Solr's heap, which is memory directly used by Solr itself. The other is unused memory, which the operating system will use to cache data on disk. Solr performance is helped dramatically by the latter kind of memory. For *OPTIMAL* performance with a 500GB index, you need 500GB of memory for the OS to cache the data. This is memory that is not used by programs, including Solr's heap. For *good* performance, it's rare that you will need enough memory to cache the entire index. But I cannot tell you with any reliability how much of the index you must be able to cache. Some people are doing fine with only a few percent of their index cached. Others see terrible performance unless they can get 75 percent of the index cached. 2) Will the fact that we have time-based logs with majority of accesses to recent data only help? Yes, it most likely will help, and reduce your memory requirements. 3) Is there some best practice how to reduce required RAM in Solr? The biggest thing you can do is to reduce the size of the index, so there is less data that must be accessed for a query. The page you referenced lists some things you might be able to do to reduce Solr's heap requirements. If you reduce the heap requirements, then more of the server's memory available for caching. Thanks, Shawn
Re: Corrupt Index error on Target cluster
I've gotten incorrect checksums when upgrading solr versions across the cluster. Or in other words, when indexing into a mixed version cluster. Are you running mixed versions by chance? On Fri, Sep 7, 2018, 6:07 AM Susheel Kumar wrote: > Anyone has insight / have faced above errors ? > > On Thu, Sep 6, 2018 at 12:04 PM Susheel Kumar > wrote: > > > Hello, > > > > We had a running cluster with CDCR and there were some issues with > > indexing on Source cluster which got resolved after restarting the nodes > > (in my absence...) and now I see below errors on a shard at Target > > cluster. Any suggestions / ideas what could have caused this and whats > the > > best way to recover. > > > > Thnx > > > > Caused by: org.apache.solr.common.SolrException: Error opening new > searcher > > at > > org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2069) > > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2189) > > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1926) > > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1826) > > at > > > org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:127) > > at > > > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:310) > > at > > > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:296) > > at > > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173) > > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477) > > at > > > org.apache.solr.handler.PingRequestHandler.handlePing(PingRequestHandler.java:267) > > ... 34 more > > Caused by: org.apache.lucene.index.CorruptIndexException: Corrupted > > bitsPerDocBase: 6033 > > > (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/app/solr/data/COLL_shard8_replica1/data/index.20180903220548447/_9nsy.tvx"))) > > at > > > org.apache.lucene.codecs.compressing.CompressingStoredFieldsIndexReader.(CompressingStoredFieldsIndexReader.java:89) > > at > > > org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.(CompressingTermVectorsReader.java:126) > > at > > > org.apache.lucene.codecs.compressing.CompressingTermVectorsFormat.vectorsReader(CompressingTermVectorsFormat.java:91) > > at > > > org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:128) > > at > > org.apache.lucene.index.SegmentReader.(SegmentReader.java:74) > > at > > > org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:145) > > at > > > org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:197) > > at > > > org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:103) > > at > > org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:467) > > at > > org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:103) > > at > > org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:79) > > at > > > org.apache.solr.core.StandardIndexReaderFactory.newReader(StandardIndexReaderFactory.java:39) > > at > > org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2033) > > ... 43 more > > Suppressed: org.apache.lucene.index.CorruptIndexException: > > checksum failed (hardware problem?) : expected=e5bf0d15 actual=21722825 > > > (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/app/solr/data/COLL_shard8_replica1/data/index.20180903220548447/_9nsy.tvx"))) > > at > > org.apache.lucene.codecs.CodecUtil.checkFooter(CodecUtil.java:419) > > at > > org.apache.lucene.codecs.CodecUtil.checkFooter(CodecUtil.java:462) > > at > > > org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.(CompressingTermVectorsReader.java:131) > > ... 54 more > > >
Re: Keystore and Password is displayed in Dashboard
Hi, Which version of Solr are you using? AFAIK this was fixed in Solr 6.6: https://issues.apache.org/jira/browse/SOLR-10076 . However, prior to Solr 7.0, sensitive property redaction was not enabled by default. To enable, set system property solr.redaction.system.enabled=true . -- Steve www.lucidworks.com > On Sep 7, 2018, at 9:16 AM, cyndefromva wrote: > > I have configured my solr instance to use ssl and it's working as expected. > However, the keystore password is being displayed when I access the Solr > Dashboard. Is there a way to hide this? > > > > -- > Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: MLT in Cloud Mode - Not Returning Fields?
Looks like this is indeed a bug My colleague debugged this behavior and it turns out that Solr only requests id and score from the shards, and not the user-specified field list. You can see that on this line https://github.com/apache/lucene-solr/blob/branch_7_4/solr/core/src/java/org/apache/solr/handler/component/MoreLikeThisComponent.java#L342 Happy to create a Jira ticket -Doug On Mon, Sep 3, 2018 at 5:23 AM Charlie Hull wrote: > On 31/08/2018 19:36, Doug Turnbull wrote: > > Hello, > > > > We're working on a Solr More Like This project (Solr 6.6.2), using the > More > > Like This searchComponent. What we note is in standalone Solr, when we > > request MLT using the search component, we get every more like this > > document fully formed with complete fields in the moreLikeThis section. > > Hey Doug, > > IIRC there wasn't a lot of support for MLT in cloud mode a few years > ago, and there are certainly still a few open issues around cloud support: > https://issues.apache.org/jira/browse/SOLR-4414 > https://issues.apache.org/jira/browse/SOLR-5480 > Maybe there are some hints in the ticket comments about different ways > to do what you want. > > Cheers > > Charlie > > > > > In cloud, however, with the exact same query and config, we only get the > > doc ids under "moreLikeThis" requiring us to fetch the metadata > associated > > with each document. > > > > I can't easily share an example due to confidentiality, but I want to > check > > if we're missing something? Documentation doesn't mention any > limitations. > > The only interesting note I've found is this one which points to a > > potential difference in behavior > > > >> The Cloud MLT Query Parser uses the realtime get handler to retrieve > the > > fields to be mined for keywords. Because of the way the realtime get > > handler is implemented, it does not return data for fields populated > using > > copyField. > > > > https://stackoverflow.com/a/46307140/8123 > > > > Any thoughts? > > > > -Doug > > > > > -- > Charlie Hull > Flax - Open Source Enterprise Search > > tel/fax: +44 (0)8700 118334 <+44%20870%20011%208334> > mobile: +44 (0)7767 825828 <+44%207767%20825828> > web: www.flax.co.uk > -- CTO, OpenSource Connections Author, Relevant Search http://o19s.com/doug
Solr memory reqs for time-sorted data
Hi, I found on wiki (https://wiki.apache.org/solr/SolrPerformanceProblems#RAM) that optimal amount of RAM for SOLR is equal to index size. This is lets say the ideal case to have everything in memory. We plan to have small installation with 2 nodes and 8shards. We'll have inside the cluster 100M of documents. We expect that each document will take 5kB to index. With in-memory index this would mean that those two nodes would require ~500GB RAM. This would mean 2x 256GB to have everything in memory. And those are really big machines... Is this calculation even correct in new Solr versions? And we do have a bit restricted problem: Our data are time based logs and we generally have a restricted search for last 3 months. Which will match let's say 10M of documents. How will this affect SOLR memory requirements? Will we still need to have the whole inverted indexes in memory? Or is there some internal optimization, which will ensure that only some part will need to be in memory? The questions: 1) Is the 500GB of memory reqs correct assumption? 2) Will the fact that we have time-based logs with majority of accesses to recent data only help? 3) Is there some best practice how to reduce required RAM in Solr? Thanks in advance! Pavel Side note: We were thinking about DB partitioning based on Time Routed Aliases, but unfortunately we need to ensure disaster recovery through a bad network connection. And TRA and Cross Data Center Replication are not compatible. (CDCR requires static number of cores, while TRA creates cores dynamically).
RE: Re: Multi word searching is not working getting random search results
Hi Susheel, Thanks for your response. Well If I use plural also it is giving the same results and the Solr is not finding the 2 different words that is in the same page. I am trying to figure out how to pass the query to find the results while doing multi word search in same page. Thanks, Jagadish M. -Original Message- From: Susheel Kumar [mailto:susheel2...@gmail.com] Sent: Thursday, September 6, 2018 3:01 PM To: solr-user@lucene.apache.org Subject: [EXTERNAL] Re: Multi word searching is not working getting random search results How about you search with Intermodal Schedules (plural) & try phrase slop for better control on relevancy order https://lucene.apache.org/solr/guide/6_6/the-extended-dismax-query-parser.html On Thu, Sep 6, 2018 at 12:10 PM Muddapati, Jagadish < jagadish.muddap...@nscorp.com> wrote: > Label: newbie > Environment: > I am currently running solr on Linux platform. > > NAME="Red Hat Enterprise Linux Server" > VERSION="7.5" > > openjdk version "1.8.0_181" > > AEM version: 6.2 > > I recently integrate solr to AEM and when i do search for multiple > words the search results are getting randomly. > > search words: Intermodal schedule > Results: First solr displaying the search results related to > Intermodal and after few pages I am seeing the serch term schedule > related pages randomly. I am not getting the results related to multi words > on the page. > For example: I am not seeing the results like [Terminals & Schedules | > Intermodal | Shipping Options ... page on starting and getting random > results and the [Terminals & Schedules | Intermodal | Shipping Options ... > page displaying after the 40 results. > > Here is the query on browser URL: > > http://secure-web.cisco.com/1YHJLnjxg38Ifakaan8ZFPHodNi4HbrQLcmhM5kTSr > x5jOf2uH75_wUtu7AFAEP7KxUB5b6CrixqFq_S0f7HrOh3XWjXQ-Ulh0lCLiuuIfRXn0SG > Cb4RFSBeyoQrKVcF6qdneCM8cn12qIiYp4k48VW-L2yHoLpFq3on--oSxJjw9n0ELt4iIo > aT942NX3uB1ugWvTByJNd7dD2uv0FqAv3uLqPHCGs6apleaaXiLWjwnRO6f_yAMNTnfRy3 > QfUOyEi4KyrULJfGTS6Hs8hNewO86LHWjh6jbxMYJg_sbi8epNC0ptsjtDTj-6YOzHx7w/ > http%3A%2F%2Ftest-servername%2Fcontent%2Fnscorp%2Fen%2Fsearch-results. > html%3Fstart%3D0%26q%3DIntermodal%2BSchedule > < > http://secure-web.cisco.com/1LoQdHzbU9XRxNqP3SAui7hMZDrw5utvOmhYY6FBfl > yIR4Kn1pbTM5fxobgygd2KkgQ3MkCOlNCXtFBX48duxR6YmWb-pXqUKJavqTvE4V_9PpVm > tJbE2B1bKJGFOXlEUqk2V4_k5NgmGIk4cxJHbOb0KWCxj9XD61t210oPjzOZUQnwzdZRnF > jyAvNImN3Hmm8TIM_StSq5SnFeabqUcnhP73OIJF43s-Wt5tpPqobgdcAEEjf9Fy6oPivN > 26n-AFiMOMveKIqiwxgX1NDgW1hDFIiuyM5bVr-JnXgXUuCrMHZxRZsDE4jthLDtJ44fb/ > http%3A%2F%2Fservername%2Fcontent%2Fnscorp%2Fen%2Fsearch-results.html% > 3Fstart%3D0%26q%3DIntermodal%2BSchedule > > > > I am using solr version 7.4 > > Thanks, > Jagadish M. > > >
Keystore and Password is displayed in Dashboard
I have configured my solr instance to use ssl and it's working as expected. However, the keystore password is being displayed when I access the Solr Dashboard. Is there a way to hide this? -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: Corrupt Index error on Target cluster
Anyone has insight / have faced above errors ? On Thu, Sep 6, 2018 at 12:04 PM Susheel Kumar wrote: > Hello, > > We had a running cluster with CDCR and there were some issues with > indexing on Source cluster which got resolved after restarting the nodes > (in my absence...) and now I see below errors on a shard at Target > cluster. Any suggestions / ideas what could have caused this and whats the > best way to recover. > > Thnx > > Caused by: org.apache.solr.common.SolrException: Error opening new searcher > at > org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2069) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2189) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1926) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1826) > at > org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:127) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:310) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:296) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477) > at > org.apache.solr.handler.PingRequestHandler.handlePing(PingRequestHandler.java:267) > ... 34 more > Caused by: org.apache.lucene.index.CorruptIndexException: Corrupted > bitsPerDocBase: 6033 > (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/app/solr/data/COLL_shard8_replica1/data/index.20180903220548447/_9nsy.tvx"))) > at > org.apache.lucene.codecs.compressing.CompressingStoredFieldsIndexReader.(CompressingStoredFieldsIndexReader.java:89) > at > org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.(CompressingTermVectorsReader.java:126) > at > org.apache.lucene.codecs.compressing.CompressingTermVectorsFormat.vectorsReader(CompressingTermVectorsFormat.java:91) > at > org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:128) > at > org.apache.lucene.index.SegmentReader.(SegmentReader.java:74) > at > org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:145) > at > org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:197) > at > org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:103) > at > org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:467) > at > org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:103) > at > org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:79) > at > org.apache.solr.core.StandardIndexReaderFactory.newReader(StandardIndexReaderFactory.java:39) > at > org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2033) > ... 43 more > Suppressed: org.apache.lucene.index.CorruptIndexException: > checksum failed (hardware problem?) : expected=e5bf0d15 actual=21722825 > (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/app/solr/data/COLL_shard8_replica1/data/index.20180903220548447/_9nsy.tvx"))) > at > org.apache.lucene.codecs.CodecUtil.checkFooter(CodecUtil.java:419) > at > org.apache.lucene.codecs.CodecUtil.checkFooter(CodecUtil.java:462) > at > org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.(CompressingTermVectorsReader.java:131) > ... 54 more >
Re: SynonimGraphFilter expands wrong synonims
And as you probably already checked, inserting the proper
*tokenizerFactory* also expands the right synonym line:
q = (body:"Cytosolic 5'-nucleotidase II" OR body:"EC 3.1.3.5")
parsedQuery = SpanOrQuery(spanOr([body:p49902, spanNear([body:cytosol,
body:purin, body:5, body:nucleotidas], 0, true), spanNear([body:ec,
body:3.1.3.5], 0, true), spanNear([body:cytosol, body:5,
body:nucleotidas, body:ii], 0, true)])) SpanOrQuery(spanOr([body:p49902,
spanNear([body:cytosol, body:purin, body:5, body:nucleotidas], 0, true),
spanNear([body:cytosol, body:5, body:nucleotidas, body:ii], 0, true),
spanNear([body:ec, body:3.1.3.5], 0, true)]))
Best,
Andrea
On 05/09/18 16:10, Andrea Gazzarini wrote:
You're right, my answer forgot to mention the *tokenizerFactory*
parameter that you can add in the filter declaration. But, differently
from what you think the default tokenizer used for parsing the
synonyms _is not_ the tokenizer of the current analyzer
(StandardTokenizer in your example) but WhitespaceTokenizer. See here
[1] for a complete description of the filter capabilities.
So instead of switching the analyzer tokenizer you could also add a
tokenizerFactory="solr.StandardTokenizerFactory" in the synonym filter
declaration.
Best,
Andrea
[1]
https://lucene.apache.org/solr/guide/6_6/filter-descriptions.html#FilterDescriptions-SynonymGraphFilter
On 05/09/2018 15:58, Danilo Tomasoni wrote:
Hi Andrea,
thank you for your answer.
About the second question: The standardTokenizer should be applied
also to the phrase query, so the ' and - symbols should be removed
even there, and this should allow a match in the synonim file isn't it?
With an example:
in phrase query:
"Cytosolic 5'-nucleotidase II" -> standardTokenizer -> Cytosolic, 5,
nucleotidase, II
in synonym parsing:
...,Cytosolic 5'-nucleotidase II,... -> standardTokenizer ->
Cytosolic, 5, nucleotidase, II
So the two graphs should match.. or I'm wrong?
Thank you
Danilo
ody:On 05/09/2018 13:23, Andrea Gazzarini wrote:
Hi Danilo,
let's see if this can help you (I'm sorry for the poor debugging,
I'm reading & writing from my mobile): the first issue should have
something to do with synonym overlapping and since I'm very curious
about what it is happening, I will be more precise when I will be in
front of a laptop.
The second: I guess the main problem is the StandardTokenizer, which
removes the ' and - symbols. That should be the reason why you don't
have any synonym detection. You should replace it with a
WhitespaceTokenizer but, be aware that if you do that, the
apostrophe in the document ( ′ ) is not the same symbol ( ' ) you've
used in the query and in the synonyms file, so you need to replace
it somewhere (in the document and/or in the query) otherwise you
won't have any match.
HTH
Gazza
On 05/09/2018 12:19, Danilo Tomasoni wrote:
Hello to all,
I have an issue related to synonimgraphfilter expanding the wrong
synonims for a phrase-term at query time.
I have a dictionary with the following lines
P49902,Cytosolic purine 5'-nucleotidase,EC 3.1.3.5,Cytosolic
5'-nucleotidase II
A8K9N1,Glucosidase\, beta\, acid 3,Cytosolic,Glucosidase\, beta\,
acid 3,Cytosolic\, isoform CRA_b,cDNA FLJ78196\, highly similar to
Homo sapiens glucosidase\, beta\, acid 3,cytosolic,GBA3\,
mRNA,cDNA\, FLJ93688\, Homo sapiens glucosidase\, beta\, acid
3,cytosolic,GBA3\, mRNA
and two documents
{"body":"8. The method of claim 6 wherein said method inhibits at
least one 5′-nucleotidase chosen from cytosolic 5′-nucleotidase II
(cN-II), cytosolic 5′-nucleotidase IA (cN-IA), cytosolic
5′-nucleotidase IB (cN-IB), cytosolic 5′-nucleotidase IMA
(cN-IIIA), cytosolic 5′-nucleotidase NIB (cN-IIIB),
ecto-5′-nucleotidase (eN, CD73), cytosolic 5′(3′)-deoxynucleotidase
(cdN) and mitochondrial 5′(3′)-deoxynucleotidase (mdN)."}
{"body":"Trichomonosis caused by the flagellate protozoan
Trichomonas vaginalis represents the most prevalent nonviral
sexually transmitted disease worldwide (WHO-DRHR 2012). In women,
the symptoms are cyclic and often worsen around the menstruation
period. In men, trichomonosis is largely asymptomatic and these men
are considered to be carriers of T. vaginalis (Petrin et al. 1998).
This infection has been associated with birth outcomes (Klebanoff
et al. 2001), infertility (Grodstein et al. 1993), cervical and
prostate cancer (Viikki et al. 2000, Sutcliffe et al. 2012) and
pelvic inflammatory disease (Cherpes et al. 2006). Importantly, T.
vaginalis is a co-factor in human immunodeficiency virus
transmission and acquisition (Sorvillo et al. 2001, Van Der Pol et
al. 2008). Therefore, it is important to study the host-parasite
relationship to understand T. vaginalis infection and pathogenesis.
Colonisation of the mucosa by T. vaginalis is a complex multi-step
process that involves distinct mechanisms (Alderete et al. 2004).
The parasite interacts with mucin (Lehker & Sweeney 1999), adheres
to vaginal
Solr CDCR replication not working
I have setup two solr cloud instances in two different Datacenters Target solr
cloud machine is copy of source machine with basicAuth enabled on them. I am
unable to see any replication on target.
Solr Version :6.6.3
I have done config changes as suggested on
https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
Source Config Changes
...
serverIP:2181,serverIP:2182,serverIP:2183
sitecore_master_index
sitecore_master_index
8
1000
128
1000
${solr.ulog.dir:}
${solr.ulog.numVersionBuckets:65536}
${solr.autoCommit.maxTime:15000}
false
${solr.autoSoftCommit.maxTime:-1}
...
Target Config Changes
...
disabled
cdcr-proc-chain
${solr.ulog.dir:}
${solr.ulog.numVersionBuckets:65536}
${solr.autoCommit.maxTime:15000}
false
${solr.autoSoftCommit.maxTime:-1}
...
Below are logs from Source target.
ERROR (zkCallback-4-thread-2-processing-n:sourceIP:8983_solr) [ ]
o.a.s.c.s.i.CloudSolrClient Request to collection collection1 failed due to
(510) org.apache.solr.common.SolrException: Could not find a healthy node to
handle the request., retry? 5
2018-09-07 10:36:14.295 WARN
(zkCallback-4-thread-2-processing-n:sourceIP:8983_solr) [ ]
o.a.s.h.CdcrReplicatorManager Unable to instantiate the log reader for target
collection collection1
org.apache.solr.common.SolrException: Could not find a healthy node to handle
the request.
at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1377)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1134)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at
org.apache.solr.handler.CdcrReplicatorManager.getCheckpoint(CdcrReplicatorManager.java:196)
at
org.apache.solr.handler.CdcrReplicatorManager.initLogReaders(CdcrReplicatorManager.java:159)
at
org.apache.solr.handler.CdcrReplicatorManager.stateUpdate(CdcrReplicatorManager.java:134)
at
org.apache.solr.handler.CdcrStateManager.callback(CdcrStateManager.java:36)
at
org.apache.solr.handler.CdcrLeaderStateManager.setAmILeader(CdcrLeaderStateManager.java:108)
at
org.apache.solr.handler.CdcrLeaderStateManager.checkIfIAmLeader(CdcrLeaderStateManager.java:95)
at
org.apache.solr.handler.CdcrLeaderStateManager.access$400(CdcrLeaderStateManager.java:40)
at
org.apache.solr.handler.CdcrLeaderStateManager$LeaderStateWatcher.process(CdcrLeaderStateManager.java:150)
at
org.apache.solr.common.cloud.SolrZkClient$3.lambda$process$0(SolrZkClient.java:269)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
2018-09-07 10:36:14.310 INFO
(coreLoadExecutor-8-thread-3-processing-n:sourceIP:8983_solr) [ ]
o.a.s.c.SolrConfig Using Lucene MatchVersion: 6.6.3
2018-09-07 10:36:14.315 INFO
(zkCallback-4-thread-1-processing-n:sourceIP:8983_solr) [ ]
o.a.s.c.c.ZkStateReader A cluster state change: [WatchedEvent
state:SyncConnected type:NodeDataChanged
path:/collections/collection1/state.json] for collection [sitecore] has
occurred - updating... (live nodes size: [1])
2018-09-07 10:36:14.343 WARN
(cdcr-replicator-211-thread-1-processing-n:sourceIP:8983_solr) [ ]
o.a.s.h.CdcrReplicator Log reader for target collection1 is not initialised, it
will be ignored.
I am unable to see anything on target. It will be great if someone can help me
in it.
Can you help in this?
Regards
Mrityunjaya
Solr CDCR replication not working
I have setup two solr cloud instances in two different Datacenters Target solr
cloud machine is copy of source machine with basicAuth enabled on them. I am
unable to see any replication on target.
Solr Version :6.6.3
I have done config changes as suggested on
https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
Source Config Changes
...
serverIP:2181,serverIP:2182,serverIP:2183
sitecore_master_index
sitecore_master_index
8
1000
128
1000
${solr.ulog.dir:}
${solr.ulog.numVersionBuckets:65536}
${solr.autoCommit.maxTime:15000}
false
${solr.autoSoftCommit.maxTime:-1}
...
Target Config Changes
...
disabled
cdcr-proc-chain
${solr.ulog.dir:}
${solr.ulog.numVersionBuckets:65536}
${solr.autoCommit.maxTime:15000}
false
${solr.autoSoftCommit.maxTime:-1}
...
Below are logs from Source target.
ERROR (zkCallback-4-thread-2-processing-n:sourceIP:8983_solr) [ ]
o.a.s.c.s.i.CloudSolrClient Request to collection collection1 failed due to
(510) org.apache.solr.common.SolrException: Could not find a healthy node to
handle the request., retry? 5
2018-09-07 10:36:14.295 WARN
(zkCallback-4-thread-2-processing-n:sourceIP:8983_solr) [ ]
o.a.s.h.CdcrReplicatorManager Unable to instantiate the log reader for target
collection collection1
org.apache.solr.common.SolrException: Could not find a healthy node to handle
the request.
at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1377)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1134)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at
org.apache.solr.handler.CdcrReplicatorManager.getCheckpoint(CdcrReplicatorManager.java:196)
at
org.apache.solr.handler.CdcrReplicatorManager.initLogReaders(CdcrReplicatorManager.java:159)
at
org.apache.solr.handler.CdcrReplicatorManager.stateUpdate(CdcrReplicatorManager.java:134)
at
org.apache.solr.handler.CdcrStateManager.callback(CdcrStateManager.java:36)
at
org.apache.solr.handler.CdcrLeaderStateManager.setAmILeader(CdcrLeaderStateManager.java:108)
at
org.apache.solr.handler.CdcrLeaderStateManager.checkIfIAmLeader(CdcrLeaderStateManager.java:95)
at
org.apache.solr.handler.CdcrLeaderStateManager.access$400(CdcrLeaderStateManager.java:40)
at
org.apache.solr.handler.CdcrLeaderStateManager$LeaderStateWatcher.process(CdcrLeaderStateManager.java:150)
at
org.apache.solr.common.cloud.SolrZkClient$3.lambda$process$0(SolrZkClient.java:269)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
2018-09-07 10:36:14.310 INFO
(coreLoadExecutor-8-thread-3-processing-n:sourceIP:8983_solr) [ ]
o.a.s.c.SolrConfig Using Lucene MatchVersion: 6.6.3
2018-09-07 10:36:14.315 INFO
(zkCallback-4-thread-1-processing-n:sourceIP:8983_solr) [ ]
o.a.s.c.c.ZkStateReader A cluster state change: [WatchedEvent
state:SyncConnected type:NodeDataChanged
path:/collections/collection1/state.json] for collection [sitecore] has
occurred - updating... (live nodes size: [1])
2018-09-07 10:36:14.343 WARN
(cdcr-replicator-211-thread-1-processing-n:sourceIP:8983_solr) [ ]
o.a.s.h.CdcrReplicator Log reader for target collection1 is not initialised, it
will be ignored.
I am unable to see anything on target. It will be great if someone can help me
in it.
Can you help in this?
Regards
Mrityunjaya
Re: regarding 'sharedlib' in solr
Usually sharedlib is a path to a directory that contains .jar files, then added to the Solr classpath. For example I've used sharedlib to deploy a jar where is a the implementation of a custom plugin for Solr that extends ExtendedDismaxQParserPlugin. On Fri, Sep 7, 2018 at 12:57 PM Andrea Gazzarini wrote: > Hi, please expand a bit. Specifically: > > * what are those text files? Configuration files? You want something > like a central point where to manage things like stopwords, synonyms? > * I don't think the shareLib folder has been created for this usage. > However, please post the complete message you're receiving, together > with the stacktrace, if available. > > Andrea > > On 07/09/18 12:02, Abhishek Agarwal wrote: > > Hi, > > > > I want to share a folder containing text files in solr among different > > cores so if the folder is updated ,so it would reflect in all the cores > > having path specified but the problem I am facing is that , i am using > > sharedlib in solr.xml and specifying the default path there.And also I am > > updating schema.xml of my core but when I am loading core ,it is giving > > error 'unsafe loading' .and not getting reload. Please help me in this. > > > > -- Vincenzo D'Amore
Re: regarding 'sharedlib' in solr
Hi, please expand a bit. Specifically: * what are those text files? Configuration files? You want something like a central point where to manage things like stopwords, synonyms? * I don't think the shareLib folder has been created for this usage. However, please post the complete message you're receiving, together with the stacktrace, if available. Andrea On 07/09/18 12:02, Abhishek Agarwal wrote: Hi, I want to share a folder containing text files in solr among different cores so if the folder is updated ,so it would reflect in all the cores having path specified but the problem I am facing is that , i am using sharedlib in solr.xml and specifying the default path there.And also I am updating schema.xml of my core but when I am loading core ,it is giving error 'unsafe loading' .and not getting reload. Please help me in this.
regarding 'sharedlib' in solr
Hi, I want to share a folder containing text files in solr among different cores so if the folder is updated ,so it would reflect in all the cores having path specified but the problem I am facing is that , i am using sharedlib in solr.xml and specifying the default path there.And also I am updating schema.xml of my core but when I am loading core ,it is giving error 'unsafe loading' .and not getting reload. Please help me in this. -- Thanks, Abhishek Agarwal
RE: Replicas do not come up after nodes are restarted in SOLR cloud
Hi Shawn, Thanks for the insights. I verified the points you mentioned, Socket timeout defaults weren't changed. Both nodes (two different hosts, windows OS ) are given heap space of 4GB. They are having two Collections as of now. One is without replicas but with 8 shards on each node. One is with replicas and 1 shard. (both replicas are down) I monitored the application for some time and I do not see obvious memory issues or prolonged garbage collection. Also, the nodes are registered with their hostnames in the collection. Thanks, Sudip -Original Message- From: Shawn Heisey [mailto:elyog...@elyograg.org] Sent: Wednesday, September 05, 2018 7:23 PM To: solr-user@lucene.apache.org Subject: Re: Replicas do not come up after nodes are restarted in SOLR cloud On 9/5/2018 2:55 AM, Sudip Mukherjee wrote: > I have a 2 node SOLR (7.x) cloud cluster on which I have collection > with replicas ( replicationFactor = 2, shard = 1 ). I am seeing that the > replicas do not come up ( state is "down") when both nodes are restarted. > From the "legend" in Graph section, I see that the replicas are in "recovery > failed" state. > Caused by: java.net.SocketTimeoutException: Read timed out > at java.net.SocketInputStream.socketRead0(Native Method) > at > java.net.SocketInputStream.socketRead(SocketInputStream.java:116) Have you changed the socket timeout in Solr's config? The socket timeout for internode requests defaults to 60 seconds. If something happened that prevented a Solr server from responding within 60 seconds, then there's something *REALLY* wrong. My best guess is that your Solr heap is too small, causing Java to spend almost all of its time doing garbage collection. Or that a too-small heap has caused one of your servers to experience an OutOfMemoryError, which on non-Windows systems will result in the Solr process being killed. Some questions in case that's not it: How many collections do you have on this setup? In the admin UI (Cloud tab), what hostname do your nodes show they are registered as? If it's localhost, that's going to be a problem for a 2-node cluster. Thanks, Shawn ***Legal Disclaimer*** "This communication may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message by mistake, please advise the sender by reply email and delete the message. Thank you." **
Solr upgrade issues
Hi,
We are in the process of upgrading Solr from solr 5.2.1 to solr 7.4.0 and I'm
facing below issues. Please help me in resolving.
1)HttpSolrClient tempClient = new
HttpSolrClient.Builder("http://localhost:8983/solr";).build();
ModifiableSolrParams params = new
ModifiableSolrParams();
params.set("qt", "/dataimport");
params.set("command", "delta-import");
params.set("clean", "false");
params.set("commit", "true");
params.set("entity", "collection1");
GenericSolrRequest req = new
GenericSolrRequest(SolrRequest.METHOD.POST, "/select" ,params);
tempClient.request(req," collection1");
In the back end I have schedulers which call delta-import on my collection1.
This used to work before in 5.2.1 and when this code gets executed, I could see
the delta-import was being run. Now in 7.4.0, I'm not able to see the
delta-import running. Does solr restricts taking external requests in 7.4.0?
2) Also in Jetty.xml , I have configured the datasource as below
java:comp/env/jdbc/tssindex
thin
jdbc:oracle:thin:@localhost:1521:xe
X
X
How to fetch the data source configured in this xml
(java:comp/env/jdbc/tssindex)
Earlier I used to fetch from tomcat context xml as below:
Context initContext = new InitialContext();
DataSource ds = null;
Context webContext =
(Context)initContext.lookup("java:/comp/env");
ds = (DataSource) webContext.lookup("jdbc/tssindex");
How to fetch it in jetty.
Thanks in advance,
Srinivas kashyap
Re: Solr range faceting
Thanks Erick,
The field is defined as a pfloat.
I took your advice and tried smaller result range and the counts look good. I
might try an index rebuild I’m wondering if the data has somehow been corrupted
by a combination of old and new index mappings.
Thanks again for your assistance.
"responseHeader":{
"zkConnected":true,
"status":0,
"QTime":7},
"response":{"numFound":3,"start":0,"docs":[
{
"Value":34.0},
{
"Value":34.0},
{
"Value":34.0}]
},
"facet_counts":
"facet_queries":{},
"facet_ranges":{
"Value:{
"counts":[
"0.0",3],
"gap":100.0,
"before":0,
"after":0,
"between":3,
"start":0.0,
"end":2000.0}}
From: Erick Erickson
Sent: Friday, 7 September 2018 12:54:48 PM
To: solr-user
Subject: Re: Solr range faceting
Indeed this doesn't look right. By my count, you're missing 599 counts
you'd expect in that range, although the after and between numbers
total the numFound.
What kind of a field is Value? Given the number of docs missing, I'd
guess you could get the number of docs down really small and post
them. Something like
values 1, 2, 3, 4, 5,
and your range query so we could try it.
What is the fieldType definition and field for Value?
And finally, do you get different results if you use json faceting?
Best,
Erick
On Thu, Sep 6, 2018 at 5:51 PM Dwane Hall wrote:
>
> Thanks Jan that has fixed the bucket issue but I'm a little confused at why
> zero counts exist for some buckets when they appear to be values in them?
>
> "response":{"numFound":869,"start":0,"docs":[
> {
> "Value":9475.08},
> {
> "Value":780.0},
> {
> "Value":9475.08},
> {
> "Value":1000.0},
> {
> "Value":50.0},
> {
> "Value":50.0},
> {
> "Value":0.0},
> {
> "Value":800.0},
> {
> "Value":0.0},
> {
> "Value":1000.0},
> {
> "Value":1000.0},
> {
> "Value":5000.0},
> {
> "Value":2000.0},
> {
>"Value":4000.0},
> {
> "Value":1500.0},
> {
> "Value":0.0},
> {
> "Value":1.0},
> {
> "Value":5000.0},
> {
> "Value":1000.0},
> {
> "Value":0.0},
> {
> "Value":1200.0},
> {
> "Value":9000.0},
> {
> "Value":1500.0},
> {
> "Value":1.0},
> {
> "Value":5000.0},
> {
> "Value":4000.0},
> {
> "Value":5000.0},
> {
> "Value":5000.0},
> {
> "Value":1.0},
> {
> "Value":1000.0}]
> },
>
> "facet_counts":{
> "facet_queries":{},
> "facet_ranges":{
> "Value":{
> "counts":[
> "0.0",9,
> "100.0",0,
> "200.0",0,
> "300.0",0,
> "400.0",80,
> "500.0",0,
> "600.0",0,
> "700.0",69,
> "800.0",0,
> "900.0",0,
> "1000.0",0,
> "1100.0",0,
> "1200.0",0,
> "1300.0",0,
> "1400.0",0,
> "1500.0",0,
> "1600.0",0,
> "1700.0",0,
> "1800.0",0,
> "1900.0",9],
> "gap":100.0,
> "before":0,
> "after":103,
> "between":766,
> "start":0.0,
> "end":2000.0}
>
> Cheers,
>
> Dwane
>
> From: Jan H?ydahl
> Sent: Friday, 7 September 2018 9:23:44 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Solr range faceting
>
> Try facet.minCount=0
>
> Jan
>
> > 7. sep. 2018 kl. 01:07 skrev Dwane Hall :
> >
> > Good morning Solr community. I'm having a few facet range issues for which
> > I'd appreciate some advice when somebody gets a spare couple of minutes.
> >
> > Environment
> > Solr Cloud (7.3.1)
> > Single Shard Index, No replicas
> >
> > Facet Configuration (I'm using the request params API and useParams at
> > runtime)
> > "facet":"true",
> > "facet.mincount":1,
> > "facet.missing":"false",
> > "facet.range":"Value"
> > "f.Value.facet.range.start":0.0,
> > "f.Value.facet.range.end":2000.0,
> > "f.Value.facet.range.gap":100,
> > "f.Value.facet.range.include":"edge",
> > "f.Value.facet.range.other":"all",
> >
> > My problem
> > With my range facet configuration I'm expecting to see a facet range entry
> > for every 'step' (100 in my case) between my facet.range.start and
> > facet.range.end settings. Something like the following 0.0,100.0,200.0,
> > ...2000.0 with a sum of the number of values that occur between each range
> > step. This does not appear to be the case and in some instances I don't
> > appear to get counts for some range steps (800.0 and 1000.0 for example are
> > present in my result set range below but I don't get a range value facets
> > for these values?)
> >
