[jira] [Commented] (LUCENE-7976) Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of very large segments
[ https://issues.apache.org/jira/browse/LUCENE-7976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510541#comment-16510541 ] Erick Erickson commented on LUCENE-7976: bq. If we fix the above loop to not add the singleton merge unless it has deletes? I don't think so. Since this is common code, then it's quite possible that during forceMerge we assemble some segments that have no deletes due to maxMergeAtOnceExplicit that are still a fraction of maxMergedSegmentMB. These segments are eligible next pass to be merged even though they have no deleted documents. So we can't just omit them from the candidate up-front. bq. ...rename maxMergeAtonce to maxMergeAtOnce Done. Autocomplete strikes again, one misspelling and it propagates. bq. I.e. change true to bestTooLarge? I've no objection, but what's the functional difference? Just making sure there's not a typo there. bq. I think this logic is buggy? The more I look the more I think it's _always_ been buggy. Or at least should be restructured. Check me out on this. As far as I can tell, mergingBytes would be the exact same in the old code every time it was calculated. Every time through the loop for gathering the best merge, the code looks in the same infosSorted (which doesn't change) and starts from the same point every time (tooBigCount which doesn't change) and adds to mergingBytes if (and only if) the segment is in mergeContext.getMergingSegments() (which doesn't change). mergingBytes really just asks if the sum of all the segments that could be merged are currently being merged total more than maxMergedSegmentBytes. So I'll make the new code do the same thing. I can calculate that value outside the loop and just set it once. Or I'm missing something that'll be obvious when someone else points it out. > Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of > very large segments > - > > Key: LUCENE-7976 > URL: https://issues.apache.org/jira/browse/LUCENE-7976 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, > LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, > LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, > SOLR-7976.patch > > > We're seeing situations "in the wild" where there are very large indexes (on > disk) handled quite easily in a single Lucene index. This is particularly > true as features like docValues move data into MMapDirectory space. The > current TMP algorithm allows on the order of 50% deleted documents as per a > dev list conversation with Mike McCandless (and his blog here: > https://www.elastic.co/blog/lucenes-handling-of-deleted-documents). > Especially in the current era of very large indexes in aggregate, (think many > TB) solutions like "you need to distribute your collection over more shards" > become very costly. Additionally, the tempting "optimize" button exacerbates > the issue since once you form, say, a 100G segment (by > optimizing/forceMerging) it is not eligible for merging until 97.5G of the > docs in it are deleted (current default 5G max segment size). > The proposal here would be to add a new parameter to TMP, something like > (no, that's not serious name, suggestions > welcome) which would default to 100 (or the same behavior we have now). > So if I set this parameter to, say, 20%, and the max segment size stays at > 5G, the following would happen when segments were selected for merging: > > any segment with > 20% deleted documents would be merged or rewritten NO > > MATTER HOW LARGE. There are two cases, > >> the segment has < 5G "live" docs. In that case it would be merged with > >> smaller segments to bring the resulting segment up to 5G. If no smaller > >> segments exist, it would just be rewritten > >> The segment has > 5G "live" docs (the result of a forceMerge or optimize). > >> It would be rewritten into a single segment removing all deleted docs no > >> matter how big it is to start. The 100G example above would be rewritten > >> to an 80G segment for instance. > Of course this would lead to potentially much more I/O which is why the > default would be the same behavior we see now. As it stands now, though, > there's no way to recover from an optimize/forceMerge except to re-index from > scratch. We routinely see 200G-300G Lucene indexes at this point "in the > wild" with 10s of shards replicated 3 or more times. And that doesn't even > include having these over HDFS. > Alternatives welcome! Something like the above seems minimally invasive. A > new merge policy is
[jira] [Comment Edited] (LUCENE-8355) IW#writeSomeDocValuesUpdates might open a dropped segment
[
https://issues.apache.org/jira/browse/LUCENE-8355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510516#comment-16510516
]
Nhat Nguyen edited comment on LUCENE-8355 at 6/13/18 2:04 AM:
--
This test fails because IW#writeSomeDocValuesUpdates tries to open a dropped
segment. We obtain a queue of readers from readerPool#getReadersByRam, then
process each of them under IW lock. However, one of the segments of those
readers is dropped before we execute #writeFieldUpdates. This situation is
possible because we only acquire IW lock on each writeFieldUpdates not entirely
the method.
was (Author: dnhatn):
This test fails because IW#writeSomeDocValuesUpdates tries to open a dropped
segment. We obtain a queue of readers from readerPool#getReadersByRam, then
process each of them under IW lock. However, one of the segments of those
readers is dropped before we execute #writeFieldUpdates. This situation is
possible because we only acquire IW lock on each writeFieldUpdates not entirely
the method.
/cc [~simonwillnauer]
> IW#writeSomeDocValuesUpdates might open a dropped segment
> -
>
> Key: LUCENE-8355
> URL: https://issues.apache.org/jira/browse/LUCENE-8355
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
>Affects Versions: 7.4, master (8.0), 7.5
>Reporter: Nhat Nguyen
>Priority: Major
> Attachments: LUCENE-8355.patch
>
>
> {noformat}
>[junit4] Suite: org.apache.lucene.index.TestIndexWriterWithThreads
>[junit4] 2> Jun 12, 2018 9:09:00 AM
> com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
> uncaughtException
>[junit4] 2> WARNING: Uncaught exception in thread:
> Thread[Thread-927,5,TGRP-TestIndexWriterWithThreads]
>[junit4] 2> java.lang.AssertionError:
> org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
>[junit4] 2> at
> __randomizedtesting.SeedInfo.seed([F89419D754B7F340]:0)
>[junit4] 2> at
> org.apache.lucene.index.TestIndexWriterWithThreads.lambda$testUpdateSingleDocWithThreads$2(TestIndexWriterWithThreads.java:682)
>[junit4] 2> at java.lang.Thread.run(Thread.java:748)
>[junit4] 2> Caused by: org.apache.lucene.store.AlreadyClosedException:
> this IndexWriter is closed
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:663)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.getConfig(IndexWriter.java:982)
>[junit4] 2> at
> org.apache.lucene.index.RandomIndexWriter.maybeFlushOrCommit(RandomIndexWriter.java:198)
>[junit4] 2> at
> org.apache.lucene.index.RandomIndexWriter.updateDocument(RandomIndexWriter.java:273)
>[junit4] 2> at
> org.apache.lucene.index.TestIndexWriterWithThreads.lambda$testUpdateSingleDocWithThreads$2(TestIndexWriterWithThreads.java:679)
>[junit4] 2> ... 1 more
>[junit4] 2> Caused by: java.io.FileNotFoundException: _a_1.fnm in
> dir=RAMDirectory@641490af
> lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@7685b98b
>[junit4] 2> at
> org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:750)
>[junit4] 2> at
> org.apache.lucene.store.Directory.openChecksumInput(Directory.java:121)
>[junit4] 2> at
> org.apache.lucene.store.MockDirectoryWrapper.openChecksumInput(MockDirectoryWrapper.java:1072)
>[junit4] 2> at
> org.apache.lucene.codecs.lucene60.Lucene60FieldInfosFormat.read(Lucene60FieldInfosFormat.java:113)
>[junit4] 2> at
> org.apache.lucene.index.SegmentReader.initFieldInfos(SegmentReader.java:195)
>[junit4] 2> at
> org.apache.lucene.index.SegmentReader.(SegmentReader.java:97)
>[junit4] 2> at
> org.apache.lucene.index.ReadersAndUpdates.writeFieldUpdates(ReadersAndUpdates.java:536)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.writeSomeDocValuesUpdates(IndexWriter.java:610)
>[junit4] 2> at
> org.apache.lucene.index.FrozenBufferedUpdates.apply(FrozenBufferedUpdates.java:299)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.lambda$publishFrozenUpdates$3(IndexWriter.java:2586)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5056)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1596)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.softUpdateDocument(IndexWriter.java:1653)
>[junit4] 2> at
> org.apache.lucene.index.RandomIndexWriter.updateDocument(RandomIndexWriter.java:264)
>[junit4] 2> ... 2 more
>[junit4] 2>
>[junit4] 2> Jun 12, 2018 9:09:00 AM
>
[jira] [Commented] (LUCENE-8355) IW#writeSomeDocValuesUpdates might open a dropped segment
[
https://issues.apache.org/jira/browse/LUCENE-8355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510519#comment-16510519
]
Nhat Nguyen commented on LUCENE-8355:
-
/cc [~simonw]
> IW#writeSomeDocValuesUpdates might open a dropped segment
> -
>
> Key: LUCENE-8355
> URL: https://issues.apache.org/jira/browse/LUCENE-8355
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
>Affects Versions: 7.4, master (8.0), 7.5
>Reporter: Nhat Nguyen
>Priority: Major
> Attachments: LUCENE-8355.patch
>
>
> {noformat}
>[junit4] Suite: org.apache.lucene.index.TestIndexWriterWithThreads
>[junit4] 2> Jun 12, 2018 9:09:00 AM
> com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
> uncaughtException
>[junit4] 2> WARNING: Uncaught exception in thread:
> Thread[Thread-927,5,TGRP-TestIndexWriterWithThreads]
>[junit4] 2> java.lang.AssertionError:
> org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
>[junit4] 2> at
> __randomizedtesting.SeedInfo.seed([F89419D754B7F340]:0)
>[junit4] 2> at
> org.apache.lucene.index.TestIndexWriterWithThreads.lambda$testUpdateSingleDocWithThreads$2(TestIndexWriterWithThreads.java:682)
>[junit4] 2> at java.lang.Thread.run(Thread.java:748)
>[junit4] 2> Caused by: org.apache.lucene.store.AlreadyClosedException:
> this IndexWriter is closed
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:663)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.getConfig(IndexWriter.java:982)
>[junit4] 2> at
> org.apache.lucene.index.RandomIndexWriter.maybeFlushOrCommit(RandomIndexWriter.java:198)
>[junit4] 2> at
> org.apache.lucene.index.RandomIndexWriter.updateDocument(RandomIndexWriter.java:273)
>[junit4] 2> at
> org.apache.lucene.index.TestIndexWriterWithThreads.lambda$testUpdateSingleDocWithThreads$2(TestIndexWriterWithThreads.java:679)
>[junit4] 2> ... 1 more
>[junit4] 2> Caused by: java.io.FileNotFoundException: _a_1.fnm in
> dir=RAMDirectory@641490af
> lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@7685b98b
>[junit4] 2> at
> org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:750)
>[junit4] 2> at
> org.apache.lucene.store.Directory.openChecksumInput(Directory.java:121)
>[junit4] 2> at
> org.apache.lucene.store.MockDirectoryWrapper.openChecksumInput(MockDirectoryWrapper.java:1072)
>[junit4] 2> at
> org.apache.lucene.codecs.lucene60.Lucene60FieldInfosFormat.read(Lucene60FieldInfosFormat.java:113)
>[junit4] 2> at
> org.apache.lucene.index.SegmentReader.initFieldInfos(SegmentReader.java:195)
>[junit4] 2> at
> org.apache.lucene.index.SegmentReader.(SegmentReader.java:97)
>[junit4] 2> at
> org.apache.lucene.index.ReadersAndUpdates.writeFieldUpdates(ReadersAndUpdates.java:536)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.writeSomeDocValuesUpdates(IndexWriter.java:610)
>[junit4] 2> at
> org.apache.lucene.index.FrozenBufferedUpdates.apply(FrozenBufferedUpdates.java:299)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.lambda$publishFrozenUpdates$3(IndexWriter.java:2586)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5056)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1596)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.softUpdateDocument(IndexWriter.java:1653)
>[junit4] 2> at
> org.apache.lucene.index.RandomIndexWriter.updateDocument(RandomIndexWriter.java:264)
>[junit4] 2> ... 2 more
>[junit4] 2>
>[junit4] 2> Jun 12, 2018 9:09:00 AM
> com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
> uncaughtException
>[junit4] 2> WARNING: Uncaught exception in thread:
> Thread[Thread-928,5,TGRP-TestIndexWriterWithThreads]
>[junit4] 2> java.lang.AssertionError: java.io.FileNotFoundException:
> _a_1.fnm in dir=RAMDirectory@641490af
> lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@7685b98b
>[junit4] 2> at
> __randomizedtesting.SeedInfo.seed([F89419D754B7F340]:0)
>[junit4] 2> at
> org.apache.lucene.index.TestIndexWriterWithThreads.lambda$testUpdateSingleDocWithThreads$2(TestIndexWriterWithThreads.java:682)
>[junit4] 2> at java.lang.Thread.run(Thread.java:748)
>[junit4] 2> Caused by: java.io.FileNotFoundException: _a_1.fnm in
> dir=RAMDirectory@641490af
> lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@7685b98b
>[junit4]
[jira] [Created] (SOLR-12482) 'bin/solr config' claims success for failed operations
Steve Rowe created SOLR-12482:
-
Summary: 'bin/solr config' claims success for failed operations
Key: SOLR-12482
URL: https://issues.apache.org/jira/browse/SOLR-12482
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Steve Rowe
For example, after running {{bin/solr start -c}} and {{bin/solr create -c
mycoll}}:
{noformat}
$PROMPT$ bin/solr config -c mycoll -z localhost:9983 -property FOOBAR -value BAZ
[...]
POSTing request to Config API: http://192.168.1.12:8983/solr/mycoll/config
{"set-property":{"FOOBAR":"BAZ"}}
Successfully set-property FOOBAR to BAZ
{noformat}
But the {{FOOBAR}} property cannot be set via {{set-property}}, because it is
not on the editable properties whitelist in
{{EditableSolrConfigAttributes.json}}.
This is evident from the direct Config API call:
{noformat}
PROMPT$ curl -X POST -d '{set-property:{FOOBAR:BAZ}}'
{
"responseHeader":{
"status":0,
"QTime":1},
"errorMessages":[{
"set-property":{"FOOBAR":"BAZ"},
"errorMessages":["'FOOBAR' is not an editable property"]}],
"WARNING":"This response format is experimental. It is likely to change in
the future."}
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8355) IW#writeSomeDocValuesUpdates might open a dropped segment
Nhat Nguyen created LUCENE-8355:
---
Summary: IW#writeSomeDocValuesUpdates might open a dropped segment
Key: LUCENE-8355
URL: https://issues.apache.org/jira/browse/LUCENE-8355
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Affects Versions: 7.4, master (8.0), 7.5
Reporter: Nhat Nguyen
{noformat}
[junit4] Suite: org.apache.lucene.index.TestIndexWriterWithThreads
[junit4] 2> Jun 12, 2018 9:09:00 AM
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
uncaughtException
[junit4] 2> WARNING: Uncaught exception in thread:
Thread[Thread-927,5,TGRP-TestIndexWriterWithThreads]
[junit4] 2> java.lang.AssertionError:
org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
[junit4] 2>at
__randomizedtesting.SeedInfo.seed([F89419D754B7F340]:0)
[junit4] 2>at
org.apache.lucene.index.TestIndexWriterWithThreads.lambda$testUpdateSingleDocWithThreads$2(TestIndexWriterWithThreads.java:682)
[junit4] 2>at java.lang.Thread.run(Thread.java:748)
[junit4] 2> Caused by: org.apache.lucene.store.AlreadyClosedException:
this IndexWriter is closed
[junit4] 2>at
org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:663)
[junit4] 2>at
org.apache.lucene.index.IndexWriter.getConfig(IndexWriter.java:982)
[junit4] 2>at
org.apache.lucene.index.RandomIndexWriter.maybeFlushOrCommit(RandomIndexWriter.java:198)
[junit4] 2>at
org.apache.lucene.index.RandomIndexWriter.updateDocument(RandomIndexWriter.java:273)
[junit4] 2>at
org.apache.lucene.index.TestIndexWriterWithThreads.lambda$testUpdateSingleDocWithThreads$2(TestIndexWriterWithThreads.java:679)
[junit4] 2>... 1 more
[junit4] 2> Caused by: java.io.FileNotFoundException: _a_1.fnm in
dir=RAMDirectory@641490af
lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@7685b98b
[junit4] 2>at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:750)
[junit4] 2>at
org.apache.lucene.store.Directory.openChecksumInput(Directory.java:121)
[junit4] 2>at
org.apache.lucene.store.MockDirectoryWrapper.openChecksumInput(MockDirectoryWrapper.java:1072)
[junit4] 2>at
org.apache.lucene.codecs.lucene60.Lucene60FieldInfosFormat.read(Lucene60FieldInfosFormat.java:113)
[junit4] 2>at
org.apache.lucene.index.SegmentReader.initFieldInfos(SegmentReader.java:195)
[junit4] 2>at
org.apache.lucene.index.SegmentReader.(SegmentReader.java:97)
[junit4] 2>at
org.apache.lucene.index.ReadersAndUpdates.writeFieldUpdates(ReadersAndUpdates.java:536)
[junit4] 2>at
org.apache.lucene.index.IndexWriter.writeSomeDocValuesUpdates(IndexWriter.java:610)
[junit4] 2>at
org.apache.lucene.index.FrozenBufferedUpdates.apply(FrozenBufferedUpdates.java:299)
[junit4] 2>at
org.apache.lucene.index.IndexWriter.lambda$publishFrozenUpdates$3(IndexWriter.java:2586)
[junit4] 2>at
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5056)
[junit4] 2>at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1596)
[junit4] 2>at
org.apache.lucene.index.IndexWriter.softUpdateDocument(IndexWriter.java:1653)
[junit4] 2>at
org.apache.lucene.index.RandomIndexWriter.updateDocument(RandomIndexWriter.java:264)
[junit4] 2>... 2 more
[junit4] 2>
[junit4] 2> Jun 12, 2018 9:09:00 AM
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
uncaughtException
[junit4] 2> WARNING: Uncaught exception in thread:
Thread[Thread-928,5,TGRP-TestIndexWriterWithThreads]
[junit4] 2> java.lang.AssertionError: java.io.FileNotFoundException:
_a_1.fnm in dir=RAMDirectory@641490af
lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@7685b98b
[junit4] 2>at
__randomizedtesting.SeedInfo.seed([F89419D754B7F340]:0)
[junit4] 2>at
org.apache.lucene.index.TestIndexWriterWithThreads.lambda$testUpdateSingleDocWithThreads$2(TestIndexWriterWithThreads.java:682)
[junit4] 2>at java.lang.Thread.run(Thread.java:748)
[junit4] 2> Caused by: java.io.FileNotFoundException: _a_1.fnm in
dir=RAMDirectory@641490af
lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@7685b98b
[junit4] 2>at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:750)
[junit4] 2>at
org.apache.lucene.store.Directory.openChecksumInput(Directory.java:121)
[junit4] 2>at
org.apache.lucene.store.MockDirectoryWrapper.openChecksumInput(MockDirectoryWrapper.java:1072)
[junit4] 2>at
[jira] [Resolved] (SOLR-12481) update.autoCreateFields must be set via Config API command 'set-user-property', but 'bin/solr create' tells users to use the default action 'set-property', which fails b
[
https://issues.apache.org/jira/browse/SOLR-12481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe resolved SOLR-12481.
---
Resolution: Fixed
Assignee: Steve Rowe
Fix Version/s: 7.5
master (8.0)
> update.autoCreateFields must be set via Config API command
> 'set-user-property', but 'bin/solr create' tells users to use the default
> action 'set-property', which fails because the property is not editable
>
>
> Key: SOLR-12481
> URL: https://issues.apache.org/jira/browse/SOLR-12481
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12481.patch
>
>
> {{bin/solr}} advises default config users to turn off data driven schema
> functionality, e.g.:
> {noformat}
> PROMPT$ bin/solr start -c
> [...]
> Waiting up to 180 seconds to see Solr running on port 8983 [-]
> Started Solr server on port 8983 (pid=74200). Happy searching!
> PROMPT$ bin/solr create -c mycoll
> WARNING: Using _default configset with data driven schema functionality. NOT
> RECOMMENDED for production use.
> To turn off: bin/solr config -c mycoll -p 8983 -property
> update.autoCreateFields -value false
> {noformat}
> When I try the above command, it claims to succeed, but in fact silently
> fails - see below (I'll open a separate JIRA for the false success problem).
> When I attempt to set this property via the equivalent direct call to the
> Config API, it fails:
> {noformat}
> PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
> '{set-property: { update.autoCreateFields: false }}'
> {
> "responseHeader":{
> "status":0,
> "QTime":8},
> "errorMessages":[{
> "set-property":{"update.autoCreateFields":false},
> "errorMessages":["'update.autoCreateFields' is not an editable property"]}],
> "WARNING":"This response format is experimental. It is likely to change in
> the future."}
> {noformat}
> The correct action to use here is {{set-user-property}} rather than
> {{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the
> correct Config API command to an incorrect {{bin/solr config}} command.
> {{bin/solr}} should instead be printing (note the {{-action}} param):
> {noformat}
> To turn off: bin/solr config -c mycoll -action set-user-property -p [...]
> -property update.autoCreateFields -value false
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12481) update.autoCreateFields must be set via Config API command 'set-user-property', but 'bin/solr create' tells users to use the default action 'set-property', which fails
[
https://issues.apache.org/jira/browse/SOLR-12481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510513#comment-16510513
]
ASF subversion and git services commented on SOLR-12481:
Commit ca35c40f1b16aa79ac5b110ca922443c1185a7eb in lucene-solr's branch
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ca35c40 ]
SOLR-12481: update.autoCreateFields must be set via Config API command
'set-user-property', but 'bin/solr create' tells users to use the default
action 'set-property', which fails because the property is not editable
> update.autoCreateFields must be set via Config API command
> 'set-user-property', but 'bin/solr create' tells users to use the default
> action 'set-property', which fails because the property is not editable
>
>
> Key: SOLR-12481
> URL: https://issues.apache.org/jira/browse/SOLR-12481
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Priority: Major
> Attachments: SOLR-12481.patch
>
>
> {{bin/solr}} advises default config users to turn off data driven schema
> functionality, e.g.:
> {noformat}
> PROMPT$ bin/solr start -c
> [...]
> Waiting up to 180 seconds to see Solr running on port 8983 [-]
> Started Solr server on port 8983 (pid=74200). Happy searching!
> PROMPT$ bin/solr create -c mycoll
> WARNING: Using _default configset with data driven schema functionality. NOT
> RECOMMENDED for production use.
> To turn off: bin/solr config -c mycoll -p 8983 -property
> update.autoCreateFields -value false
> {noformat}
> When I try the above command, it claims to succeed, but in fact silently
> fails - see below (I'll open a separate JIRA for the false success problem).
> When I attempt to set this property via the equivalent direct call to the
> Config API, it fails:
> {noformat}
> PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
> '{set-property: { update.autoCreateFields: false }}'
> {
> "responseHeader":{
> "status":0,
> "QTime":8},
> "errorMessages":[{
> "set-property":{"update.autoCreateFields":false},
> "errorMessages":["'update.autoCreateFields' is not an editable property"]}],
> "WARNING":"This response format is experimental. It is likely to change in
> the future."}
> {noformat}
> The correct action to use here is {{set-user-property}} rather than
> {{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the
> correct Config API command to an incorrect {{bin/solr config}} command.
> {{bin/solr}} should instead be printing (note the {{-action}} param):
> {noformat}
> To turn off: bin/solr config -c mycoll -action set-user-property -p [...]
> -property update.autoCreateFields -value false
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12481) update.autoCreateFields must be set via Config API command 'set-user-property', but 'bin/solr create' tells users to use the default action 'set-property', which fails
[
https://issues.apache.org/jira/browse/SOLR-12481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510512#comment-16510512
]
ASF subversion and git services commented on SOLR-12481:
Commit 2cbd23ceb790acc34461f509bb5e6bfb09ef37d0 in lucene-solr's branch
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2cbd23c ]
SOLR-12481: update.autoCreateFields must be set via Config API command
'set-user-property', but 'bin/solr create' tells users to use the default
action 'set-property', which fails because the property is not editable
> update.autoCreateFields must be set via Config API command
> 'set-user-property', but 'bin/solr create' tells users to use the default
> action 'set-property', which fails because the property is not editable
>
>
> Key: SOLR-12481
> URL: https://issues.apache.org/jira/browse/SOLR-12481
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Priority: Major
> Attachments: SOLR-12481.patch
>
>
> {{bin/solr}} advises default config users to turn off data driven schema
> functionality, e.g.:
> {noformat}
> PROMPT$ bin/solr start -c
> [...]
> Waiting up to 180 seconds to see Solr running on port 8983 [-]
> Started Solr server on port 8983 (pid=74200). Happy searching!
> PROMPT$ bin/solr create -c mycoll
> WARNING: Using _default configset with data driven schema functionality. NOT
> RECOMMENDED for production use.
> To turn off: bin/solr config -c mycoll -p 8983 -property
> update.autoCreateFields -value false
> {noformat}
> When I try the above command, it claims to succeed, but in fact silently
> fails - see below (I'll open a separate JIRA for the false success problem).
> When I attempt to set this property via the equivalent direct call to the
> Config API, it fails:
> {noformat}
> PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
> '{set-property: { update.autoCreateFields: false }}'
> {
> "responseHeader":{
> "status":0,
> "QTime":8},
> "errorMessages":[{
> "set-property":{"update.autoCreateFields":false},
> "errorMessages":["'update.autoCreateFields' is not an editable property"]}],
> "WARNING":"This response format is experimental. It is likely to change in
> the future."}
> {noformat}
> The correct action to use here is {{set-user-property}} rather than
> {{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the
> correct Config API command to an incorrect {{bin/solr config}} command.
> {{bin/solr}} should instead be printing (note the {{-action}} param):
> {noformat}
> To turn off: bin/solr config -c mycoll -action set-user-property -p [...]
> -property update.autoCreateFields -value false
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12481) update.autoCreateFields must be set via Config API command 'set-user-property', but 'bin/solr create' tells users to use the default action 'set-property', which fails
[
https://issues.apache.org/jira/browse/SOLR-12481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510510#comment-16510510
]
Steve Rowe commented on SOLR-12481:
---
Attached patch, committing shortly.
> update.autoCreateFields must be set via Config API command
> 'set-user-property', but 'bin/solr create' tells users to use the default
> action 'set-property', which fails because the property is not editable
>
>
> Key: SOLR-12481
> URL: https://issues.apache.org/jira/browse/SOLR-12481
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Priority: Major
> Attachments: SOLR-12481.patch
>
>
> {{bin/solr}} advises default config users to turn off data driven schema
> functionality, e.g.:
> {noformat}
> PROMPT$ bin/solr start -c
> [...]
> Waiting up to 180 seconds to see Solr running on port 8983 [-]
> Started Solr server on port 8983 (pid=74200). Happy searching!
> PROMPT$ bin/solr create -c mycoll
> WARNING: Using _default configset with data driven schema functionality. NOT
> RECOMMENDED for production use.
> To turn off: bin/solr config -c mycoll -p 8983 -property
> update.autoCreateFields -value false
> {noformat}
> When I try the above command, it claims to succeed, but in fact silently
> fails - see below (I'll open a separate JIRA for the false success problem).
> When I attempt to set this property via the equivalent direct call to the
> Config API, it fails:
> {noformat}
> PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
> '{set-property: { update.autoCreateFields: false }}'
> {
> "responseHeader":{
> "status":0,
> "QTime":8},
> "errorMessages":[{
> "set-property":{"update.autoCreateFields":false},
> "errorMessages":["'update.autoCreateFields' is not an editable property"]}],
> "WARNING":"This response format is experimental. It is likely to change in
> the future."}
> {noformat}
> The correct action to use here is {{set-user-property}} rather than
> {{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the
> correct Config API command to an incorrect {{bin/solr config}} command.
> {{bin/solr}} should instead be printing (note the {{-action}} param):
> {noformat}
> To turn off: bin/solr config -c mycoll -action set-user-property -p [...]
> -property update.autoCreateFields -value false
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12481) update.autoCreateFields must be set via Config API command 'set-user-property', but 'bin/solr create' tells users to use the default action 'set-property', which fails be
[
https://issues.apache.org/jira/browse/SOLR-12481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-12481:
--
Attachment: SOLR-12481.patch
> update.autoCreateFields must be set via Config API command
> 'set-user-property', but 'bin/solr create' tells users to use the default
> action 'set-property', which fails because the property is not editable
>
>
> Key: SOLR-12481
> URL: https://issues.apache.org/jira/browse/SOLR-12481
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Priority: Major
> Attachments: SOLR-12481.patch
>
>
> {{bin/solr}} advises default config users to turn off data driven schema
> functionality, e.g.:
> {noformat}
> PROMPT$ bin/solr start -c
> [...]
> Waiting up to 180 seconds to see Solr running on port 8983 [-]
> Started Solr server on port 8983 (pid=74200). Happy searching!
> PROMPT$ bin/solr create -c mycoll
> WARNING: Using _default configset with data driven schema functionality. NOT
> RECOMMENDED for production use.
> To turn off: bin/solr config -c mycoll -p 8983 -property
> update.autoCreateFields -value false
> {noformat}
> When I try the above command, it claims to succeed, but in fact silently
> fails - see below (I'll open a separate JIRA for the false success problem).
> When I attempt to set this property via the equivalent direct call to the
> Config API, it fails:
> {noformat}
> PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
> '{set-property: { update.autoCreateFields: false }}'
> {
> "responseHeader":{
> "status":0,
> "QTime":8},
> "errorMessages":[{
> "set-property":{"update.autoCreateFields":false},
> "errorMessages":["'update.autoCreateFields' is not an editable property"]}],
> "WARNING":"This response format is experimental. It is likely to change in
> the future."}
> {noformat}
> The correct action to use here is {{set-user-property}} rather than
> {{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the
> correct Config API command to an incorrect {{bin/solr config}} command.
> {{bin/solr}} should instead be printing (note the {{-action}} param):
> {noformat}
> To turn off: bin/solr config -c mycoll -action set-user-property -p [...]
> -property update.autoCreateFields -value false
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12481) update.autoCreateFields must be set via Config API command 'set-user-property', but 'bin/solr create' tells users to use the default action 'set-property', which fails be
[
https://issues.apache.org/jira/browse/SOLR-12481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-12481:
--
Description:
{{bin/solr}} advises default config users to turn off data driven schema
functionality, e.g.:
{noformat}
PROMPT$ bin/solr start -c
[...]
Waiting up to 180 seconds to see Solr running on port 8983 [-]
Started Solr server on port 8983 (pid=74200). Happy searching!
PROMPT$ bin/solr create -c mycoll
WARNING: Using _default configset with data driven schema functionality. NOT
RECOMMENDED for production use.
To turn off: bin/solr config -c mycoll -p 8983 -property
update.autoCreateFields -value false
{noformat}
When I try the above command, it claims to succeed, but in fact silently fails
- see below (I'll open a separate JIRA for the false success problem).
When I attempt to set this property via the equivalent direct call to the
Config API, it fails:
{noformat}
PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
'{set-property: { update.autoCreateFields: false }}'
{
"responseHeader":{
"status":0,
"QTime":8},
"errorMessages":[{
"set-property":{"update.autoCreateFields":false},
"errorMessages":["'update.autoCreateFields' is not an editable property"]}],
"WARNING":"This response format is experimental. It is likely to change in the
future."}
{noformat}
The correct action to use here is {{set-user-property}} rather than
{{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the correct
Config API command to an incorrect {{bin/solr config}} command.
{{bin/solr}} should instead be printing (note the {{-action}} param):
{noformat}
To turn off: bin/solr config -c mycoll -action set-user-property -p [...]
-property update.autoCreateFields -value false
{noformat}
was:
{{bin/solr}} advises default config users to turn off data driven schema
functionality, e.g.:
{noformat}
PROMPT$ bin/solr start -c
[...]
Waiting up to 180 seconds to see Solr running on port 8983 [-]
Started Solr server on port 8983 (pid=74200). Happy searching!
PROMPT$ bin/solr create -c mycoll
WARNING: Using _default configset with data driven schema functionality. NOT
RECOMMENDED for production use.
To turn off: bin/solr config -c mycoll -p 8983 -property
update.autoCreateFields -value false
{noformat}
When I try the above command, it claims to succeed, but in fact silently fails
- see below (I'll open a separate JIRA for the false success problem).
When I attempt to set this property via the equivalent direct call to the
Config API, it fails:
{noformat}
PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
'{set-property: { update.autoCreateFields: false }}'
{
"responseHeader":{
"status":0,
"QTime":8},
"errorMessages":[{
"set-property":{"update.autoCreateFields":false},
"errorMessages":["'update.autoCreateFields' is not an editable property"]}],
"WARNING":"This response format is experimental. It is likely to change in the
future."}
{noformat}
The correct action to use here is {{set-user-property}} rather than
{{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the correct
Config API command to an incorrect {{bin/solr config}} command.
{{bin/solr}} should instead be printing (note the {{-action}} param):
{noformat}
To turn off: bin/solr config -c mycoll -action set-user-property -p [...]
-property update.autoCreateFields -value false
{noformat}
> update.autoCreateFields must be set via Config API command
> 'set-user-property', but 'bin/solr create' tells users to use the default
> action 'set-property', which fails because the property is not editable
>
>
> Key: SOLR-12481
> URL: https://issues.apache.org/jira/browse/SOLR-12481
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Priority: Major
>
> {{bin/solr}} advises default config users to turn off data driven schema
> functionality, e.g.:
> {noformat}
> PROMPT$ bin/solr start -c
> [...]
> Waiting up to 180 seconds to see Solr running on port 8983 [-]
> Started Solr server on port 8983 (pid=74200). Happy searching!
> PROMPT$ bin/solr create -c mycoll
> WARNING: Using _default configset with data driven schema functionality. NOT
> RECOMMENDED for production use.
> To turn off: bin/solr config -c mycoll -p 8983 -property
> update.autoCreateFields -value false
> {noformat}
> When I try the above command, it claims to succeed, but in fact silently
> fails - see below (I'll open a separate JIRA for the false success problem).
> When I attempt to set this property via the equivalent direct call to the
> Config API, it fails:
[jira] [Updated] (SOLR-12481) update.autoCreateFields must be set via Config API command 'set-user-property', but 'bin/solr create' tells users to use the default action 'set-property', which fails be
[
https://issues.apache.org/jira/browse/SOLR-12481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-12481:
--
Description:
{{bin/solr}} advises default config users to turn off data driven schema
functionality, e.g.:
{noformat}
PROMPT$ bin/solr start -c
[...]
Waiting up to 180 seconds to see Solr running on port 8983 [-]
Started Solr server on port 8983 (pid=74200). Happy searching!
PROMPT$ bin/solr create -c mycoll
WARNING: Using _default configset with data driven schema functionality. NOT
RECOMMENDED for production use.
To turn off: bin/solr config -c mycoll -p 8983 -property
update.autoCreateFields -value false
{noformat}
When I try the above command, it claims to succeed, but in fact silently fails
- see below (I'll open a separate JIRA for the false success problem).
When I attempt to set this property via the equivalent direct call to the
Config API, it fails:
{noformat}
PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
'{set-property: { update.autoCreateFields: false }}'
{
"responseHeader":{
"status":0,
"QTime":8},
"errorMessages":[{
"set-property":{"update.autoCreateFields":false},
"errorMessages":["'update.autoCreateFields' is not an editable property"]}],
"WARNING":"This response format is experimental. It is likely to change in the
future."}
{noformat}
The correct action to use here is {{set-user-property}} rather than
{{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the correct
Config API command to an incorrect {{bin/solr config}} command.
{{bin/solr}} should instead be printing (note the {{-action}} param):
{noformat}
To turn off: bin/solr config -c mycoll -action set-user-property -p [...]
-property update.autoCreateFields -value false
{noformat}
was:
{{bin/solr}} advises default config users to turn off data driven schema
functionality, e.g.:
{noformat}
PROMPT$ bin/solr start -c
[...]
Waiting up to 180 seconds to see Solr running on port 8983 [-]
Started Solr server on port 8983 (pid=74200). Happy searching!
PROMPT$ bin/solr create -c mycoll
WARNING: Using _default configset with data driven schema functionality. NOT
RECOMMENDED for production use.
To turn off: bin/solr config -c mycoll -p 8983 -property
update.autoCreateFields -value false
{noformat}
When I try the above command, it claims to succeed, but in fact silently fails
- see below (I'll open a separate JIRA for the false success problem).
When I attempt to set this property via the equivalent direct call to the
Config API, it fails:
{noformat}
PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
'{set-property: { update.autoCreateFields: false }}'
{
"responseHeader":{
"status":0,
"QTime":8},
"errorMessages":[{
"set-property":{"update.autoCreateFields":false},
"errorMessages":["'update.autoCreateFields' is not an editable property"]}],
"WARNING":"This response format is experimental. It is likely to change in the
future."}
{noformat}
The correct action to use here is {{set-user-property}} rather than
{{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the correct
Config API command to the incorrect {{bin/solr config}} command.
{{bin/solr}} should instead be printing (note the {{-action}} param):
{noformat}
To turn off: bin/solr config -c mycoll -action set-user-property -p 8983
-property update.autoCreateFields -value false
{noformat}
> update.autoCreateFields must be set via Config API command
> 'set-user-property', but 'bin/solr create' tells users to use the default
> action 'set-property', which fails because the property is not editable
>
>
> Key: SOLR-12481
> URL: https://issues.apache.org/jira/browse/SOLR-12481
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Priority: Major
>
> {{bin/solr}} advises default config users to turn off data driven schema
> functionality, e.g.:
> {noformat}
> PROMPT$ bin/solr start -c
> [...]
> Waiting up to 180 seconds to see Solr running on port 8983 [-]
> Started Solr server on port 8983 (pid=74200). Happy searching!
> PROMPT$ bin/solr create -c mycoll
> WARNING: Using _default configset with data driven schema functionality. NOT
> RECOMMENDED for production use.
> To turn off: bin/solr config -c mycoll -p 8983 -property
> update.autoCreateFields -value false
> {noformat}
> When I try the above command, it claims to succeed, but in fact silently
> fails - see below (I'll open a separate JIRA for the false success problem).
> When I attempt to set this property via the equivalent direct call to the
> Config API, it fails:
[jira] [Updated] (SOLR-12481) update.autoCreateFields must be set via Config API command 'set-user-property', but 'bin/solr create' tells users to use the default action 'set-property', which fails be
[
https://issues.apache.org/jira/browse/SOLR-12481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-12481:
--
Description:
{{bin/solr}} advises default config users to turn off data driven schema
functionality, e.g.:
{noformat}
PROMPT$ bin/solr start -c
[...]
Waiting up to 180 seconds to see Solr running on port 8983 [-]
Started Solr server on port 8983 (pid=74200). Happy searching!
PROMPT$ bin/solr create -c mycoll
WARNING: Using _default configset with data driven schema functionality. NOT
RECOMMENDED for production use.
To turn off: bin/solr config -c mycoll -p 8983 -property
update.autoCreateFields -value false
{noformat}
When I try the above command, it claims to succeed, but in fact silently fails
- see below (I'll open a separate JIRA for the false success problem).
When I attempt to set this property via the equivalent direct call to the
Config API, it fails:
{noformat}
PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
'{set-property: { update.autoCreateFields: false }}'
{
"responseHeader":{
"status":0,
"QTime":8},
"errorMessages":[{
"set-property":{"update.autoCreateFields":false},
"errorMessages":["'update.autoCreateFields' is not an editable property"]}],
"WARNING":"This response format is experimental. It is likely to change in the
future."}
{noformat}
The correct action to use here is {{set-user-property}} rather than
{{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the correct
Config API command to the incorrect {{bin/solr config}} command.
{{bin/solr}} should instead be printing (note the {{-action}} param):
{noformat}
To turn off: bin/solr config -c mycoll -action set-user-property -p 8983
-property update.autoCreateFields -value false
{noformat}
was:
{{bin/solr}} advises default config users to turn off data driven schema
functionality, e.g.:
{noformat}
PROMPT$ bin/solr start -c
[...]
Waiting up to 180 seconds to see Solr running on port 8983 [-]
Started Solr server on port 8983 (pid=74200). Happy searching!
PROMPT$ bin/solr create -c mycoll
WARNING: Using _default configset with data driven schema functionality. NOT
RECOMMENDED for production use.
To turn off: bin/solr config -c mycoll -p 8983 -property
update.autoCreateFields -value false
{noformat}
When I try the above command, it claims to succeed (I'll open a separate JIRA
for the false success problem).
When I attempt to set this property via the equivalent direct call to the
Config API, it fails:
{noformat}
PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
'{set-property: { update.autoCreateFields: false }}'
{
"responseHeader":{
"status":0,
"QTime":8},
"errorMessages":[{
"set-property":{"update.autoCreateFields":false},
"errorMessages":["'update.autoCreateFields' is not an editable property"]}],
"WARNING":"This response format is experimental. It is likely to change in the
future."}
{noformat}
The correct action to use here is {{set-user-property}} rather than
{{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the correct
Config API command to the incorrect {{bin/solr config}} command.
{{bin/solr}} should instead be printing (note the {{-action}} param):
{noformat}
To turn off: bin/solr config -c mycoll -action set-user-property -p 8983
-property update.autoCreateFields -value false
{noformat}
> update.autoCreateFields must be set via Config API command
> 'set-user-property', but 'bin/solr create' tells users to use the default
> action 'set-property', which fails because the property is not editable
>
>
> Key: SOLR-12481
> URL: https://issues.apache.org/jira/browse/SOLR-12481
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Priority: Major
>
> {{bin/solr}} advises default config users to turn off data driven schema
> functionality, e.g.:
> {noformat}
> PROMPT$ bin/solr start -c
> [...]
> Waiting up to 180 seconds to see Solr running on port 8983 [-]
> Started Solr server on port 8983 (pid=74200). Happy searching!
> PROMPT$ bin/solr create -c mycoll
> WARNING: Using _default configset with data driven schema functionality. NOT
> RECOMMENDED for production use.
> To turn off: bin/solr config -c mycoll -p 8983 -property
> update.autoCreateFields -value false
> {noformat}
> When I try the above command, it claims to succeed, but in fact silently
> fails - see below (I'll open a separate JIRA for the false success problem).
> When I attempt to set this property via the equivalent direct call to the
> Config API, it fails:
> {noformat}
> PROMPT$ curl -X POST
[jira] [Updated] (SOLR-12481) update.autoCreateFields must be set via Config API command 'set-user-property', but 'bin/solr create' tells users to use the default action 'set-property', which fails be
[
https://issues.apache.org/jira/browse/SOLR-12481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-12481:
--
Description:
{{bin/solr}} advises default config users to turn off data driven schema
functionality, e.g.:
{noformat}
PROMPT$ bin/solr start -c
[...]
Waiting up to 180 seconds to see Solr running on port 8983 [-]
Started Solr server on port 8983 (pid=74200). Happy searching!
PROMPT$ bin/solr create -c mycoll
WARNING: Using _default configset with data driven schema functionality. NOT
RECOMMENDED for production use.
To turn off: bin/solr config -c mycoll -p 8983 -property
update.autoCreateFields -value false
{noformat}
When I try the above command, it claims to succeed (I'll open a separate JIRA
for the false success problem).
When I attempt to set this property via the equivalent direct call to the
Config API, it fails:
{noformat}
PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
'{set-property: { update.autoCreateFields: false }}'
{
"responseHeader":{
"status":0,
"QTime":8},
"errorMessages":[{
"set-property":{"update.autoCreateFields":false},
"errorMessages":["'update.autoCreateFields' is not an editable property"]}],
"WARNING":"This response format is experimental. It is likely to change in the
future."}
{noformat}
The correct action to use here is {{set-user-property}} rather than
{{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the correct
Config API command to the incorrect {{bin/solr config}} command.
{{bin/solr}} should instead be printing (note the {{-action}} param):
{noformat}
To turn off: bin/solr config -c mycoll -action set-user-property -p 8983
-property update.autoCreateFields -value false
{noformat}
was:
{{bin/solr}} advises default config users to turn off data driven schema
functionality, e.g.:
{noprompt}
PROMPT$ bin/solr start -c
[...]
Waiting up to 180 seconds to see Solr running on port 8983 [-]
Started Solr server on port 8983 (pid=74200). Happy searching!
PROMPT$ bin/solr create -c mycoll
WARNING: Using _default configset with data driven schema functionality. NOT
RECOMMENDED for production use.
To turn off: bin/solr config -c mycoll -p 8983 -property
update.autoCreateFields -value false
{noprompt}
When I try the above command, it claims to succeed (I'll open a separate JIRA
for the false success problem).
When I attempt to set this property via the equivalent direct call to the
Config API, it fails:
{noformat}
PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
'{set-property: { update.autoCreateFields: false }}'
{
"responseHeader":{
"status":0,
"QTime":8},
"errorMessages":[{
"set-property":{"update.autoCreateFields":false},
"errorMessages":["'update.autoCreateFields' is not an editable property"]}],
"WARNING":"This response format is experimental. It is likely to change in the
future."}
{noformat}
The correct action to use here is {{set-user-property}} rather than
{{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the correct
Config API command to the incorrect {{bin/solr config}} command.
{{bin/solr}} should instead be printing (note the {{-action}} param):
{noformat}
To turn off: bin/solr config -c mycoll -action set-user-property -p 8983
-property update.autoCreateFields -value false
{noformat}
> update.autoCreateFields must be set via Config API command
> 'set-user-property', but 'bin/solr create' tells users to use the default
> action 'set-property', which fails because the property is not editable
>
>
> Key: SOLR-12481
> URL: https://issues.apache.org/jira/browse/SOLR-12481
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Priority: Major
>
> {{bin/solr}} advises default config users to turn off data driven schema
> functionality, e.g.:
> {noformat}
> PROMPT$ bin/solr start -c
> [...]
> Waiting up to 180 seconds to see Solr running on port 8983 [-]
> Started Solr server on port 8983 (pid=74200). Happy searching!
> PROMPT$ bin/solr create -c mycoll
> WARNING: Using _default configset with data driven schema functionality. NOT
> RECOMMENDED for production use.
> To turn off: bin/solr config -c mycoll -p 8983 -property
> update.autoCreateFields -value false
> {noformat}
> When I try the above command, it claims to succeed (I'll open a separate JIRA
> for the false success problem).
> When I attempt to set this property via the equivalent direct call to the
> Config API, it fails:
> {noformat}
> PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
> '{set-property: {
[jira] [Updated] (SOLR-12481) update.autoCreateFields must be set via Config API command 'set-user-property', but 'bin/solr create' tells users to use the default action 'set-property', which fails be
[
https://issues.apache.org/jira/browse/SOLR-12481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-12481:
--
Description:
{{bin/solr}} advises default config users to turn off data driven schema
functionality, e.g.:
{noformat}
PROMPT$ bin/solr start -c
[...]
Waiting up to 180 seconds to see Solr running on port 8983 [-]
Started Solr server on port 8983 (pid=74200). Happy searching!
PROMPT$ bin/solr create -c mycoll
WARNING: Using _default configset with data driven schema functionality. NOT
RECOMMENDED for production use.
To turn off: bin/solr config -c mycoll -p 8983 -property
update.autoCreateFields -value false
{noformat}
When I try the above command, it claims to succeed (I'll open a separate JIRA
for the false success problem).
When I attempt to set this property via the equivalent direct call to the
Config API, it fails:
{noformat}
PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
'{set-property: { update.autoCreateFields: false }}'
{
"responseHeader":{
"status":0,
"QTime":8},
"errorMessages":[{
"set-property":{"update.autoCreateFields":false},
"errorMessages":["'update.autoCreateFields' is not an editable property"]}],
"WARNING":"This response format is experimental. It is likely to change in the
future."}
{noformat}
The correct action to use here is {{set-user-property}} rather than
{{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the correct
Config API command to the incorrect {{bin/solr config}} command.
{{bin/solr}} should instead be printing (note the {{-action}} param):
{noformat}
To turn off: bin/solr config -c mycoll -action set-user-property -p 8983
-property update.autoCreateFields -value false
{noformat}
was:
{{bin/solr}} advises default config users to turn off data driven schema
functionality, e.g.:
{noformat}
PROMPT$ bin/solr start -c
[...]
Waiting up to 180 seconds to see Solr running on port 8983 [-]
Started Solr server on port 8983 (pid=74200). Happy searching!
PROMPT$ bin/solr create -c mycoll
WARNING: Using _default configset with data driven schema functionality. NOT
RECOMMENDED for production use.
To turn off: bin/solr config -c mycoll -p 8983 -property
update.autoCreateFields -value false
{noformat}
When I try the above command, it claims to succeed (I'll open a separate JIRA
for the false success problem).
When I attempt to set this property via the equivalent direct call to the
Config API, it fails:
{noformat}
PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
'{set-property: { update.autoCreateFields: false }}'
{
"responseHeader":{
"status":0,
"QTime":8},
"errorMessages":[{
"set-property":{"update.autoCreateFields":false},
"errorMessages":["'update.autoCreateFields' is not an editable property"]}],
"WARNING":"This response format is experimental. It is likely to change in the
future."}
{noformat}
The correct action to use here is {{set-user-property}} rather than
{{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the correct
Config API command to the incorrect {{bin/solr config}} command.
{{bin/solr}} should instead be printing (note the {{-action}} param):
{noformat}
To turn off: bin/solr config -c mycoll -action set-user-property -p 8983
-property update.autoCreateFields -value false
{noformat}
> update.autoCreateFields must be set via Config API command
> 'set-user-property', but 'bin/solr create' tells users to use the default
> action 'set-property', which fails because the property is not editable
>
>
> Key: SOLR-12481
> URL: https://issues.apache.org/jira/browse/SOLR-12481
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Priority: Major
>
> {{bin/solr}} advises default config users to turn off data driven schema
> functionality, e.g.:
> {noformat}
> PROMPT$ bin/solr start -c
> [...]
> Waiting up to 180 seconds to see Solr running on port 8983 [-]
> Started Solr server on port 8983 (pid=74200). Happy searching!
> PROMPT$ bin/solr create -c mycoll
> WARNING: Using _default configset with data driven schema functionality. NOT
> RECOMMENDED for production use.
> To turn off: bin/solr config -c mycoll -p 8983 -property
> update.autoCreateFields -value false
> {noformat}
> When I try the above command, it claims to succeed (I'll open a separate JIRA
> for the false success problem).
> When I attempt to set this property via the equivalent direct call to the
> Config API, it fails:
> {noformat}
> PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
> '{set-property: {
[jira] [Created] (SOLR-12481) update.autoCreateFields must be set via Config API command 'set-user-property', but 'bin/solr create' tells users to use the default action 'set-property', which fails be
Steve Rowe created SOLR-12481:
-
Summary: update.autoCreateFields must be set via Config API
command 'set-user-property', but 'bin/solr create' tells users to use the
default action 'set-property', which fails because the property is not editable
Key: SOLR-12481
URL: https://issues.apache.org/jira/browse/SOLR-12481
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Steve Rowe
{{bin/solr}} advises default config users to turn off data driven schema
functionality, e.g.:
{noprompt}
PROMPT$ bin/solr start -c
[...]
Waiting up to 180 seconds to see Solr running on port 8983 [-]
Started Solr server on port 8983 (pid=74200). Happy searching!
PROMPT$ bin/solr create -c mycoll
WARNING: Using _default configset with data driven schema functionality. NOT
RECOMMENDED for production use.
To turn off: bin/solr config -c mycoll -p 8983 -property
update.autoCreateFields -value false
{noprompt}
When I try the above command, it claims to succeed (I'll open a separate JIRA
for the false success problem).
When I attempt to set this property via the equivalent direct call to the
Config API, it fails:
{noformat}
PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d
'{set-property: { update.autoCreateFields: false }}'
{
"responseHeader":{
"status":0,
"QTime":8},
"errorMessages":[{
"set-property":{"update.autoCreateFields":false},
"errorMessages":["'update.autoCreateFields' is not an editable property"]}],
"WARNING":"This response format is experimental. It is likely to change in the
future."}
{noformat}
The correct action to use here is {{set-user-property}} rather than
{{set-property}}. SOLR-11108 changed the {{bin/solr}} output from the correct
Config API command to the incorrect {{bin/solr config}} command.
{{bin/solr}} should instead be printing (note the {{-action}} param):
{noformat}
To turn off: bin/solr config -c mycoll -action set-user-property -p 8983
-property update.autoCreateFields -value false
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510490#comment-16510490
]
ASF subversion and git services commented on SOLR-12434:
Commit 3af30b7612084ef06842447725efefd707e6fc84 in lucene-solr's branch
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3af30b7 ]
SOLR-12434: remove debug printing from bin/solr
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12434.patch, SOLR-12434.patch
>
>
> {{bin/solr config}} and {{bin/solr healthcheck}} should be usable without
> specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510491#comment-16510491
]
ASF subversion and git services commented on SOLR-12434:
Commit 3d8b219273f32c137fa25f1773a6ebf833670805 in lucene-solr's branch
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3d8b219 ]
SOLR-12434: remove debug printing from bin/solr
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12434.patch, SOLR-12434.patch
>
>
> {{bin/solr config}} and {{bin/solr healthcheck}} should be usable without
> specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510483#comment-16510483
]
ASF subversion and git services commented on SOLR-12434:
Commit 00be7bc2d601e8a8728bc52f76ba2487d387b7f6 in lucene-solr's branch
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=00be7bc ]
SOLR-12434: remove debug printing from bin/solr
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12434.patch, SOLR-12434.patch
>
>
> {{bin/solr config}} and {{bin/solr healthcheck}} should be usable without
> specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510482#comment-16510482
]
ASF subversion and git services commented on SOLR-12434:
Commit 21d0aa19b7a277464d72de2f8e45936f8a34651b in lucene-solr's branch
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=21d0aa1 ]
SOLR-12434: remove debug printing from bin/solr
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12434.patch, SOLR-12434.patch
>
>
> {{bin/solr config}} and {{bin/solr healthcheck}} should be usable without
> specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe resolved SOLR-12434.
---
Resolution: Fixed
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12434.patch, SOLR-12434.patch
>
>
> {{bin/solr config}} and {{bin/solr healthcheck}} should be usable without
> specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510480#comment-16510480
]
ASF subversion and git services commented on SOLR-12434:
Commit ade22a1ef99cb819e7ee35ac1c31ba6470b97a2a in lucene-solr's branch
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ade22a1 ]
SOLR-12434: Fix 'bin/solr config' endless loop parsing cmdline args
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12434.patch, SOLR-12434.patch
>
>
> {{bin/solr config}} and {{bin/solr healthcheck}} should be usable without
> specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510479#comment-16510479
]
ASF subversion and git services commented on SOLR-12434:
Commit b412769eced1b51a67b71be42ee24672308099c7 in lucene-solr's branch
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b412769 ]
SOLR-12434: Fix 'bin/solr config' endless loop parsing cmdline args
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12434.patch, SOLR-12434.patch
>
>
> {{bin/solr config}} and {{bin/solr healthcheck}} should be usable without
> specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe reopened SOLR-12434:
---
Reopening to fix an endless loop in {{bin/solr config}} cmdline processing.
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12434.patch, SOLR-12434.patch
>
>
> {{bin/solr config}} and {{bin/solr healthcheck}} should be usable without
> specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.4) - Build # 22237 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22237/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.update.processor.TestNamedUpdateProcessors.test Error Message: Error from server at https://127.0.0.1:35827/collection1: Async exception during distributed update: Error from server at https://127.0.0.1:34917/collection1_shard1_replica_n43: Bad Requestrequest: https://127.0.0.1:34917/collection1_shard1_replica_n43/update?update.distrib=TOLEADER=https%3A%2F%2F127.0.0.1%3A35827%2Fcollection1_shard2_replica_n41%2F=javabin=2 Remote error message: ERROR: [doc=123] multiple values encountered for non multiValued field test_s: [one, two] Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:35827/collection1: Async exception during distributed update: Error from server at https://127.0.0.1:34917/collection1_shard1_replica_n43: Bad Request request: https://127.0.0.1:34917/collection1_shard1_replica_n43/update?update.distrib=TOLEADER=https%3A%2F%2F127.0.0.1%3A35827%2Fcollection1_shard2_replica_n41%2F=javabin=2 Remote error message: ERROR: [doc=123] multiple values encountered for non multiValued field test_s: [one, two] at __randomizedtesting.SeedInfo.seed([FFBAAF5A9EEFBC12:77EE90803013D1EA]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:173) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:152) at org.apache.solr.update.processor.TestNamedUpdateProcessors.test(TestNamedUpdateProcessors.java:103) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at
[jira] [Commented] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510416#comment-16510416
]
ASF subversion and git services commented on SOLR-12434:
Commit ab2f9798846dbd8a18e5d6e06cbd0f425014bf5e in lucene-solr's branch
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ab2f979 ]
SOLR-12434: bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12434.patch, SOLR-12434.patch
>
>
> {{bin/solr config}} and {{bin/solr healthcheck}} should be usable without
> specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe resolved SOLR-12434.
---
Resolution: Fixed
Fix Version/s: 7.5
master (8.0)
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12434.patch, SOLR-12434.patch
>
>
> {{bin/solr config}} and {{bin/solr healthcheck}} should be usable without
> specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510417#comment-16510417
]
ASF subversion and git services commented on SOLR-12434:
Commit ba62472bd31b5c617cfdc0937e0d2c3b2f41c064 in lucene-solr's branch
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ba62472 ]
SOLR-12434: bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12434.patch, SOLR-12434.patch
>
>
> {{bin/solr config}} and {{bin/solr healthcheck}} should be usable without
> specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510404#comment-16510404
]
Steve Rowe commented on SOLR-12434:
---
bq. todo: test on Windows.
Done. Attached patch contains a fix over the previous patch: was missing a
cmdline arg {{SHIFT}}, so cmdline parsing was an endless loop.
I also noticed that on Windows, {{bin\solr healthcheck}} was not respecting
{{ZK_HOST}} in {{solr.in.cmd}} (this is not a problem under \*nix). The
attached patch fixes this.
Committing shortly.
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12434.patch, SOLR-12434.patch
>
>
> {{bin/solr config}} and {{bin/solr healthcheck}} should be usable without
> specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-12434:
--
Attachment: SOLR-12434.patch
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12434.patch, SOLR-12434.patch
>
>
> {{bin/solr config}} and {{bin/solr healthcheck}} should be usable without
> specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-12434:
--
Description: {{bin/solr config}} and {{bin/solr healthcheck}} should be
usable without specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is
specified in {{solr.in.sh}}/{{solr.in.cmd}}. (was: {{bin/solr config}} should
be usable without specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is
specified in {{solr.in.sh}}/{{solr.in.cmd}}.)
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12434.patch
>
>
> {{bin/solr config}} and {{bin/solr healthcheck}} should be usable without
> specifying {{-z}} or {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12434) bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-12434:
--
Summary: bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
(was: bin/solr config|healthcheck ignore ZK_HOST in solr.in.{sh,cmd})
> bin/solr {config,healthcheck} ignore ZK_HOST in solr.in.{sh,cmd}
>
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12434.patch
>
>
> {{bin/solr config}} should be usable without specifying {{-z}} or
> {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12434) bin/solr config|healthcheck ignore ZK_HOST in solr.in.{sh,cmd}
[
https://issues.apache.org/jira/browse/SOLR-12434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-12434:
--
Summary: bin/solr config|healthcheck ignore ZK_HOST in solr.in.{sh,cmd}
(was: bin/solr config ignores ZK_HOST in solr.in.{sh,cmd})
> bin/solr config|healthcheck ignore ZK_HOST in solr.in.{sh,cmd}
> --
>
> Key: SOLR-12434
> URL: https://issues.apache.org/jira/browse/SOLR-12434
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12434.patch
>
>
> {{bin/solr config}} should be usable without specifying {{-z}} or
> {{-solrUrl}} params, if {{ZK_HOST}} is specified in
> {{solr.in.sh}}/{{solr.in.cmd}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12457) field(x,min|max) sorting doesn't work on trie or str fields in multi-shard collections
[
https://issues.apache.org/jira/browse/SOLR-12457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510391#comment-16510391
]
Hoss Man commented on SOLR-12457:
-
Ok ... here's some spit balling...
ultimatley the root of the "ClassCastException: java.lang.String cannot be cast
to org.apache.lucene.util.BytesRef" comes down to the age old problem of
JavaBinCodec defaulting to {{writeVal(val.getClass().getName() + ':' +
val.toString());}} when it doesn't know how to write ab Object.
In particular: {{QueryComponent.doFieldSortValues}} tries to be agnostic to the
SortFields/Comparators used, and puts the "raw" sort value directly in the
response (unless there is a SchemaField that can be used to marshall it) .. in
the case of functions like these, that's a BytesRef -- on the other side of
things, the resulting "String" (ie:
{{org.apache.lucene.util.BytesRef:[DEADBEEF]}} ) gets read in and cases the
class cast when it's passed to TermOrdValComparator.
In an ideal world, the intra node communication would just happily "work" even
with {{BytesRef}} objects -- in which case we wouldn't even need the existing
marshall/unmarshall logic that StrField has -- and we could potentially
configure an ObjectResolver on the JavaBinCodec used for intra node
communication to do so ... but that seems like a pretty big change for this and
still wouldn't fix things for anyone still using xml for intra node
communication (do these people exist?)
a "hack" with a more limited surface area of change would be to make
{{QueryComponent.doFieldSortValues}} and {{QueryComponent.unmarshalSortValues}}
"smarter" such that they take care of automatically base64 encoding/decoding
sort values if/when the SortField uses a TermOrdValComparator
...that's really the best idea i've got.
> field(x,min|max) sorting doesn't work on trie or str fields in multi-shard
> collections
> --
>
> Key: SOLR-12457
> URL: https://issues.apache.org/jira/browse/SOLR-12457
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1
>Reporter: Varun Thacker
>Priority: Major
> Attachments: SOLR-12457.patch
>
>
> When I go to sort on a multi-valued field in a 2 shard collection, which has
> trie fields the query fails.
> To reproduce we need 2+ shards, a multi-valued trie field and "desc" sort
> criteria.
> Here's my schema
> {code:java}
> multiValued="true" docValues="true"/>
> positionIncrementGap="0" precisionStep="0"/>
> multiValued="true"/>
>
> {code}
> Now If I add a few docs
> {code:java}
> [
> {"id" : "1", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]},
> {"id" : "2", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]},
> {"id" : "3", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]}
> ]{code}
> Works:
> [http://localhost:8983/solr/gettingstarted/select?q=*:*=field(test_i,max)%20desc]
>
> Doesn't Work:
> [http://localhost:8983/solr/gettingstarted/select?q=*:*=field(test_is,max)%20desc]
>
> To be more clear when I say it doesn't work , the query throws and error and
> here's the stack trace for it:
> {code:java}
> ERROR - 2018-06-06 22:55:06.599; [c:gettingstarted s:shard2 r:core_node8
> x:gettingstarted_shard2_replica_n5] org.apache.solr.common.SolrException;
> null:java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.lucene.search.FieldComparator$TermOrdValComparator.compareValues(FieldComparator.java:561)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:161)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:153)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:91)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:33)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:263)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:140)
> at
> org.apache.lucene.util.PriorityQueue.insertWithOverflow(PriorityQueue.java:156)
> at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:924)
> at
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at
>
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_172) - Build # 2113 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2113/
Java: 64bit/jdk1.8.0_172 -XX:+UseCompressedOops -XX:+UseG1GC
2 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration
Error Message:
last state:
DocCollection(testSplitIntegration_collection//clusterstate.json/40)={
"replicationFactor":"2", "pullReplicas":"0",
"router":{"name":"compositeId"}, "maxShardsPerNode":"2",
"autoAddReplicas":"false", "nrtReplicas":"2", "tlogReplicas":"0",
"autoCreated":"true", "shards":{ "shard2":{ "replicas":{
"core_node3":{
"core":"testSplitIntegration_collection_shard2_replica_n3",
"leader":"true", "SEARCHER.searcher.maxDoc":11,
"SEARCHER.searcher.deletedDocs":0, "INDEX.sizeInBytes":15740,
"node_name":"127.0.0.1:10001_solr", "state":"active",
"type":"NRT", "INDEX.sizeInGB":1.4659017324447632E-5,
"SEARCHER.searcher.numDocs":11}, "core_node4":{
"core":"testSplitIntegration_collection_shard2_replica_n4",
"SEARCHER.searcher.maxDoc":11, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":15740, "node_name":"127.0.0.1:1_solr",
"state":"active", "type":"NRT",
"INDEX.sizeInGB":1.4659017324447632E-5,
"SEARCHER.searcher.numDocs":11}}, "range":"0-7fff",
"state":"active"}, "shard1":{ "stateTimestamp":"1528844328834792450",
"replicas":{ "core_node1":{
"core":"testSplitIntegration_collection_shard1_replica_n1",
"leader":"true", "SEARCHER.searcher.maxDoc":14,
"SEARCHER.searcher.deletedDocs":0, "INDEX.sizeInBytes":17240,
"node_name":"127.0.0.1:10001_solr", "state":"active",
"type":"NRT", "INDEX.sizeInGB":1.605600118637085E-5,
"SEARCHER.searcher.numDocs":14}, "core_node2":{
"core":"testSplitIntegration_collection_shard1_replica_n2",
"SEARCHER.searcher.maxDoc":14, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":17240, "node_name":"127.0.0.1:1_solr",
"state":"active", "type":"NRT",
"INDEX.sizeInGB":1.605600118637085E-5,
"SEARCHER.searcher.numDocs":14}}, "range":"8000-",
"state":"inactive"}, "shard1_1":{ "parent":"shard1",
"stateTimestamp":"1528844328855931000", "range":"c000-",
"state":"active", "replicas":{ "core_node10":{
"leader":"true",
"core":"testSplitIntegration_collection_shard1_1_replica1",
"SEARCHER.searcher.maxDoc":7, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":13740, "node_name":"127.0.0.1:1_solr",
"base_url":"http://127.0.0.1:1/solr;, "state":"active",
"type":"NRT", "INDEX.sizeInGB":1.2796372175216675E-5,
"SEARCHER.searcher.numDocs":7}, "core_node9":{
"core":"testSplitIntegration_collection_shard1_1_replica0",
"SEARCHER.searcher.maxDoc":7, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":13740, "node_name":"127.0.0.1:10001_solr",
"base_url":"http://127.0.0.1:10001/solr;, "state":"active",
"type":"NRT", "INDEX.sizeInGB":1.2796372175216675E-5,
"SEARCHER.searcher.numDocs":7}}}, "shard1_0":{ "parent":"shard1",
"stateTimestamp":"1528844328855560250", "range":"8000-bfff",
"state":"active", "replicas":{ "core_node7":{
"leader":"true",
"core":"testSplitIntegration_collection_shard1_0_replica0",
"SEARCHER.searcher.maxDoc":7, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":23980, "node_name":"127.0.0.1:10001_solr",
"base_url":"http://127.0.0.1:10001/solr;, "state":"active",
"type":"NRT", "INDEX.sizeInGB":2.2333115339279175E-5,
"SEARCHER.searcher.numDocs":7}, "core_node8":{
"core":"testSplitIntegration_collection_shard1_0_replica1",
"SEARCHER.searcher.maxDoc":7, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":23980, "node_name":"127.0.0.1:1_solr",
"base_url":"http://127.0.0.1:1/solr;, "state":"active",
"type":"NRT", "INDEX.sizeInGB":2.2333115339279175E-5,
"SEARCHER.searcher.numDocs":7}
Stack Trace:
java.util.concurrent.TimeoutException: last state:
DocCollection(testSplitIntegration_collection//clusterstate.json/40)={
"replicationFactor":"2",
"pullReplicas":"0",
"router":{"name":"compositeId"},
"maxShardsPerNode":"2",
[jira] [Comment Edited] (SOLR-12342) what-if analysis in JSON facet
[
https://issues.apache.org/jira/browse/SOLR-12342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510327#comment-16510327
]
Mikhail Khludnev edited comment on SOLR-12342 at 6/12/18 10:36 PM:
---
It turns out that
bq. incoming bucket docset to let to exclude it
is already done under SOLR-9480 via
[domain.query|https://github.com/apache/lucene-solr/blame/23da90813cd0fd3a1d60bb886b455689a14caa6e/solr/core/src/java/org/apache/solr/search/facet/FacetProcessor.java#L163]
was (Author: mkhludnev):
It turns out that
bq. incoming bucket docset to let to exclude it
is already done under SOLR-9480 via
[https://github.com/apache/lucene-solr/blame/23da90813cd0fd3a1d60bb886b455689a14caa6e/solr/core/src/java/org/apache/solr/search/facet/FacetProcessor.java#L163|domain.query]
> what-if analysis in JSON facet
> ---
>
> Key: SOLR-12342
> URL: https://issues.apache.org/jira/browse/SOLR-12342
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
>Reporter: Mikhail Khludnev
>Priority: Major
>
> It's literally what subfaceting (and earlier pivot facets) does. However,
> it's more complicated with you know what? Right! Block-Joins. Completely
> maked up sample follows:
> {quote}
> Giving those favoured SKUs with colours and sizes. I'd like to see sizes
> distribution (facets) depending on dominating colour per product documents.
> Eg I need to enumerate sku colours with term facet, then for every sku colour
> I want to search for products where this colour dominates - it's
> comprehensive combination of {{\{!frange}}}s, summing {{\{!parent
> score=total}} constant score queries {{^1}} and funcs like {{div()}} and
> {{sub()}} etc. Then I want to facet those new docset for sizes.
> {quote}
> h2. Proposal
> - Implicitly tag incoming bucket docset to let to exclude it via
> {{domain:\{excludeTags:[enclosing_bucket_docset]}}};
> - Implicitly inject the incoming bucket docset as a query parameter to allow
> to include it in query like {{query:"\{!frange l=10}\{!parent ..
> score=total}(\{!query v=$enclosing_bucket_docset}^1)"}}
>
> h2. Questions
> # How you gonna do something like this alternatively?
> # What about those two non-invasive improvements?
> # How to name those tags and param?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12342) what-if analysis in JSON facet
[
https://issues.apache.org/jira/browse/SOLR-12342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510327#comment-16510327
]
Mikhail Khludnev commented on SOLR-12342:
-
It turns out that
bq. incoming bucket docset to let to exclude it
is already done under SOLR-9480 via
[https://github.com/apache/lucene-solr/blame/23da90813cd0fd3a1d60bb886b455689a14caa6e/solr/core/src/java/org/apache/solr/search/facet/FacetProcessor.java#L163|domain.query]
> what-if analysis in JSON facet
> ---
>
> Key: SOLR-12342
> URL: https://issues.apache.org/jira/browse/SOLR-12342
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
>Reporter: Mikhail Khludnev
>Priority: Major
>
> It's literally what subfaceting (and earlier pivot facets) does. However,
> it's more complicated with you know what? Right! Block-Joins. Completely
> maked up sample follows:
> {quote}
> Giving those favoured SKUs with colours and sizes. I'd like to see sizes
> distribution (facets) depending on dominating colour per product documents.
> Eg I need to enumerate sku colours with term facet, then for every sku colour
> I want to search for products where this colour dominates - it's
> comprehensive combination of {{\{!frange}}}s, summing {{\{!parent
> score=total}} constant score queries {{^1}} and funcs like {{div()}} and
> {{sub()}} etc. Then I want to facet those new docset for sizes.
> {quote}
> h2. Proposal
> - Implicitly tag incoming bucket docset to let to exclude it via
> {{domain:\{excludeTags:[enclosing_bucket_docset]}}};
> - Implicitly inject the incoming bucket docset as a query parameter to allow
> to include it in query like {{query:"\{!frange l=10}\{!parent ..
> score=total}(\{!query v=$enclosing_bucket_docset}^1)"}}
>
> h2. Questions
> # How you gonna do something like this alternatively?
> # What about those two non-invasive improvements?
> # How to name those tags and param?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12457) field(x,min|max) sorting doesn't work on trie or str fields in multi-shard collections
[
https://issues.apache.org/jira/browse/SOLR-12457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510314#comment-16510314
]
Hoss Man commented on SOLR-12457:
-
attached a patch that converts {{SortByFunctionTest}} to a MiniSolrCloud based
test (NOTE: {{TestSortByMinMaxFunction extendsSortByFunctionTest}} ) as a
starting point for testing & fixing this
> field(x,min|max) sorting doesn't work on trie or str fields in multi-shard
> collections
> --
>
> Key: SOLR-12457
> URL: https://issues.apache.org/jira/browse/SOLR-12457
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1
>Reporter: Varun Thacker
>Priority: Major
> Attachments: SOLR-12457.patch
>
>
> When I go to sort on a multi-valued field in a 2 shard collection, which has
> trie fields the query fails.
> To reproduce we need 2+ shards, a multi-valued trie field and "desc" sort
> criteria.
> Here's my schema
> {code:java}
> multiValued="true" docValues="true"/>
> positionIncrementGap="0" precisionStep="0"/>
> multiValued="true"/>
>
> {code}
> Now If I add a few docs
> {code:java}
> [
> {"id" : "1", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]},
> {"id" : "2", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]},
> {"id" : "3", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]}
> ]{code}
> Works:
> [http://localhost:8983/solr/gettingstarted/select?q=*:*=field(test_i,max)%20desc]
>
> Doesn't Work:
> [http://localhost:8983/solr/gettingstarted/select?q=*:*=field(test_is,max)%20desc]
>
> To be more clear when I say it doesn't work , the query throws and error and
> here's the stack trace for it:
> {code:java}
> ERROR - 2018-06-06 22:55:06.599; [c:gettingstarted s:shard2 r:core_node8
> x:gettingstarted_shard2_replica_n5] org.apache.solr.common.SolrException;
> null:java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.lucene.search.FieldComparator$TermOrdValComparator.compareValues(FieldComparator.java:561)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:161)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:153)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:91)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:33)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:263)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:140)
> at
> org.apache.lucene.util.PriorityQueue.insertWithOverflow(PriorityQueue.java:156)
> at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:924)
> at
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
> at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:526){code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12457) field(x,min|max) sorting doesn't work on trie or str fields in multi-shard collections
[
https://issues.apache.org/jira/browse/SOLR-12457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-12457:
Attachment: SOLR-12457.patch
> field(x,min|max) sorting doesn't work on trie or str fields in multi-shard
> collections
> --
>
> Key: SOLR-12457
> URL: https://issues.apache.org/jira/browse/SOLR-12457
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1
>Reporter: Varun Thacker
>Priority: Major
> Attachments: SOLR-12457.patch
>
>
> When I go to sort on a multi-valued field in a 2 shard collection, which has
> trie fields the query fails.
> To reproduce we need 2+ shards, a multi-valued trie field and "desc" sort
> criteria.
> Here's my schema
> {code:java}
> multiValued="true" docValues="true"/>
> positionIncrementGap="0" precisionStep="0"/>
> multiValued="true"/>
>
> {code}
> Now If I add a few docs
> {code:java}
> [
> {"id" : "1", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]},
> {"id" : "2", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]},
> {"id" : "3", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]}
> ]{code}
> Works:
> [http://localhost:8983/solr/gettingstarted/select?q=*:*=field(test_i,max)%20desc]
>
> Doesn't Work:
> [http://localhost:8983/solr/gettingstarted/select?q=*:*=field(test_is,max)%20desc]
>
> To be more clear when I say it doesn't work , the query throws and error and
> here's the stack trace for it:
> {code:java}
> ERROR - 2018-06-06 22:55:06.599; [c:gettingstarted s:shard2 r:core_node8
> x:gettingstarted_shard2_replica_n5] org.apache.solr.common.SolrException;
> null:java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.lucene.search.FieldComparator$TermOrdValComparator.compareValues(FieldComparator.java:561)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:161)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:153)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:91)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:33)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:263)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:140)
> at
> org.apache.lucene.util.PriorityQueue.insertWithOverflow(PriorityQueue.java:156)
> at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:924)
> at
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
> at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:526){code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12457) field(x,min|max) sorting doesn't work on trie or str fields in multi-shard collections
[
https://issues.apache.org/jira/browse/SOLR-12457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510308#comment-16510308
]
Hoss Man commented on SOLR-12457:
-
bq. ... so StrField's marshalSortValue & unmarshalSortValue methods (which
handle the BytesRef/String conversion) take care of things for you.
FWIW: i started second guessing myself as to *why* I was seeing the implicit
syntax work for str fields, because in both cases the {{SortField}} should be
identical {{SortedSetSortField}} instances with the field name set on them --
but then i realized {{QueryComponent.unmarshalSortValues}} uses
{{SortSpec.getSchemaFields()}} to decide which {{SortFields}} should be
unmarshalled -- and _that_ knows the difference between a {{SortField}} whose
{{String getField()}} might happen to match a schema field name, vs an actual
usage of sorting on a {{SchemaField}} (which is important for field aliasing,
etc...)
> field(x,min|max) sorting doesn't work on trie or str fields in multi-shard
> collections
> --
>
> Key: SOLR-12457
> URL: https://issues.apache.org/jira/browse/SOLR-12457
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1
>Reporter: Varun Thacker
>Priority: Major
>
> When I go to sort on a multi-valued field in a 2 shard collection, which has
> trie fields the query fails.
> To reproduce we need 2+ shards, a multi-valued trie field and "desc" sort
> criteria.
> Here's my schema
> {code:java}
> multiValued="true" docValues="true"/>
> positionIncrementGap="0" precisionStep="0"/>
> multiValued="true"/>
>
> {code}
> Now If I add a few docs
> {code:java}
> [
> {"id" : "1", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]},
> {"id" : "2", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]},
> {"id" : "3", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]}
> ]{code}
> Works:
> [http://localhost:8983/solr/gettingstarted/select?q=*:*=field(test_i,max)%20desc]
>
> Doesn't Work:
> [http://localhost:8983/solr/gettingstarted/select?q=*:*=field(test_is,max)%20desc]
>
> To be more clear when I say it doesn't work , the query throws and error and
> here's the stack trace for it:
> {code:java}
> ERROR - 2018-06-06 22:55:06.599; [c:gettingstarted s:shard2 r:core_node8
> x:gettingstarted_shard2_replica_n5] org.apache.solr.common.SolrException;
> null:java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.lucene.search.FieldComparator$TermOrdValComparator.compareValues(FieldComparator.java:561)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:161)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:153)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:91)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:33)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:263)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:140)
> at
> org.apache.lucene.util.PriorityQueue.insertWithOverflow(PriorityQueue.java:156)
> at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:924)
> at
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
> at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:526){code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12457) field(x,min|max) sorting doesn't work on trie or str fields in multi-shard collections
[
https://issues.apache.org/jira/browse/SOLR-12457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-12457:
Summary: field(x,min|max) sorting doesn't work on trie or str fields in
multi-shard collections (was: Multi valued field sorting doesn't work on trie
fields)
> field(x,min|max) sorting doesn't work on trie or str fields in multi-shard
> collections
> --
>
> Key: SOLR-12457
> URL: https://issues.apache.org/jira/browse/SOLR-12457
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1
>Reporter: Varun Thacker
>Priority: Major
>
> When I go to sort on a multi-valued field in a 2 shard collection, which has
> trie fields the query fails.
> To reproduce we need 2+ shards, a multi-valued trie field and "desc" sort
> criteria.
> Here's my schema
> {code:java}
> multiValued="true" docValues="true"/>
> positionIncrementGap="0" precisionStep="0"/>
> multiValued="true"/>
>
> {code}
> Now If I add a few docs
> {code:java}
> [
> {"id" : "1", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]},
> {"id" : "2", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]},
> {"id" : "3", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]}
> ]{code}
> Works:
> [http://localhost:8983/solr/gettingstarted/select?q=*:*=field(test_i,max)%20desc]
>
> Doesn't Work:
> [http://localhost:8983/solr/gettingstarted/select?q=*:*=field(test_is,max)%20desc]
>
> To be more clear when I say it doesn't work , the query throws and error and
> here's the stack trace for it:
> {code:java}
> ERROR - 2018-06-06 22:55:06.599; [c:gettingstarted s:shard2 r:core_node8
> x:gettingstarted_shard2_replica_n5] org.apache.solr.common.SolrException;
> null:java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.lucene.search.FieldComparator$TermOrdValComparator.compareValues(FieldComparator.java:561)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:161)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:153)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:91)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:33)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:263)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:140)
> at
> org.apache.lucene.util.PriorityQueue.insertWithOverflow(PriorityQueue.java:156)
> at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:924)
> at
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
> at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:526){code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12457) Multi valued field sorting doesn't work on trie fields
[
https://issues.apache.org/jira/browse/SOLR-12457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510279#comment-16510279
]
Hoss Man commented on SOLR-12457:
-
I was hoping to crank out a quick fix for this in time for 7.4, but the problem
is more nuanced then i realized...
the {{FieldType}} {{marshalSortValue}} & {{unmarshalSortValue}} functions don't
come into play in these cases because we're not sorting on a _field_ we're
sorting on a _ValueSource_
As I speculated in my earlier comment, this means that the same problem occurs
with string fields if you try something like
{{sort=field(multivalued_string,min) asc}} ... but it does *NOT* affect you if
you use the implicit min|max syntax added in SOLR-11854 (ie:
{{sort=multivalued_string asc}} ) because in that case there is no ValueSource
involved and the SortField used is directly tied to the (multivalued) field
name -- so StrField's {{marshalSortValue}} & {{unmarshalSortValue}} methods
(which handle the BytesRef/String conversion) take care of things for you.
NOTE: The same implicit min|max syntax (ie: {{sort=multivalued_trie_field
asc}} ) does *NOT* work for trie fields, because they don't override the
default {{marshalSortValue}} & {{unmarshalSortValue}} (even if we only cared
about solving this bug for the implicit syntax, the marshalling methods don't
have access to the {{SchemaField}}, so there's no easy way for the marshalling
methods to know if the "field" being sorted on is multivalued or not -- so we'd
have to do some kind of kludgy hack where the {{TrieField}} marshaling logic
did instance of checks to decide if it should convert things)
At the moment, i can't think of a simple/clean fix for this.
> Multi valued field sorting doesn't work on trie fields
> --
>
> Key: SOLR-12457
> URL: https://issues.apache.org/jira/browse/SOLR-12457
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1
>Reporter: Varun Thacker
>Priority: Major
>
> When I go to sort on a multi-valued field in a 2 shard collection, which has
> trie fields the query fails.
> To reproduce we need 2+ shards, a multi-valued trie field and "desc" sort
> criteria.
> Here's my schema
> {code:java}
> multiValued="true" docValues="true"/>
> positionIncrementGap="0" precisionStep="0"/>
> multiValued="true"/>
>
> {code}
> Now If I add a few docs
> {code:java}
> [
> {"id" : "1", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]},
> {"id" : "2", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]},
> {"id" : "3", "test_is" : ["1", "2", "3", "4", "5"], "test_i" : ["1", "2",
> "3", "4", "5"]}
> ]{code}
> Works:
> [http://localhost:8983/solr/gettingstarted/select?q=*:*=field(test_i,max)%20desc]
>
> Doesn't Work:
> [http://localhost:8983/solr/gettingstarted/select?q=*:*=field(test_is,max)%20desc]
>
> To be more clear when I say it doesn't work , the query throws and error and
> here's the stack trace for it:
> {code:java}
> ERROR - 2018-06-06 22:55:06.599; [c:gettingstarted s:shard2 r:core_node8
> x:gettingstarted_shard2_replica_n5] org.apache.solr.common.SolrException;
> null:java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.lucene.search.FieldComparator$TermOrdValComparator.compareValues(FieldComparator.java:561)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:161)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:153)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:91)
> at
> org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:33)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:263)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:140)
> at
> org.apache.lucene.util.PriorityQueue.insertWithOverflow(PriorityQueue.java:156)
> at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:924)
> at
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
> at
[jira] [Resolved] (SOLR-9685) tag a query in JSON syntax
[
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-9685.
Resolution: Fixed
OK, I also modified a test to test for the {"#tag":{"lucene" case.
Right now, excludeTags only works on top-level filters, so we can only test
that the syntax works for now on these sub-queries I think.
> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685-doc.patch,
> SOLR-9685.patch, SOLR-9685.patch, SOLR-9685.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6096) Support Update and Delete on nested documents
[
https://issues.apache.org/jira/browse/SOLR-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510236#comment-16510236
]
Lorenzo Speranzoni commented on SOLR-6096:
--
Many thanks for your fast reply [~mkhludnev] .
Yes, I saw SOLR-5211 ... and deleteByQuery(_root_:ID) was indeed my candidate
solution but unfortunately hbase-indexer doesn't let you create and submit such
a statement (at least for my limited experience with that connector).
I would need to trigger it from SOLR side as soon as you the parent is
cancelled or something like that... don't think postCommit is ideal for that?
Thanks again.
> Support Update and Delete on nested documents
> -
>
> Key: SOLR-6096
> URL: https://issues.apache.org/jira/browse/SOLR-6096
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.7.2
>Reporter: Thomas Scheffler
>Priority: Major
> Labels: blockjoin, nested
>
> When using nested or child document. Update and delete operation on the root
> document should also affect the nested documents, as no child can exist
> without its parent :-)
> Example
> {code:xml|title=First Import}
>
> 1
> Article with author
>
> Smith, John
> author
>
>
> {code}
> If I change my mind and the author was not named *John* but *_Jane_*:
> {code:xml|title=Changed name of author of '1'}
>
> 1
> Article with author
>
> Smith, Jane
> author
>
>
> {code}
> I would expect that John is not in the index anymore. Currently he is. There
> might also be the case that any subdocument is removed by an update:
> {code:xml|title=Remove author}
>
> 1
> Article without author
>
> {code}
> This should affect a delete on all nested documents, too. The same way all
> nested documents should be deleted if I delete the root document:
> {code:xml|title=Deletion of '1'}
>
> 1
>
>
> {code}
> This is currently possible to do all this stuff on client side by issuing
> additional request to delete document before every update. It would be more
> efficient if this could be handled on SOLR side. One would benefit on atomic
> update. The biggest plus shows when using "delete-by-query".
> {code:xml|title=Deletion of '1' by query}
>
> title:*
>
>
> {code}
> In that case one would not have to first query all documents and issue
> deletes by those id and every document that are nested.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11823) Incorrect number of replica calculation when using Restore Collection API
[
https://issues.apache.org/jira/browse/SOLR-11823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510230#comment-16510230
]
Jan Høydahl commented on SOLR-11823:
If you apply your patch from SOLR-11807 and run my reproduction steps, does
that work? I’m not (knowingly) setting -1 when creating my collection, as the
case was in the other issue.
> Incorrect number of replica calculation when using Restore Collection API
> -
>
> Key: SOLR-11823
> URL: https://issues.apache.org/jira/browse/SOLR-11823
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore
>Affects Versions: 7.1
>Reporter: Ansgar Wiechers
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> I'm running Solr 7.1 (didn't test other versions) in SolrCloud mode ona a
> 3-node cluster and tried using the backup/restore API for the first time.
> Backup worked fine, but when trying to restore the backed-up collection I ran
> into an unexpected problem with the replication factor setting.
> I expected the command below to restore a backup of the collection "demo"
> with 3 shards, creating 2 replicas per shard. Instead it's trying to create 6
> replicas per shard:
> {noformat}
> # curl -s -k
> 'https://localhost:8983/solr/admin/collections?action=restore=demo=/srv/backup/solr/solr-dev=demo=2=2'
> {
> "error": {
> "code": 400,
> "msg": "Solr cloud with available number of nodes:3 is insufficient for
> restoring a collection with 3 shards, total replicas per shard 6 and
> maxShardsPerNode 2. Consider increasing maxShardsPerNode value OR number
> ofavailable nodes.",
> "metadata": [
> "error-class",
> "org.apache.solr.common.SolrException",
> "root-error-class",
> "org.apache.solr.common.SolrException"
> ]
> },
> "exception": {
> "rspCode": 400,
> "msg": "Solr cloud with available number of nodes:3 is insufficient for
> restoring a collection with 3 shards, total replicas per shard 6 and
> maxShardsPerNode 2. Consider increasing maxShardsPerNode value OR number of
> available nodes."
> },
> "Operation restore caused exception:":
> "org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> Solr cloud with available number of nodes:3 is insufficient for restoring a
> collection with 3 shards, total replicas per shard 6 and maxShardsPerNode 2.
> Consider increasing maxShardsPerNode value OR number of available nodes.",
> "responseHeader": {
> "QTime": 28,
> "status": 400
> }
> }
> {noformat}
> Restoring a collection with only 2 shards tries to create 6 replicas as well,
> so it looks to me like the restore API multiplies the replication factor with
> the number of nodes, which is not how the replication factor behaves in other
> contexts. The
> [documentation|https://lucene.apache.org/solr/guide/7_1/collections-api.html]
> also didn't lead me to expect this behavior:
> {quote}
> replicationFactor
>The number of replicas to be created for each shard.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6096) Support Update and Delete on nested documents
[
https://issues.apache.org/jira/browse/SOLR-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510226#comment-16510226
]
Mikhail Khludnev commented on SOLR-6096:
[~inserpio], I hope SOLR-5211 makes an improvement for this case.
if in {{delete by ID}} you mean deleting by {{}} field I can suggest
a {{deleteByQuery(\_root_:ID)}}, however it might have performance implication.
> Support Update and Delete on nested documents
> -
>
> Key: SOLR-6096
> URL: https://issues.apache.org/jira/browse/SOLR-6096
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.7.2
>Reporter: Thomas Scheffler
>Priority: Major
> Labels: blockjoin, nested
>
> When using nested or child document. Update and delete operation on the root
> document should also affect the nested documents, as no child can exist
> without its parent :-)
> Example
> {code:xml|title=First Import}
>
> 1
> Article with author
>
> Smith, John
> author
>
>
> {code}
> If I change my mind and the author was not named *John* but *_Jane_*:
> {code:xml|title=Changed name of author of '1'}
>
> 1
> Article with author
>
> Smith, Jane
> author
>
>
> {code}
> I would expect that John is not in the index anymore. Currently he is. There
> might also be the case that any subdocument is removed by an update:
> {code:xml|title=Remove author}
>
> 1
> Article without author
>
> {code}
> This should affect a delete on all nested documents, too. The same way all
> nested documents should be deleted if I delete the root document:
> {code:xml|title=Deletion of '1'}
>
> 1
>
>
> {code}
> This is currently possible to do all this stuff on client side by issuing
> additional request to delete document before every update. It would be more
> efficient if this could be handled on SOLR side. One would benefit on atomic
> update. The biggest plus shows when using "delete-by-query".
> {code:xml|title=Deletion of '1' by query}
>
> title:*
>
>
> {code}
> In that case one would not have to first query all documents and issue
> deletes by those id and every document that are nested.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))
[
https://issues.apache.org/jira/browse/LUCENE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510220#comment-16510220
]
Robert Muir commented on LUCENE-8041:
-
{quote}
+1 to make term vectors consistent across the index; it has always been strange
that Lucene allows this. Maybe open a separate issue for that?
{quote}
This issue specifically asks why there is an iterator at all in the
description, thats why i explained it.
But i also am concerned about this issue because i don't think its a real
bottleneck for anyone. I don't want us doing anything risky that could
potentially hurt ordinary users for some esoteric abuse case with a million
fields: it would be better to just stay with treemap.
It is fine to sort a list in the constructor, or use a linkedhashmap. This
won't hurt ordinary users, it will just cost more ram for abuse cases, so I am
fine. I really don't want to see sneaky optimizations trying to avoid sorts or
any of that, it does not belong here, this needs to be simple, clear, and safe.
Instead any serious effort should go into trying to remove the problematic api
(term vectors stuff), then it can even simpler since we won't need two data
structures.
> All Fields.terms(fld) impls should be O(1) not O(log(N))
>
>
> Key: LUCENE-8041
> URL: https://issues.apache.org/jira/browse/LUCENE-8041
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8041.patch
>
>
> I've seen apps that have a good number of fields -- hundreds. The O(log(N))
> of TreeMap definitely shows up in a profiler; sometimes 20% of search time,
> if I recall. There are many Field implementations that are impacted... in
> part because Fields is the base class of FieldsProducer.
> As an aside, I hope Fields to go away some day; FieldsProducer should be
> TermsProducer and not have an iterator of fields. If DocValuesProducer
> doesn't have this then why should the terms index part of our API have it?
> If we did this then the issue here would be a simple transition to a HashMap.
> Or maybe we can switch to HashMap and relax the definition of Fields.iterator
> to not necessarily be sorted?
> Perhaps the fix can be a relatively simple conversion over to LinkedHashMap
> in many cases if we can assume when we initialize these internal maps that we
> consume them in sorted order to begin with.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11779) Basic long-term collection of aggregated metrics
[
https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510213#comment-16510213
]
Andrzej Bialecki commented on SOLR-11779:
--
Sounds good - I'll make the change shortly.
> Basic long-term collection of aggregated metrics
>
>
> Key: SOLR-11779
> URL: https://issues.apache.org/jira/browse/SOLR-11779
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Affects Versions: 7.3, master (8.0)
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11779.patch, SOLR-11779.patch, SOLR-11779.patch,
> SOLR-11779.patch, c1.png, c2.png, core.json, d1.png, d2.png, d3.png,
> jvm-list.json, jvm-string.json, jvm.json, o1.png, u1.png
>
>
> Tracking the key metrics over time is very helpful in understanding the
> cluster and user behavior.
> Currently even basic metrics tracking requires setting up an external system
> and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The
> advantage of this setup is that these external tools usually provide a lot of
> sophisticated functionality. The downside is that they don't ship out of the
> box with Solr and require additional admin effort to set up.
> Solr could collect some of the key metrics and keep their historical values
> in a round-robin database (eg. using RRD4j) to keep the size of the historic
> data constant (eg. ~64kB per metric), but at the same providing out of the
> box useful insights into the basic system behavior over time. This data could
> be persisted to the {{.system}} collection as blobs, and it could be also
> presented in the Admin UI as graphs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-11779) Basic long-term collection of aggregated metrics
[
https://issues.apache.org/jira/browse/SOLR-11779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki reopened SOLR-11779:
--
> Basic long-term collection of aggregated metrics
>
>
> Key: SOLR-11779
> URL: https://issues.apache.org/jira/browse/SOLR-11779
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Affects Versions: 7.3, master (8.0)
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11779.patch, SOLR-11779.patch, SOLR-11779.patch,
> SOLR-11779.patch, c1.png, c2.png, core.json, d1.png, d2.png, d3.png,
> jvm-list.json, jvm-string.json, jvm.json, o1.png, u1.png
>
>
> Tracking the key metrics over time is very helpful in understanding the
> cluster and user behavior.
> Currently even basic metrics tracking requires setting up an external system
> and either polling {{/admin/metrics}} or using {{SolrMetricReporter}}-s. The
> advantage of this setup is that these external tools usually provide a lot of
> sophisticated functionality. The downside is that they don't ship out of the
> box with Solr and require additional admin effort to set up.
> Solr could collect some of the key metrics and keep their historical values
> in a round-robin database (eg. using RRD4j) to keep the size of the historic
> data constant (eg. ~64kB per metric), but at the same providing out of the
> box useful insights into the basic system behavior over time. This data could
> be persisted to the {{.system}} collection as blobs, and it could be also
> presented in the Admin UI as graphs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6096) Support Update and Delete on nested documents
[
https://issues.apache.org/jira/browse/SOLR-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510205#comment-16510205
]
Lorenzo Speranzoni commented on SOLR-6096:
--
I'm using HBASE-INDEXER and our use case requires us to generate a parent +
children set of documents per HBASE row. When it comes to deleting a record in
HBASE the only option is to delete by ID which results in the deletion of the
parent document only.
I was wondering if there's a way to "trigger" the deletion of the orphaned
children via configuration or with a specific delete by query "delete all
orphaned children" (that I can't figure out) that could be scheduled in a cron
script?
Or do you have see any better strategy to keep the index clean?
Thank you very much in advance,
Lorenzo
> Support Update and Delete on nested documents
> -
>
> Key: SOLR-6096
> URL: https://issues.apache.org/jira/browse/SOLR-6096
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.7.2
>Reporter: Thomas Scheffler
>Priority: Major
> Labels: blockjoin, nested
>
> When using nested or child document. Update and delete operation on the root
> document should also affect the nested documents, as no child can exist
> without its parent :-)
> Example
> {code:xml|title=First Import}
>
> 1
> Article with author
>
> Smith, John
> author
>
>
> {code}
> If I change my mind and the author was not named *John* but *_Jane_*:
> {code:xml|title=Changed name of author of '1'}
>
> 1
> Article with author
>
> Smith, Jane
> author
>
>
> {code}
> I would expect that John is not in the index anymore. Currently he is. There
> might also be the case that any subdocument is removed by an update:
> {code:xml|title=Remove author}
>
> 1
> Article without author
>
> {code}
> This should affect a delete on all nested documents, too. The same way all
> nested documents should be deleted if I delete the root document:
> {code:xml|title=Deletion of '1'}
>
> 1
>
>
> {code}
> This is currently possible to do all this stuff on client side by issuing
> additional request to delete document before every update. It would be more
> efficient if this could be handled on SOLR side. One would benefit on atomic
> update. The biggest plus shows when using "delete-by-query".
> {code:xml|title=Deletion of '1' by query}
>
> title:*
>
>
> {code}
> In that case one would not have to first query all documents and issue
> deletes by those id and every document that are nested.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12480) TriggerAction failures may cause inconsistent trigger behavior
[
https://issues.apache.org/jira/browse/SOLR-12480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki resolved SOLR-12480.
--
Resolution: Duplicate
> TriggerAction failures may cause inconsistent trigger behavior
> --
>
> Key: SOLR-12480
> URL: https://issues.apache.org/jira/browse/SOLR-12480
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Affects Versions: 7.4, master (8.0)
>Reporter: Andrzej Bialecki
>Priority: Major
>
> The following issue occasionally appears when running
> {{TestLargeCluster.testNodeLost}}.
> The test kills a large number of nodes, waiting for a certain time between
> the kills. Depending on the sequence and the length of {{waitFor}} it may
> happen that when {{ExecutePlanAction}} processes MOVEREPLICA the target node
> may just have been killed. This results in an exception and a FAILED status
> of the action.
> However, this failure is not reported back to the trigger as unprocessed
> event because it happens asynchronously in the action executor (in
> {{ScheduledTriggers}}) - so the trigger happily resets its internal state to
> no longer track the lost node. As a result, replicas remain lost and even if
> there’s a Policy violation the event will not be generated again, and the
> number of replicas won’t go back to the original number.
> Also, {{ScheduledTriggers:311}} and 323 only logs the exception but doesn’t
> fire listeners with FAILED status, which is a bug.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12480) TriggerAction failures may cause inconsistent trigger behavior
Andrzej Bialecki created SOLR-12480:
Summary: TriggerAction failures may cause inconsistent trigger
behavior
Key: SOLR-12480
URL: https://issues.apache.org/jira/browse/SOLR-12480
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: AutoScaling
Affects Versions: 7.4, master (8.0)
Reporter: Andrzej Bialecki
The following issue occasionally appears when running
{{TestLargeCluster.testNodeLost}}.
The test kills a large number of nodes, waiting for a certain time between the
kills. Depending on the sequence and the length of {{waitFor}} it may happen
that when {{ExecutePlanAction}} processes MOVEREPLICA the target node may just
have been killed. This results in an exception and a FAILED status of the
action.
However, this failure is not reported back to the trigger as unprocessed event
because it happens asynchronously in the action executor (in
{{ScheduledTriggers}}) - so the trigger happily resets its internal state to no
longer track the lost node. As a result, replicas remain lost and even if
there’s a Policy violation the event will not be generated again, and the
number of replicas won’t go back to the original number.
Also, {{ScheduledTriggers:311}} and 323 only logs the exception but doesn’t
fire listeners with FAILED status, which is a bug.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12479) TriggerAction failures may cause inconsistent trigger behavior
Andrzej Bialecki created SOLR-12479:
Summary: TriggerAction failures may cause inconsistent trigger
behavior
Key: SOLR-12479
URL: https://issues.apache.org/jira/browse/SOLR-12479
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: AutoScaling
Affects Versions: 7.4, master (8.0)
Reporter: Andrzej Bialecki
The following issue occasionally appears when running
{{TestLargeCluster.testNodeLost}}.
The test kills a large number of nodes, waiting for a certain time between the
kills. Depending on the sequence and the length of {{waitFor}} it may happen
that when {{ExecutePlanAction}} processes MOVEREPLICA the target node may just
have been killed. This results in an exception and a FAILED status of the
action.
However, this failure is not reported back to the trigger as unprocessed event
because it happens asynchronously in the action executor (in
{{ScheduledTriggers}}) - so the trigger happily resets its internal state to no
longer track the lost node. As a result, replicas remain lost and even if
there’s a Policy violation the event will not be generated again, and the
number of replicas won’t go back to the original number.
Also, {{ScheduledTriggers:311}} and 323 only logs the exception but doesn’t
fire listeners with FAILED status, which is a bug.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8354) remove IndexWriter from TestTieredMergePolicy
Erick Erickson created LUCENE-8354: -- Summary: remove IndexWriter from TestTieredMergePolicy Key: LUCENE-8354 URL: https://issues.apache.org/jira/browse/LUCENE-8354 Project: Lucene - Core Issue Type: Improvement Reporter: Erick Erickson Now that IndexWriter has been removed (LUCENE-7976) from TieredMergePolicy, we should also remove it from TestTieredMergePolicy. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #403: SOLR-12193 Move some log messages to TRACE le...
GitHub user gezapeti opened a pull request: https://github.com/apache/lucene-solr/pull/403 SOLR-12193 Move some log messages to TRACE level You can merge this pull request into a Git repository by running: $ git pull https://github.com/gezapeti/lucene-solr SOLR-12193 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/403.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #403 commit cafad41be127726a4d4e60830973584864785e8c Author: gezapeti <2914398+gezapeti@...> Date: 2018-06-12T20:15:09Z SOLR-12193 Move some log messages to TRACE level --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9685) tag a query in JSON syntax
[
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510127#comment-16510127
]
ASF subversion and git services commented on SOLR-9685:
---
Commit 7db0895f24df4003b90dfc2dcf97076ba4f75c4a in lucene-solr's branch
refs/heads/branch_7_4 from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7db0895 ]
SOLR-9685: fix parsing of tagged sub-queries
> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685-doc.patch,
> SOLR-9685.patch, SOLR-9685.patch, SOLR-9685.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7444) Remove StopFilter from StandardAnalyzer in Lucene-Core
[
https://issues.apache.org/jira/browse/LUCENE-7444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510124#comment-16510124
]
Michael McCandless commented on LUCENE-7444:
+1 to that patch.
> Remove StopFilter from StandardAnalyzer in Lucene-Core
> --
>
> Key: LUCENE-7444
> URL: https://issues.apache.org/jira/browse/LUCENE-7444
> Project: Lucene - Core
> Issue Type: Task
> Components: core/other, modules/analysis
>Affects Versions: 6.2
>Reporter: Uwe Schindler
>Priority: Major
>
> Yonik said on LUCENE-7318:
> {quote}
> bq. I think it would make a good default for most Lucene users, and we should
> graduate it from the analyzers module into core, and make it the default for
> IndexWriter.
> This "StandardAnalyzer" is specific to English, as it removes English
> stopwords.
> That seems to be an odd choice now for a few reasons:
> - It was argued in the past (rather vehemently) that Solr should not prefer
> english in it's default "text" field
> - AFAIK, removing stopwords is no longer considered best practice.
> Given that removal of english stopwords is the only thing that really makes
> this analyzer english-centric (and given the negative impact that can have on
> other languages), it seems like the stopword filter should be removed from
> StandardAnalyzer.
> {quote}
> When trying to fix the backwards incompatibility issues in LUCENE-7318, it
> looks like most unrelated code moved from analysis module to core (and
> changing package names :( ) was related to word list loading,
> CharArraySets, and superclasses of StopFilter. If we follow Yonik's
> suggestion, we can revert all those changes. I agree with hin, an "universal"
> analyzer should not have any language specific stop-words.
> The other thing is LowercaseFilter, but I'd suggest to simply add a clone of
> it to Lucene core and leave the analysis-module self-contained.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9685) tag a query in JSON syntax
[
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510126#comment-16510126
]
ASF subversion and git services commented on SOLR-9685:
---
Commit cc34f9b61959f5b91d095b64c83fb792ed545117 in lucene-solr's branch
refs/heads/branch_7x from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cc34f9b ]
SOLR-9685: fix parsing of tagged sub-queries
> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685-doc.patch,
> SOLR-9685.patch, SOLR-9685.patch, SOLR-9685.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9685) tag a query in JSON syntax
[
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510121#comment-16510121
]
ASF subversion and git services commented on SOLR-9685:
---
Commit 23da90813cd0fd3a1d60bb886b455689a14caa6e in lucene-solr's branch
refs/heads/master from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=23da908 ]
SOLR-9685: fix parsing of tagged sub-queries
> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685-doc.patch,
> SOLR-9685.patch, SOLR-9685.patch, SOLR-9685.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7976) Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of very large segments
[
https://issues.apache.org/jira/browse/LUCENE-7976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510118#comment-16510118
]
Michael McCandless commented on LUCENE-7976:
Thanks [~erickerickson]; patch looks a lot better! I'm glad that scary loop is
gone.
A few small things:
Can we remove this code:
{noformat}
// A singleton merge with no deletes makes no sense. We can get here
when forceMerge is looping around...
if (candidate.size() == 1) {
SegmentSizeAndDocs segSizeDocs =
segInfosSizes.get(candidate.get(0));
if (segSizeDocs.delCount == 0) {
continue;
}
}
{noformat}
If we fix the above loop to not add the singleton merge unless it has deletes?
Can you rename {{maxMergeAtonce}} --> {{maxMergeAtOnce}}?
Hmm shouldn't this code only run if the merge candidate is max sized
({{bestTooLarge}})? I.e. change {{true}} to {{bestTooLarge}}?
{noformat}
if (bestTooLarge) {
haveOneLargeMerge = true;
}
{noformat}
I think this logic might be buggy?
{noformat}
boolean maxMergeIsRunning = false;
if (mergeType == MERGE_TYPE.NATURAL) {
maxMergeIsRunning = mergingBytes >= maxMergedSegmentBytes;
}
{noformat}
E.g. if we have picked two merges to run, neither of which is the max segment
size, but when added together they are over the max, then we incorrectly
conclude {{maxMergeIsRunning}}?
> Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of
> very large segments
> -
>
> Key: LUCENE-7976
> URL: https://issues.apache.org/jira/browse/LUCENE-7976
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch,
> LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch,
> LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch,
> SOLR-7976.patch
>
>
> We're seeing situations "in the wild" where there are very large indexes (on
> disk) handled quite easily in a single Lucene index. This is particularly
> true as features like docValues move data into MMapDirectory space. The
> current TMP algorithm allows on the order of 50% deleted documents as per a
> dev list conversation with Mike McCandless (and his blog here:
> https://www.elastic.co/blog/lucenes-handling-of-deleted-documents).
> Especially in the current era of very large indexes in aggregate, (think many
> TB) solutions like "you need to distribute your collection over more shards"
> become very costly. Additionally, the tempting "optimize" button exacerbates
> the issue since once you form, say, a 100G segment (by
> optimizing/forceMerging) it is not eligible for merging until 97.5G of the
> docs in it are deleted (current default 5G max segment size).
> The proposal here would be to add a new parameter to TMP, something like
> (no, that's not serious name, suggestions
> welcome) which would default to 100 (or the same behavior we have now).
> So if I set this parameter to, say, 20%, and the max segment size stays at
> 5G, the following would happen when segments were selected for merging:
> > any segment with > 20% deleted documents would be merged or rewritten NO
> > MATTER HOW LARGE. There are two cases,
> >> the segment has < 5G "live" docs. In that case it would be merged with
> >> smaller segments to bring the resulting segment up to 5G. If no smaller
> >> segments exist, it would just be rewritten
> >> The segment has > 5G "live" docs (the result of a forceMerge or optimize).
> >> It would be rewritten into a single segment removing all deleted docs no
> >> matter how big it is to start. The 100G example above would be rewritten
> >> to an 80G segment for instance.
> Of course this would lead to potentially much more I/O which is why the
> default would be the same behavior we see now. As it stands now, though,
> there's no way to recover from an optimize/forceMerge except to re-index from
> scratch. We routinely see 200G-300G Lucene indexes at this point "in the
> wild" with 10s of shards replicated 3 or more times. And that doesn't even
> include having these over HDFS.
> Alternatives welcome! Something like the above seems minimally invasive. A
> new merge policy is certainly an alternative.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8004) IndexUpgraderTool should rewrite segments rather than forceMerge
[ https://issues.apache.org/jira/browse/LUCENE-8004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510104#comment-16510104 ] Erick Erickson commented on LUCENE-8004: Since LUCENE-7976 hasn't been added to 7.4, this is _not_ a blocker for 7.4. > IndexUpgraderTool should rewrite segments rather than forceMerge > > > Key: LUCENE-8004 > URL: https://issues.apache.org/jira/browse/LUCENE-8004 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > > Spinoff from LUCENE-7976. We help users get themselves into a corner by using > forceMerge on an index to rewrite all segments in the current Lucene format. > We should rewrite each individual segment instead. This would also help with > upgrading X-2->X-1, then X-1->X. > Of course the preferred method is to re-index from scratch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11277) Add auto hard commit setting based on tlog size
[
https://issues.apache.org/jira/browse/SOLR-11277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510099#comment-16510099
]
Lucene/Solr QA commented on SOLR-11277:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
|| || || || {color:brown} master Compile Tests {color} ||
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 0m 9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 0m 9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate ref guide {color} |
{color:green} 0m 9s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:black}{color} | {color:black} {color} | {color:black} 4m 17s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-11277 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12927318/SOLR-11277.02.patch |
| Optional Tests | ratsources validatesourcepatterns validaterefguide |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 7c4bad0 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 |
| modules | C: solr/solr-ref-guide U: solr/solr-ref-guide |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/122/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Add auto hard commit setting based on tlog size
> ---
>
> Key: SOLR-11277
> URL: https://issues.apache.org/jira/browse/SOLR-11277
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Rupa Shankar
>Assignee: Anshum Gupta
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11277.01.patch, SOLR-11277.02.patch,
> SOLR-11277.patch, SOLR-11277.patch, SOLR-11277.patch, SOLR-11277.patch,
> SOLR-11277.patch, SOLR-11277.patch, SOLR-11277.patch,
> max_size_auto_commit.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When indexing documents of variable sizes and at variable schedules, it can
> be hard to estimate the optimal auto hard commit maxDocs or maxTime settings.
> We’ve had some occurrences of really huge tlogs, resulting in serious issues,
> so in an attempt to avoid this, it would be great to have a “maxSize” setting
> based on the tlog size on disk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: discuss: stop adding 'via' from CHANGES.txt entries (take two)
> +1 to remove via; who actually pushed the change is (or should be) > unimportant, I don't care much for credit and am pretty much indifferent to any of these options. The way I see it is that 'via' is not much of a credit but a *responsibility* -- the committer should have reviewed the change she or he is contributing on behalf of the non-committer. Sure, git history is fine too but note that it's not ideal -- it may not mention the actual contributor of a patch if it's a manual application of a diff file and in cases like this it'd require more complex processing than just scanning through CHANGES.txt so I'd opt for simplicity of keeping it together in CHANGES.txt (easier to scan through, doesn't take any credit away from the author), but I'll live with any decision. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 806 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/806/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/80/consoleText [repro] Revision: 5a3d75b8b37274f9fbfbb660989852e62c5c9544 [repro] Repro line: ant test -Dtestcase=TestRandomRequestDistribution -Dtests.method=test -Dtests.seed=2BC6D267554B544F -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=vi -Dtests.timezone=Europe/Simferopol -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=AutoAddReplicasPlanActionTest -Dtests.method=testSimple -Dtests.seed=2BC6D267554B544F -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-NI -Dtests.timezone=Asia/Ust-Nera -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=TestLargeCluster -Dtests.method=testAddNode -Dtests.seed=2BC6D267554B544F -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sl-SI -Dtests.timezone=AST -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=SolrRrdBackendFactoryTest -Dtests.method=testBasic -Dtests.seed=2BC6D267554B544F -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-SA -Dtests.timezone=US/Indiana-Starke -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=SolrExporterTest -Dtests.seed=89BB19DAEB77A517 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-TN -Dtests.timezone=America/Louisville -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 7c4bad0e8f6c6befa1aeb79b9a047cae40134ba8 [repro] git fetch [repro] git checkout 5a3d75b8b37274f9fbfbb660989852e62c5c9544 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/contrib/prometheus-exporter [repro] SolrExporterTest [repro]solr/core [repro] SolrRrdBackendFactoryTest [repro] AutoAddReplicasPlanActionTest [repro] TestLargeCluster [repro] TestRandomRequestDistribution [repro] ant compile-test [...truncated 2584 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.SolrExporterTest" -Dtests.showOutput=onerror -Dtests.seed=89BB19DAEB77A517 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-TN -Dtests.timezone=America/Louisville -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [...truncated 71 lines...] [repro] ant compile-test [...truncated 1331 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=20 -Dtests.class="*.SolrRrdBackendFactoryTest|*.AutoAddReplicasPlanActionTest|*.TestLargeCluster|*.TestRandomRequestDistribution" -Dtests.showOutput=onerror -Dtests.seed=2BC6D267554B544F -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-SA -Dtests.timezone=US/Indiana-Starke -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 25093 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.cloud.TestRandomRequestDistribution [repro] 0/5 failed: org.apache.solr.cloud.autoscaling.AutoAddReplicasPlanActionTest [repro] 0/5 failed: org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest [repro] 0/5 failed: org.apache.solr.prometheus.exporter.SolrExporterTest [repro] 5/5 failed: org.apache.solr.cloud.autoscaling.sim.TestLargeCluster [repro] Re-testing 100% failures at the tip of branch_7x [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestLargeCluster [repro] ant compile-test [...truncated 3318 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestLargeCluster" -Dtests.showOutput=onerror -Dtests.seed=2BC6D267554B544F -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sl-SI -Dtests.timezone=AST -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 24234 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of branch_7x: [repro] 5/5 failed: org.apache.solr.cloud.autoscaling.sim.TestLargeCluster [repro] Re-testing 100% failures at the tip of branch_7x without a seed [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestLargeCluster [repro] ant compile-test [...truncated 3318 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestLargeCluster" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sl-SI -Dtests.timezone=AST -Dtests.asserts=true
[jira] [Commented] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))
[
https://issues.apache.org/jira/browse/LUCENE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510092#comment-16510092
]
David Smiley commented on LUCENE-8041:
--
bq. I do wonder if an intermediate step would be to have a map + a
Iterable so we don't need to do this sorting over and over again?
Absolutely; there's no need to re-sort. I'm working with
[~yhec...@salesforce.com] who came up with this tidy solution. In
BlockTreeTermsReader, the "fields" field becomes a HashMap. Then, in the
constructor after it's populated, there's a few lines to build up the list:
{code:java}
ArrayList fieldsNames = new ArrayList(fields.keySet());
Collections.sort(fieldsNames);
fieldsNamesIterable = Collections.unmodifiableCollection(fieldsNames);
{code}
{{fieldsNamesIterable}} is a new declared field.
Very similar logic goes in PerFieldsPostingsFormat.
I think it's possible to avoid the sort() in BlockTreeTermsReader if you know
you're reading data written pre-sorted.
> All Fields.terms(fld) impls should be O(1) not O(log(N))
>
>
> Key: LUCENE-8041
> URL: https://issues.apache.org/jira/browse/LUCENE-8041
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8041.patch
>
>
> I've seen apps that have a good number of fields -- hundreds. The O(log(N))
> of TreeMap definitely shows up in a profiler; sometimes 20% of search time,
> if I recall. There are many Field implementations that are impacted... in
> part because Fields is the base class of FieldsProducer.
> As an aside, I hope Fields to go away some day; FieldsProducer should be
> TermsProducer and not have an iterator of fields. If DocValuesProducer
> doesn't have this then why should the terms index part of our API have it?
> If we did this then the issue here would be a simple transition to a HashMap.
> Or maybe we can switch to HashMap and relax the definition of Fields.iterator
> to not necessarily be sorted?
> Perhaps the fix can be a relatively simple conversion over to LinkedHashMap
> in many cases if we can assume when we initialize these internal maps that we
> consume them in sorted order to begin with.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: discuss: stop adding 'via' from CHANGES.txt entries (take two)
+1 to remove via if it's a stupid merge. But there are cases where the patch is taken and improved by the committer. In that case the committer should be added with a comma only. Uwe Am June 12, 2018 7:05:57 PM UTC schrieb Gus Heck : >FWIW As a non-committer contributor I don't mind the "via". Seems legit >to >give the committer some credit for their review and merging work. > >On Tue, Jun 12, 2018 at 2:53 PM, Michael McCandless < >luc...@mikemccandless.com> wrote: > >> +1 to remove via; who actually pushed the change is (or should be) >> unimportant, and is easily derived from git history if we really do >ever >> need it. >> >> Your ideas will go further if you don't insist on going with them ;) >> >> Mike McCandless >> >> http://blog.mikemccandless.com >> >> On Mon, Jun 4, 2018 at 8:47 PM, Robert Muir wrote: >> >>> I raised this issue a few years ago, and no consensus was reached >[1] >>> >>> I'm asking if we can take the time to revisit the issue. Back then >it >>> was subversion days, and you had "patch-uploaders" and >"contributors". >>> With git now, I believe the situation is even a bit more extreme, >>> because the committer is the contributor and the lucene "committer" >>> was really the "pusher". >>> >>> On the other hand, there were some reasons against removing this >>> before. In particular some mentioned that it conveyed meaning about >>> who might be the best person to ping about a particular area of the >>> code. If this is still the case, I'd ask that we discuss alternative >>> ways that it could be accomplished (such as wiki page perhaps >>> linked-to HowToContribute that ppl can edit). >>> >>> I wrote a new summary/argument inline, but see the linked thread for >>> the previous discussion: >>> >>> >>> In the past CHANGES.txt entries from a contributor have also had the >>> name of the committer with a 'via' entry. >>> >>> e.g.: >>> >>> LUCENE-1234: optimized FooBar. (Jane Doe via Joe Schmoe). >>> >>> I propose we stop adding the committer name (via Joe Schmoe). It >seems >>> to diminish the value of the contribution. It reminds me of a >>> professor adding a second author by default or something like that. >If >>> someone really wants to know who committed the change, I think its >>> fair that they look at version control history? >>> >>> 1. http://mail-archives.apache.org/mod_mbox/lucene-dev/201206.m >>> box/%3CCAOdYfZW65MXrzyRPsvBD0C6c4X%2BLuQX4oVec%3DyR_PCPgTQrn >>> hQ%40mail.gmail.com%3E >>> >>> >- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >> > > >-- >http://www.the111shift.com -- Uwe Schindler Achterdiek 19, 28357 Bremen https://www.thetaphi.de
[jira] [Resolved] (SOLR-5152) EdgeNGramFilterFactory deletes token
[
https://issues.apache.org/jira/browse/SOLR-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher resolved SOLR-5152.
Resolution: Duplicate
> EdgeNGramFilterFactory deletes token
>
>
> Key: SOLR-5152
> URL: https://issues.apache.org/jira/browse/SOLR-5152
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.4
>Reporter: Christoph Lingg
>Priority: Major
> Attachments: SOLR-5152-v5.0.0.patch, SOLR-5152.patch
>
>
> I am using EdgeNGramFilterFactory in my schema.xml
> {code:xml} positionIncrementGap="100">
>
>
> maxGramSize="10" side="front" />
>
> {code}
> Some tokens in my index only consist of one character, let's say {{R}}.
> minGramSize is set to 2 and is bigger than the length of the token. I
> expected the NGramFilter to left {{R}} unchanged but in fact it is deleting
> the token.
> For my use case this interpretation is undesirable, and probably for most use
> cases too!?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7444) Remove StopFilter from StandardAnalyzer in Lucene-Core
[
https://issues.apache.org/jira/browse/LUCENE-7444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510061#comment-16510061
]
Uwe Schindler commented on LUCENE-7444:
---
+1 that's an easy change!
> Remove StopFilter from StandardAnalyzer in Lucene-Core
> --
>
> Key: LUCENE-7444
> URL: https://issues.apache.org/jira/browse/LUCENE-7444
> Project: Lucene - Core
> Issue Type: Task
> Components: core/other, modules/analysis
>Affects Versions: 6.2
>Reporter: Uwe Schindler
>Priority: Major
>
> Yonik said on LUCENE-7318:
> {quote}
> bq. I think it would make a good default for most Lucene users, and we should
> graduate it from the analyzers module into core, and make it the default for
> IndexWriter.
> This "StandardAnalyzer" is specific to English, as it removes English
> stopwords.
> That seems to be an odd choice now for a few reasons:
> - It was argued in the past (rather vehemently) that Solr should not prefer
> english in it's default "text" field
> - AFAIK, removing stopwords is no longer considered best practice.
> Given that removal of english stopwords is the only thing that really makes
> this analyzer english-centric (and given the negative impact that can have on
> other languages), it seems like the stopword filter should be removed from
> StandardAnalyzer.
> {quote}
> When trying to fix the backwards incompatibility issues in LUCENE-7318, it
> looks like most unrelated code moved from analysis module to core (and
> changing package names :( ) was related to word list loading,
> CharArraySets, and superclasses of StopFilter. If we follow Yonik's
> suggestion, we can revert all those changes. I agree with hin, an "universal"
> analyzer should not have any language specific stop-words.
> The other thing is LowercaseFilter, but I'd suggest to simply add a clone of
> it to Lucene core and leave the analysis-module self-contained.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5332) Add "preserve original" setting to the EdgeNGramFilterFactory
[ https://issues.apache.org/jira/browse/SOLR-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510060#comment-16510060 ] Ingomar Wesp commented on SOLR-5332: Given that LUCENE-7960 has been closed, I think this issue can be marked as fixed, too. > Add "preserve original" setting to the EdgeNGramFilterFactory > - > > Key: SOLR-5332 > URL: https://issues.apache.org/jira/browse/SOLR-5332 > Project: Solr > Issue Type: Wish >Affects Versions: 4.4, 4.5, 4.5.1, 4.6 >Reporter: Alexander S. >Priority: Major > Fix For: 5.2, 6.0 > > > Hi, as described here: > http://lucene.472066.n3.nabble.com/Help-to-figure-out-why-query-does-not-match-td4086967.html > the problem is in that if you have these 2 strings to index: > 1. facebook.com/someuser.1 > 2. facebook.com/someveryandverylongusername > and the edge ngram filter factory with min and max gram size settings 2 and > 25, search requests for these urls will fail. > But search requests for: > 1. facebook.com/someuser > 2. facebook.com/someveryandverylonguserna > will work properly. > It's because first url has "1" at the end, which is lover than the allowed > min gram size. In the second url the user name is longer than the max gram > size (27 characters). > Would be good to have a "preserve original" option, that will add the > original string to the index if it does not fit the allowed gram size, so > that "1" and "someveryandverylongusername" tokens will also be added to the > index. > Best, > Alex -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5152) EdgeNGramFilterFactory deletes token
[
https://issues.apache.org/jira/browse/SOLR-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510056#comment-16510056
]
Ingomar Wesp commented on SOLR-5152:
Given that LUCENE-7960 has been closed, I think this issue can be marked as
fixed as well.
> EdgeNGramFilterFactory deletes token
>
>
> Key: SOLR-5152
> URL: https://issues.apache.org/jira/browse/SOLR-5152
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.4
>Reporter: Christoph Lingg
>Priority: Major
> Attachments: SOLR-5152-v5.0.0.patch, SOLR-5152.patch
>
>
> I am using EdgeNGramFilterFactory in my schema.xml
> {code:xml} positionIncrementGap="100">
>
>
> maxGramSize="10" side="front" />
>
> {code}
> Some tokens in my index only consist of one character, let's say {{R}}.
> minGramSize is set to 2 and is bigger than the length of the token. I
> expected the NGramFilter to left {{R}} unchanged but in fact it is deleting
> the token.
> For my use case this interpretation is undesirable, and probably for most use
> cases too!?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))
[ https://issues.apache.org/jira/browse/LUCENE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510047#comment-16510047 ] Simon Willnauer commented on LUCENE-8041: - bq. +1 to make term vectors consistent across the index; it has always been strange that Lucene allows this. Maybe open a separate issue for that? ++ bq. This has the downside that it sorts all fields on every call to iterator(). My concern is mainly that it will introduce performance problems down the line, ones that are difficult to find/debug because of java's syntactic sugar around iterator(). Especially if someone is using MultiFields (slow-wrapper crap), they will be doing a bunch of sorts on each segment, then merging those, and all hidden behind a single call to iterator(). I do wonder if an intermediate step would be to have a map + a Iterable so we don't need to do this sorting over and over again? > All Fields.terms(fld) impls should be O(1) not O(log(N)) > > > Key: LUCENE-8041 > URL: https://issues.apache.org/jira/browse/LUCENE-8041 > Project: Lucene - Core > Issue Type: Improvement >Reporter: David Smiley >Priority: Major > Attachments: LUCENE-8041.patch > > > I've seen apps that have a good number of fields -- hundreds. The O(log(N)) > of TreeMap definitely shows up in a profiler; sometimes 20% of search time, > if I recall. There are many Field implementations that are impacted... in > part because Fields is the base class of FieldsProducer. > As an aside, I hope Fields to go away some day; FieldsProducer should be > TermsProducer and not have an iterator of fields. If DocValuesProducer > doesn't have this then why should the terms index part of our API have it? > If we did this then the issue here would be a simple transition to a HashMap. > Or maybe we can switch to HashMap and relax the definition of Fields.iterator > to not necessarily be sorted? > Perhaps the fix can be a relatively simple conversion over to LinkedHashMap > in many cases if we can assume when we initialize these internal maps that we > consume them in sorted order to begin with. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: discuss: stop adding 'via' from CHANGES.txt entries (take two)
FWIW As a non-committer contributor I don't mind the "via". Seems legit to give the committer some credit for their review and merging work. On Tue, Jun 12, 2018 at 2:53 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > +1 to remove via; who actually pushed the change is (or should be) > unimportant, and is easily derived from git history if we really do ever > need it. > > Your ideas will go further if you don't insist on going with them ;) > > Mike McCandless > > http://blog.mikemccandless.com > > On Mon, Jun 4, 2018 at 8:47 PM, Robert Muir wrote: > >> I raised this issue a few years ago, and no consensus was reached [1] >> >> I'm asking if we can take the time to revisit the issue. Back then it >> was subversion days, and you had "patch-uploaders" and "contributors". >> With git now, I believe the situation is even a bit more extreme, >> because the committer is the contributor and the lucene "committer" >> was really the "pusher". >> >> On the other hand, there were some reasons against removing this >> before. In particular some mentioned that it conveyed meaning about >> who might be the best person to ping about a particular area of the >> code. If this is still the case, I'd ask that we discuss alternative >> ways that it could be accomplished (such as wiki page perhaps >> linked-to HowToContribute that ppl can edit). >> >> I wrote a new summary/argument inline, but see the linked thread for >> the previous discussion: >> >> >> In the past CHANGES.txt entries from a contributor have also had the >> name of the committer with a 'via' entry. >> >> e.g.: >> >> LUCENE-1234: optimized FooBar. (Jane Doe via Joe Schmoe). >> >> I propose we stop adding the committer name (via Joe Schmoe). It seems >> to diminish the value of the contribution. It reminds me of a >> professor adding a second author by default or something like that. If >> someone really wants to know who committed the change, I think its >> fair that they look at version control history? >> >> 1. http://mail-archives.apache.org/mod_mbox/lucene-dev/201206.m >> box/%3CCAOdYfZW65MXrzyRPsvBD0C6c4X%2BLuQX4oVec%3DyR_PCPgTQrn >> hQ%40mail.gmail.com%3E >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > -- http://www.the111shift.com
[JENKINS] Lucene-Solr-BadApples-Tests-7.x - Build # 81 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/81/ 5 tests failed. FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration Error Message: did not finish processing in time Stack Trace: java.lang.AssertionError: did not finish processing in time at __randomizedtesting.SeedInfo.seed([4DFC337E7A6A315B:1E4571CE987BA4A1]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:408) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration Error Message: did not finish processing in time Stack Trace: java.lang.AssertionError: did not finish processing in time at __randomizedtesting.SeedInfo.seed([4DFC337E7A6A315B:74728A3E5595F8A5]:0) at
Re: discuss: stop adding 'via' from CHANGES.txt entries (take two)
+1 to remove via; who actually pushed the change is (or should be) unimportant, and is easily derived from git history if we really do ever need it. Your ideas will go further if you don't insist on going with them ;) Mike McCandless http://blog.mikemccandless.com On Mon, Jun 4, 2018 at 8:47 PM, Robert Muir wrote: > I raised this issue a few years ago, and no consensus was reached [1] > > I'm asking if we can take the time to revisit the issue. Back then it > was subversion days, and you had "patch-uploaders" and "contributors". > With git now, I believe the situation is even a bit more extreme, > because the committer is the contributor and the lucene "committer" > was really the "pusher". > > On the other hand, there were some reasons against removing this > before. In particular some mentioned that it conveyed meaning about > who might be the best person to ping about a particular area of the > code. If this is still the case, I'd ask that we discuss alternative > ways that it could be accomplished (such as wiki page perhaps > linked-to HowToContribute that ppl can edit). > > I wrote a new summary/argument inline, but see the linked thread for > the previous discussion: > > > In the past CHANGES.txt entries from a contributor have also had the > name of the committer with a 'via' entry. > > e.g.: > > LUCENE-1234: optimized FooBar. (Jane Doe via Joe Schmoe). > > I propose we stop adding the committer name (via Joe Schmoe). It seems > to diminish the value of the contribution. It reminds me of a > professor adding a second author by default or something like that. If > someone really wants to know who committed the change, I think its > fair that they look at version control history? > > 1. http://mail-archives.apache.org/mod_mbox/lucene-dev/201206. > mbox/%3CCAOdYfZW65MXrzyRPsvBD0C6c4X%2BLuQX4oVec%3DyR_ > PCPgTQrnhQ%40mail.gmail.com%3E > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Commented] (LUCENE-8343) BlendedInfixSuggester bad score calculus for certain suggestion weights
[ https://issues.apache.org/jira/browse/LUCENE-8343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510024#comment-16510024 ] Michael McCandless commented on LUCENE-8343: I agree the proposed fix seems somewhat hacky; could we maybe catch these "invalid" weight values during indexing and throw an exception, asking the user to pick more appropriate weights? And also +1 to discussing switching to double instead of long for our suggesters; maybe open a spinoff issue to discuss? > BlendedInfixSuggester bad score calculus for certain suggestion weights > --- > > Key: LUCENE-8343 > URL: https://issues.apache.org/jira/browse/LUCENE-8343 > Project: Lucene - Core > Issue Type: Bug > Components: core/search >Affects Versions: 7.3.1 >Reporter: Alessandro Benedetti >Priority: Major > Attachments: LUCENE-8343.patch, LUCENE-8343.patch, LUCENE-8343.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Currently the BlendedInfixSuggester return a (long) score to rank the > suggestions. > This score is calculated as a multiplication between : > long *Weight* : the suggestion weight, coming from a document field, it can > be any long value ( including 1, 0,.. ) > double *Coefficient* : 0<=x<=1, calculated based on the position match, > earlier the better > The resulting score is a long, which means that at the moment, any weight<10 > can bring inconsistencies. > *Edge cases* > Weight =1 > Score = 1( if we have a match at the beginning of the suggestion) or 0 ( for > any other match) > Weight =0 > Score = 0 ( independently of the position match coefficient) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11277) Add auto hard commit setting based on tlog size
[ https://issues.apache.org/jira/browse/SOLR-11277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510006#comment-16510006 ] Cassandra Targett commented on SOLR-11277: -- [~anshumg] - Docs look great, thanks. Do you want me to commit it for you while you're traveling? > Add auto hard commit setting based on tlog size > --- > > Key: SOLR-11277 > URL: https://issues.apache.org/jira/browse/SOLR-11277 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Rupa Shankar >Assignee: Anshum Gupta >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: SOLR-11277.01.patch, SOLR-11277.02.patch, > SOLR-11277.patch, SOLR-11277.patch, SOLR-11277.patch, SOLR-11277.patch, > SOLR-11277.patch, SOLR-11277.patch, SOLR-11277.patch, > max_size_auto_commit.patch > > Time Spent: 20m > Remaining Estimate: 0h > > When indexing documents of variable sizes and at variable schedules, it can > be hard to estimate the optimal auto hard commit maxDocs or maxTime settings. > We’ve had some occurrences of really huge tlogs, resulting in serious issues, > so in an attempt to avoid this, it would be great to have a “maxSize” setting > based on the tlog size on disk. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))
[ https://issues.apache.org/jira/browse/LUCENE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510005#comment-16510005 ] Michael McCandless commented on LUCENE-8041: +1 to make term vectors consistent across the index; it has always been strange that Lucene allows this. Maybe open a separate issue for that? > All Fields.terms(fld) impls should be O(1) not O(log(N)) > > > Key: LUCENE-8041 > URL: https://issues.apache.org/jira/browse/LUCENE-8041 > Project: Lucene - Core > Issue Type: Improvement >Reporter: David Smiley >Priority: Major > Attachments: LUCENE-8041.patch > > > I've seen apps that have a good number of fields -- hundreds. The O(log(N)) > of TreeMap definitely shows up in a profiler; sometimes 20% of search time, > if I recall. There are many Field implementations that are impacted... in > part because Fields is the base class of FieldsProducer. > As an aside, I hope Fields to go away some day; FieldsProducer should be > TermsProducer and not have an iterator of fields. If DocValuesProducer > doesn't have this then why should the terms index part of our API have it? > If we did this then the issue here would be a simple transition to a HashMap. > Or maybe we can switch to HashMap and relax the definition of Fields.iterator > to not necessarily be sorted? > Perhaps the fix can be a relatively simple conversion over to LinkedHashMap > in many cases if we can assume when we initialize these internal maps that we > consume them in sorted order to begin with. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11216) Make PeerSync more robust
[ https://issues.apache.org/jira/browse/SOLR-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509971#comment-16509971 ] hamada commented on SOLR-11216: --- from 20,000 foot level. Any time based solution is just brittle, solution 2 sounds like a workaround. solution 3 seems to fit the bill. > Make PeerSync more robust > - > > Key: SOLR-11216 > URL: https://issues.apache.org/jira/browse/SOLR-11216 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Priority: Major > Attachments: SOLR-11216.patch > > > First of all, I will change the issue's title with a better name when I have. > When digging into SOLR-10126. I found a case that can make peerSync fail. > * leader and replica receive update from 1 to 4 > * replica stop > * replica miss updates 5, 6 > * replica start recovery > ## replica buffer updates 7, 8 > ## replica request versions from leader, > ## in the same time leader receive update 9, so it will return updates from 1 > to 9 (for request versions) when replica get recent versions ( so it will be > 1,2,3,4,5,6,7,8,9 ) > ## replica do peersync and request updates 5, 6, 9 from leader > ## replica apply updates 5, 6, 9. Its index does not have update 7, 8 and > maxVersionSpecified for fingerprint is 9, therefore compare fingerprint will > fail > My idea here is why replica request update 9 (step 6) while it knows that > updates with lower version ( update 7, 8 ) are on its buffering tlog. Should > we request only updates that lower than the lowest update in its buffering > tlog ( < 7 )? > Someone my ask that what if replica won't receive update 9. In that case, > leader will put the replica into LIR state, so replica will run recovery > process again. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9685) tag a query in JSON syntax
[
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated SOLR-9685:
Attachment: SOLR-9685-doc.patch
> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685-doc.patch,
> SOLR-9685.patch, SOLR-9685.patch, SOLR-9685.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9685) tag a query in JSON syntax
[
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509858#comment-16509858
]
Cassandra Targett commented on SOLR-9685:
-
I updated the doc patch. It no longer applied after some other changes I made
yesterday so the line numbers didn't match up (I removed all the anchors - the
preference is to use those only when absolutely necessary so it's easier for
people to know how to construct cross-references to other sections). I also did
some light copy editing - if you're OK with it, go ahead and commit it to all 3
branches when you're ready.
> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685-doc.patch,
> SOLR-9685.patch, SOLR-9685.patch, SOLR-9685.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Propose hiding/removing JIRA Environment text input
OK, I made them the same order, with the addition of the Lucene Fields for LUCENE before Environment: Description Labels Attachments Environment On Tue, Jun 12, 2018 at 10:29 AM Cassandra Targett wrote: > Yeah, I wasn't sure if folks would want the labels up higher in LUCENE. > It's easy to fix though if the preference is the two forms be mostly the > same (with the exception of the "Lucene Fields"). > > On Tue, Jun 12, 2018 at 10:11 AM David Smiley > wrote: > >> Much better Cassandra; thanks! >> >> BTW I noticed some small differences in field order on the create screen >> between Lucene and Solr. Solr now has the Environment field at the very >> bottom whereas Lucene has "Lucene Fields" and "Labels" below it. Doesn't >> matter I guess. >> >> On Tue, Jun 12, 2018 at 10:29 AM Cassandra Targett >> wrote: >> >>> OK, this is done. >>> >>> I was rather aggressive about removing fields for the SOLR project that >>> I know we don't use, but much less so for the LUCENE project. I did ensure >>> that the Environment field is after Description in both projects. >>> >>> I used a mix of looking up the field description in JIRA, querying to >>> see if a field was populated in the JIRA db, and looking up INFRA issues to >>> find out why the field might have been added before removing fields I >>> didn't know already. I have less familiarity with LUCENE issues, so I took >>> a lighter hand, not wanting to ruin individual workflows I'm not fully >>> aware of. >>> >>> As an example, I removed the "Bugzilla ID" field from SOLR screens >>> because it contained no data in the db, but kept it for LUCENE because it >>> does have historical data. I removed "Bugtraq ID" for both, since neither >>> had data there. A "Status Whiteboard" field appeared in the list 3 times >>> but doesn't display and I couldn't figure out at all, so I removed all of >>> them (and that fieldname appears 4x in the JIRA db, but is only used on one >>> single issue system-wide...Oh JIRA & your duplicate fieldnames...). >>> >>> There's probably more to do to tighten it all up, but I thought that was >>> good enough for now and the main goal is accomplished (move Environment >>> down). >>> >>> If I screwed something up, I apologize in advance - let me know and I'll >>> try to put it back. Issues looked the same to me before and afterwards (I >>> checked several, in both projects), but you never know with JIRA when a >>> field is lurking somewhere. >>> >>> Hope it helps - >>> Cassandra >>> >>> On Tue, Jun 12, 2018 at 8:34 AM Cassandra Targett >>> wrote: >>> Sure, David, I'll do it this morning. When I looked at the fields list for the form in JIRA, there are over 100 fields set up to display on that form - there's some other bit of arcane JIRA configuration that defines the fields available for the project - but I'll remove all but the ones I know we use so they don't just appear one day and confuse us all again (in case you're curious, some are related to Bugzilla integration, some are for Hadoop projects, some are duplicates, etc.). On Tue, Jun 12, 2018 at 7:47 AM David Smiley wrote: > Cassandra, can you please try editing the JIRA config to re-order > Environment below Description? I suppose Atlassian chose the current > order > because it matches the order it's seen when viewing the issue, which makes > sense but I don't mind sacrificing that -- whatever it takes to diminish > Environment. > > IMO it also is only suitable for a "bug" and not other issue types. > > We also don't use "Sprint"; can you remove that? > > Scope creep ok and these Lucene Fields, two checkboxes, New and > Patch Available... I just don't think we really use this but I should > raise > this separately. > > On Fri, Jun 8, 2018 at 2:52 PM Steve Rowe wrote: > >> +1 to try to fix the form ourselves, thanks Cassandra. I think >> putting Description above Environment will do the trick. (I just created >> an issue and put the description in the environment field…) >> >> -- >> Steve >> www.lucidworks.com >> >> > On Jun 8, 2018, at 8:44 AM, Cassandra Targett < >> casstarg...@gmail.com> wrote: >> > >> > I've been debating saying something about this too - I think it >> happened when INFRA added some text to direct users to use the mailing >> list >> or IRC if they really have a support question instead of a bug >> (INFRA-16507). >> > >> > The most basic solution is a simple re-ordering of the form, which >> in JIRA is really easy to do. We could put the environment field near the >> bottom and if someone is paying attention to the form and wants to fill >> it >> in, fine, but the rest of us can get at the most commonly used/needed >> fields quicker. >> > >> > As I was writing that I thought I'd refresh my memory of where >>
Re: Propose hiding/removing JIRA Environment text input
Yeah, I wasn't sure if folks would want the labels up higher in LUCENE. It's easy to fix though if the preference is the two forms be mostly the same (with the exception of the "Lucene Fields"). On Tue, Jun 12, 2018 at 10:11 AM David Smiley wrote: > Much better Cassandra; thanks! > > BTW I noticed some small differences in field order on the create screen > between Lucene and Solr. Solr now has the Environment field at the very > bottom whereas Lucene has "Lucene Fields" and "Labels" below it. Doesn't > matter I guess. > > On Tue, Jun 12, 2018 at 10:29 AM Cassandra Targett > wrote: > >> OK, this is done. >> >> I was rather aggressive about removing fields for the SOLR project that I >> know we don't use, but much less so for the LUCENE project. I did ensure >> that the Environment field is after Description in both projects. >> >> I used a mix of looking up the field description in JIRA, querying to see >> if a field was populated in the JIRA db, and looking up INFRA issues to >> find out why the field might have been added before removing fields I >> didn't know already. I have less familiarity with LUCENE issues, so I took >> a lighter hand, not wanting to ruin individual workflows I'm not fully >> aware of. >> >> As an example, I removed the "Bugzilla ID" field from SOLR screens >> because it contained no data in the db, but kept it for LUCENE because it >> does have historical data. I removed "Bugtraq ID" for both, since neither >> had data there. A "Status Whiteboard" field appeared in the list 3 times >> but doesn't display and I couldn't figure out at all, so I removed all of >> them (and that fieldname appears 4x in the JIRA db, but is only used on one >> single issue system-wide...Oh JIRA & your duplicate fieldnames...). >> >> There's probably more to do to tighten it all up, but I thought that was >> good enough for now and the main goal is accomplished (move Environment >> down). >> >> If I screwed something up, I apologize in advance - let me know and I'll >> try to put it back. Issues looked the same to me before and afterwards (I >> checked several, in both projects), but you never know with JIRA when a >> field is lurking somewhere. >> >> Hope it helps - >> Cassandra >> >> On Tue, Jun 12, 2018 at 8:34 AM Cassandra Targett >> wrote: >> >>> Sure, David, I'll do it this morning. >>> >>> When I looked at the fields list for the form in JIRA, there are over >>> 100 fields set up to display on that form - there's some other bit of >>> arcane JIRA configuration that defines the fields available for the project >>> - but I'll remove all but the ones I know we use so they don't just appear >>> one day and confuse us all again (in case you're curious, some are related >>> to Bugzilla integration, some are for Hadoop projects, some are duplicates, >>> etc.). >>> >>> On Tue, Jun 12, 2018 at 7:47 AM David Smiley >>> wrote: >>> Cassandra, can you please try editing the JIRA config to re-order Environment below Description? I suppose Atlassian chose the current order because it matches the order it's seen when viewing the issue, which makes sense but I don't mind sacrificing that -- whatever it takes to diminish Environment. IMO it also is only suitable for a "bug" and not other issue types. We also don't use "Sprint"; can you remove that? Scope creep ok and these Lucene Fields, two checkboxes, New and Patch Available... I just don't think we really use this but I should raise this separately. On Fri, Jun 8, 2018 at 2:52 PM Steve Rowe wrote: > +1 to try to fix the form ourselves, thanks Cassandra. I think > putting Description above Environment will do the trick. (I just created > an issue and put the description in the environment field…) > > -- > Steve > www.lucidworks.com > > > On Jun 8, 2018, at 8:44 AM, Cassandra Targett > wrote: > > > > I've been debating saying something about this too - I think it > happened when INFRA added some text to direct users to use the mailing > list > or IRC if they really have a support question instead of a bug > (INFRA-16507). > > > > The most basic solution is a simple re-ordering of the form, which > in JIRA is really easy to do. We could put the environment field near the > bottom and if someone is paying attention to the form and wants to fill it > in, fine, but the rest of us can get at the most commonly used/needed > fields quicker. > > > > As I was writing that I thought I'd refresh my memory of where > screen editing is done in JIRA, and it looks like those of us with > committer status have access to edit that form. So we can solve this > quickly, and probably we can do it on our own without asking INFRA. > > > > If we come to consensus on either burying or removing the field, I'd > be happy to be the one that makes the change. > > > >
[jira] [Commented] (SOLR-12208) Don't use "INDEX.sizeInBytes" as a tag name in policy calculations
[ https://issues.apache.org/jira/browse/SOLR-12208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509746#comment-16509746 ] ASF subversion and git services commented on SOLR-12208: Commit e8d37eb8e9b4b133710a3ecdbc3849605b204452 in lucene-solr's branch refs/heads/branch_7x from Andrzej Bialecki [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e8d37eb ] SOLR-12208: Add simulator support for properly tracking INDEX.sizeInBytes and INDEX.sizeInGB. > Don't use "INDEX.sizeInBytes" as a tag name in policy calculations > -- > > Key: SOLR-12208 > URL: https://issues.apache.org/jira/browse/SOLR-12208 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Fix For: master (8.0), 7.5 > > Attachments: SOLR-12208.patch, SOLR-12208.patch, SOLR-12208.patch > > > CORE_IDX and FREEDISK ConditionType reuse this metric name, but they assume > the values are expressed in gigabytes. This alone is confusing considering > the name of the metric. > Additionally, it causes conflicts in the simulation framework that would > require substantial changes to resolve (ReplicaInfo-s in > SimClusterStateProvider keep metric values in their variables, expressed in > original units - but then the Policy assumes it can put the values expressed > in GB under the same key... hilarity ensues). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Propose hiding/removing JIRA Environment text input
Much better Cassandra; thanks! BTW I noticed some small differences in field order on the create screen between Lucene and Solr. Solr now has the Environment field at the very bottom whereas Lucene has "Lucene Fields" and "Labels" below it. Doesn't matter I guess. On Tue, Jun 12, 2018 at 10:29 AM Cassandra Targett wrote: > OK, this is done. > > I was rather aggressive about removing fields for the SOLR project that I > know we don't use, but much less so for the LUCENE project. I did ensure > that the Environment field is after Description in both projects. > > I used a mix of looking up the field description in JIRA, querying to see > if a field was populated in the JIRA db, and looking up INFRA issues to > find out why the field might have been added before removing fields I > didn't know already. I have less familiarity with LUCENE issues, so I took > a lighter hand, not wanting to ruin individual workflows I'm not fully > aware of. > > As an example, I removed the "Bugzilla ID" field from SOLR screens because > it contained no data in the db, but kept it for LUCENE because it does have > historical data. I removed "Bugtraq ID" for both, since neither had data > there. A "Status Whiteboard" field appeared in the list 3 times but doesn't > display and I couldn't figure out at all, so I removed all of them (and > that fieldname appears 4x in the JIRA db, but is only used on one single > issue system-wide...Oh JIRA & your duplicate fieldnames...). > > There's probably more to do to tighten it all up, but I thought that was > good enough for now and the main goal is accomplished (move Environment > down). > > If I screwed something up, I apologize in advance - let me know and I'll > try to put it back. Issues looked the same to me before and afterwards (I > checked several, in both projects), but you never know with JIRA when a > field is lurking somewhere. > > Hope it helps - > Cassandra > > On Tue, Jun 12, 2018 at 8:34 AM Cassandra Targett > wrote: > >> Sure, David, I'll do it this morning. >> >> When I looked at the fields list for the form in JIRA, there are over 100 >> fields set up to display on that form - there's some other bit of arcane >> JIRA configuration that defines the fields available for the project - but >> I'll remove all but the ones I know we use so they don't just appear one >> day and confuse us all again (in case you're curious, some are related to >> Bugzilla integration, some are for Hadoop projects, some are duplicates, >> etc.). >> >> On Tue, Jun 12, 2018 at 7:47 AM David Smiley >> wrote: >> >>> Cassandra, can you please try editing the JIRA config to re-order >>> Environment below Description? I suppose Atlassian chose the current order >>> because it matches the order it's seen when viewing the issue, which makes >>> sense but I don't mind sacrificing that -- whatever it takes to diminish >>> Environment. >>> >>> IMO it also is only suitable for a "bug" and not other issue types. >>> >>> We also don't use "Sprint"; can you remove that? >>> >>> Scope creep ok and these Lucene Fields, two checkboxes, New and >>> Patch Available... I just don't think we really use this but I should raise >>> this separately. >>> >>> On Fri, Jun 8, 2018 at 2:52 PM Steve Rowe wrote: >>> +1 to try to fix the form ourselves, thanks Cassandra. I think putting Description above Environment will do the trick. (I just created an issue and put the description in the environment field…) -- Steve www.lucidworks.com > On Jun 8, 2018, at 8:44 AM, Cassandra Targett wrote: > > I've been debating saying something about this too - I think it happened when INFRA added some text to direct users to use the mailing list or IRC if they really have a support question instead of a bug (INFRA-16507). > > The most basic solution is a simple re-ordering of the form, which in JIRA is really easy to do. We could put the environment field near the bottom and if someone is paying attention to the form and wants to fill it in, fine, but the rest of us can get at the most commonly used/needed fields quicker. > > As I was writing that I thought I'd refresh my memory of where screen editing is done in JIRA, and it looks like those of us with committer status have access to edit that form. So we can solve this quickly, and probably we can do it on our own without asking INFRA. > > If we come to consensus on either burying or removing the field, I'd be happy to be the one that makes the change. > > On Fri, Jun 8, 2018 at 7:24 AM David Smiley wrote: > Many of us have accidentally added a long-form description of our JIRA issues into the Environment field of JIRA instead of the Description. I think we can agree this is pretty annoying. It seems to have been happening more lately with a change to JIRA that for whatever reason has made
[jira] [Commented] (LUCENE-8352) Make TokenStreamComponents final
[ https://issues.apache.org/jira/browse/LUCENE-8352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509726#comment-16509726 ] Mike Sokolov commented on LUCENE-8352: -- bq So maybe we could remove this setReader method, make TokenStreamComponents final, and replace the tokenizer field with a Consumer that would be tokenizer::setReader by default? I think that would work for me, yes, and not too difficult either :) > Make TokenStreamComponents final > > > Key: LUCENE-8352 > URL: https://issues.apache.org/jira/browse/LUCENE-8352 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Mark Harwood >Priority: Minor > > The current design is a little trappy. Any specialised subclasses of > TokenStreamComponents _(see_ _StandardAnalyzer, ClassicAnalyzer, > UAX29URLEmailAnalyzer)_ are discarded by any subsequent Analyzers that wrap > them _(see LimitTokenCountAnalyzer, QueryAutoStopWordAnalyzer, > ShingleAnalyzerWrapper and other examples in elasticsearch)_. > The current design means each AnalyzerWrapper.wrapComponents() implementation > discards any custom TokenStreamComponents and replaces it with one of its own > choosing (a vanilla TokenStreamComponents class from examples I've seen). > This is a trap I fell into when writing a custom TokenStreamComponents with a > custom setReader() and I wondered why it was not being triggered when wrapped > by other analyzers. > If AnalyzerWrapper is designed to encourage composition it's arguably a > mistake to also permit custom TokenStreamComponent subclasses - the > composition process does not preserve the choice of custom classes and any > behaviours they might add. For this reason we should not encourage extensions > to TokenStreamComponents (or if TSC extensions are required we should somehow > mark an Analyzer as "unwrappable" to prevent lossy compositions). > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8352) Make TokenStreamComponents final
[
https://issues.apache.org/jira/browse/LUCENE-8352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509726#comment-16509726
]
Mike Sokolov edited comment on LUCENE-8352 at 6/12/18 3:05 PM:
---
{quote}So maybe we could remove this setReader method, make
TokenStreamComponents final, and replace the tokenizer field with a
Consumer that would be tokenizer::setReader by default?{quote}
I think that would work for me, yes, and not too difficult either :)
was (Author: sokolov):
bq So maybe we could remove this setReader method, make TokenStreamComponents
final, and replace the tokenizer field with a Consumer that would be
tokenizer::setReader by default?
I think that would work for me, yes, and not too difficult either :)
> Make TokenStreamComponents final
>
>
> Key: LUCENE-8352
> URL: https://issues.apache.org/jira/browse/LUCENE-8352
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Mark Harwood
>Priority: Minor
>
> The current design is a little trappy. Any specialised subclasses of
> TokenStreamComponents _(see_ _StandardAnalyzer, ClassicAnalyzer,
> UAX29URLEmailAnalyzer)_ are discarded by any subsequent Analyzers that wrap
> them _(see LimitTokenCountAnalyzer, QueryAutoStopWordAnalyzer,
> ShingleAnalyzerWrapper and other examples in elasticsearch)_.
> The current design means each AnalyzerWrapper.wrapComponents() implementation
> discards any custom TokenStreamComponents and replaces it with one of its own
> choosing (a vanilla TokenStreamComponents class from examples I've seen).
> This is a trap I fell into when writing a custom TokenStreamComponents with a
> custom setReader() and I wondered why it was not being triggered when wrapped
> by other analyzers.
> If AnalyzerWrapper is designed to encourage composition it's arguably a
> mistake to also permit custom TokenStreamComponent subclasses - the
> composition process does not preserve the choice of custom classes and any
> behaviours they might add. For this reason we should not encourage extensions
> to TokenStreamComponents (or if TSC extensions are required we should somehow
> mark an Analyzer as "unwrappable" to prevent lossy compositions).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #395: WIP SOLR-12362: add tests for working relatio...
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/395#discussion_r194765026
--- Diff: solr/core/src/java/org/apache/solr/handler/loader/JsonLoader.java
---
@@ -664,8 +672,38 @@ private Object parseSingleFieldValue(int ev, String
fieldName) throws IOExceptio
if (ev == JSONParser.ARRAY_END) {
return lst;
}
-Object val = parseSingleFieldValue(ev, fieldName);
+Object val = parseSingleFieldValue(ev, sif);
lst.add(val);
+sif.setValue(null);
+ }
+}
+
+private boolean isChildDoc(SolrInputDocument extendedMap) {
+ return
extendedMap.containsKey(req.getSchema().getUniqueKeyField().getName());
+}
+
+private boolean entryIsChildDoc(Object val) {
+ if(val instanceof List) {
+List listVal = (List) val;
+if (listVal.size() == 0) return false;
+return listVal.get(0) instanceof Map;
+ }
+ return val instanceof Map;
+}
+
+private SolrInputDocument generateExtendedValueDoc(int ev) throws
IOException {
--- End diff --
the name seems off -- 'generate' isn't bad but this method is parsing and
plenty of other methods here parse and are named as such so I think this should
be `parseExtendedValueAsDoc` or better `parseExtendedFieldValueAsDoc` since it
is only called by `parseExtendedFieldValue`.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #395: WIP SOLR-12362: add tests for working relatio...
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/395#discussion_r194766692
--- Diff: solr/core/src/java/org/apache/solr/handler/loader/JsonLoader.java
---
@@ -664,8 +672,38 @@ private Object parseSingleFieldValue(int ev, String
fieldName) throws IOExceptio
if (ev == JSONParser.ARRAY_END) {
return lst;
}
-Object val = parseSingleFieldValue(ev, fieldName);
+Object val = parseSingleFieldValue(ev, sif);
lst.add(val);
+sif.setValue(null);
+ }
+}
+
+private boolean isChildDoc(SolrInputDocument extendedMap) {
--- End diff --
rename extendedMap to extendedFieldValue
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #395: WIP SOLR-12362: add tests for working relatio...
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/395#discussion_r194768590
--- Diff: solr/core/src/java/org/apache/solr/handler/loader/JsonLoader.java
---
@@ -556,82 +572,71 @@ private void parseFieldValue(SolrInputField sif)
throws IOException {
if (ev == JSONParser.OBJECT_START) {
parseExtendedFieldValue(sif, ev);
} else {
-Object val = parseNormalFieldValue(ev, sif.getName());
+Object val = parseNormalFieldValue(ev, sif);
sif.setValue(val);
}
}
private void parseExtendedFieldValue(SolrInputField sif, int ev)
throws IOException {
assert ev == JSONParser.OBJECT_START;
- Object normalFieldValue = null;
- Map extendedInfo = null;
+ SolrInputDocument extendedSolrDocument =
generateExtendedValueDoc(ev);
- for (; ; ) {
-ev = parser.nextEvent();
-switch (ev) {
- case JSONParser.STRING:
-String label = parser.getString();
-if ("boost".equals(label)) {
- ev = parser.nextEvent();
- if (ev != JSONParser.NUMBER &&
- ev != JSONParser.LONG &&
- ev != JSONParser.BIGNUMBER) {
-throw new
SolrException(SolrException.ErrorCode.BAD_REQUEST, "Boost should have number. "
-+ "Unexpected " + JSONParser.getEventString(ev) + " at
[" + parser.getPosition() + "], field=" + sif.getName());
- }
+ if (isChildDoc(extendedSolrDocument)) {
+SolrInputDocument cDoc = new SolrInputDocument();
+for (Map.Entry extendedEntry:
extendedSolrDocument.entrySet()) {
+ cDoc.setField(extendedEntry.getKey(),
extendedEntry.getValue().getValue());
+}
+sif.addValue(cDoc);
+return;
+ }
- String message = "Ignoring field boost: " +
parser.getDouble() + " as index-time boosts are not supported anymore";
- if (WARNED_ABOUT_INDEX_TIME_BOOSTS.compareAndSet(false,
true)) {
-log.warn(message);
- } else {
-log.debug(message);
- }
-} else if ("value".equals(label)) {
- normalFieldValue = parseNormalFieldValue(parser.nextEvent(),
sif.getName());
-} else {
- // If we encounter other unknown map keys, then use a map
- if (extendedInfo == null) {
-extendedInfo = new HashMap<>(2);
- }
- // for now, the only extended info will be field values
- // we could either store this as an Object or a
SolrInputField
- Object val = parseNormalFieldValue(parser.nextEvent(),
sif.getName());
- extendedInfo.put(label, val);
-}
-break;
+ Object normalFieldValue = null;
+ Map extendedInfo = null;
- case JSONParser.OBJECT_END:
-if (extendedInfo != null) {
- if (normalFieldValue != null) {
-extendedInfo.put("value", normalFieldValue);
- }
- sif.setValue(extendedInfo);
-} else {
- sif.setValue(normalFieldValue);
-}
-return;
+ for (String label: extendedSolrDocument.keySet() ) {
--- End diff --
Whenever I see looping over keys from a map-like thing, I often see a line
of code that then fetches the value, as seen here. This internally results in
a bunch of lookups that aren't necessary. Instead, note that
SolrInputDocument is Iterable (which itself has the key and
value), so just loop over that.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #395: WIP SOLR-12362: add tests for working relatio...
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/395#discussion_r194761432
--- Diff: solr/core/src/java/org/apache/solr/handler/loader/JsonLoader.java
---
@@ -664,8 +672,38 @@ private Object parseSingleFieldValue(int ev, String
fieldName) throws IOExceptio
if (ev == JSONParser.ARRAY_END) {
return lst;
}
-Object val = parseSingleFieldValue(ev, fieldName);
+Object val = parseSingleFieldValue(ev, sif);
lst.add(val);
+sif.setValue(null);
+ }
+}
+
+private boolean isChildDoc(SolrInputDocument extendedMap) {
+ return
extendedMap.containsKey(req.getSchema().getUniqueKeyField().getName());
+}
+
+private boolean entryIsChildDoc(Object val) {
+ if(val instanceof List) {
+List listVal = (List) val;
+if (listVal.size() == 0) return false;
+return listVal.get(0) instanceof Map;
+ }
+ return val instanceof Map;
+}
+
+private SolrInputDocument generateExtendedValueDoc(int ev) throws
IOException {
+ assert ev == JSONParser.OBJECT_START;
+ SolrInputDocument extendedInfo = new SolrInputDocument();
+
+ while(true) {
+ev = parser.nextEvent();
+if (ev == JSONParser.OBJECT_END) {
+ return extendedInfo;
+}
+String label = parser.getString();
+SolrInputField sif = new SolrInputField(label);
+parseFieldValue(sif);
+extendedInfo.addField(label, sif.getValue());
--- End diff --
I think you can use extendedInfo.putField(key,SolrInputField) here? Oh I
see comments elsewhere in this file explaining why addField is used; maybe
copy-paste those comments?
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #395: WIP SOLR-12362: add tests for working relatio...
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/395#discussion_r194761077
--- Diff: solr/core/src/java/org/apache/solr/handler/loader/JsonLoader.java
---
@@ -556,82 +572,71 @@ private void parseFieldValue(SolrInputField sif)
throws IOException {
if (ev == JSONParser.OBJECT_START) {
parseExtendedFieldValue(sif, ev);
} else {
-Object val = parseNormalFieldValue(ev, sif.getName());
+Object val = parseNormalFieldValue(ev, sif);
sif.setValue(val);
}
}
private void parseExtendedFieldValue(SolrInputField sif, int ev)
throws IOException {
assert ev == JSONParser.OBJECT_START;
- Object normalFieldValue = null;
- Map extendedInfo = null;
+ SolrInputDocument extendedSolrDocument =
generateExtendedValueDoc(ev);
- for (; ; ) {
-ev = parser.nextEvent();
-switch (ev) {
- case JSONParser.STRING:
-String label = parser.getString();
-if ("boost".equals(label)) {
- ev = parser.nextEvent();
- if (ev != JSONParser.NUMBER &&
- ev != JSONParser.LONG &&
- ev != JSONParser.BIGNUMBER) {
-throw new
SolrException(SolrException.ErrorCode.BAD_REQUEST, "Boost should have number. "
-+ "Unexpected " + JSONParser.getEventString(ev) + " at
[" + parser.getPosition() + "], field=" + sif.getName());
- }
+ if (isChildDoc(extendedSolrDocument)) {
+SolrInputDocument cDoc = new SolrInputDocument();
+for (Map.Entry extendedEntry:
extendedSolrDocument.entrySet()) {
+ cDoc.setField(extendedEntry.getKey(),
extendedEntry.getValue().getValue());
--- End diff --
Why can't you simply do sif.addValue(extendedSolrDocument)? Thus avoiding
the rebuilding of a SolrInputDocument that seems to have no purpose.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #395: WIP SOLR-12362: add tests for working relatio...
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/395#discussion_r194760654
--- Diff: solr/core/src/java/org/apache/solr/handler/loader/JsonLoader.java
---
@@ -556,82 +572,71 @@ private void parseFieldValue(SolrInputField sif)
throws IOException {
if (ev == JSONParser.OBJECT_START) {
parseExtendedFieldValue(sif, ev);
} else {
-Object val = parseNormalFieldValue(ev, sif.getName());
+Object val = parseNormalFieldValue(ev, sif);
sif.setValue(val);
}
}
private void parseExtendedFieldValue(SolrInputField sif, int ev)
throws IOException {
--- End diff --
Lets put "ev" as first arg to be more consistent
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11216) Make PeerSync more robust
[ https://issues.apache.org/jira/browse/SOLR-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509691#comment-16509691 ] Cao Manh Dat commented on SOLR-11216: - Attached a patch for this ticket, based on Solution 3. It needs more test, but the overall result seems good. > Make PeerSync more robust > - > > Key: SOLR-11216 > URL: https://issues.apache.org/jira/browse/SOLR-11216 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Priority: Major > Attachments: SOLR-11216.patch > > > First of all, I will change the issue's title with a better name when I have. > When digging into SOLR-10126. I found a case that can make peerSync fail. > * leader and replica receive update from 1 to 4 > * replica stop > * replica miss updates 5, 6 > * replica start recovery > ## replica buffer updates 7, 8 > ## replica request versions from leader, > ## in the same time leader receive update 9, so it will return updates from 1 > to 9 (for request versions) when replica get recent versions ( so it will be > 1,2,3,4,5,6,7,8,9 ) > ## replica do peersync and request updates 5, 6, 9 from leader > ## replica apply updates 5, 6, 9. Its index does not have update 7, 8 and > maxVersionSpecified for fingerprint is 9, therefore compare fingerprint will > fail > My idea here is why replica request update 9 (step 6) while it knows that > updates with lower version ( update 7, 8 ) are on its buffering tlog. Should > we request only updates that lower than the lowest update in its buffering > tlog ( < 7 )? > Someone my ask that what if replica won't receive update 9. In that case, > leader will put the replica into LIR state, so replica will run recovery > process again. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12478) make JSON.facet aware of timeAllowed
Mikhail Khludnev created SOLR-12478: --- Summary: make JSON.facet aware of timeAllowed Key: SOLR-12478 URL: https://issues.apache.org/jira/browse/SOLR-12478 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Mikhail Khludnev It make sense to prevent heavy facets from spinning infinitely by checking [timeout|https://lucene.apache.org/solr/guide/7_3/common-query-parameters.html#timeallowed-parameter]. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11216) Make PeerSync more robust
[ https://issues.apache.org/jira/browse/SOLR-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat updated SOLR-11216: Attachment: SOLR-11216.patch > Make PeerSync more robust > - > > Key: SOLR-11216 > URL: https://issues.apache.org/jira/browse/SOLR-11216 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Priority: Major > Attachments: SOLR-11216.patch > > > First of all, I will change the issue's title with a better name when I have. > When digging into SOLR-10126. I found a case that can make peerSync fail. > * leader and replica receive update from 1 to 4 > * replica stop > * replica miss updates 5, 6 > * replica start recovery > ## replica buffer updates 7, 8 > ## replica request versions from leader, > ## in the same time leader receive update 9, so it will return updates from 1 > to 9 (for request versions) when replica get recent versions ( so it will be > 1,2,3,4,5,6,7,8,9 ) > ## replica do peersync and request updates 5, 6, 9 from leader > ## replica apply updates 5, 6, 9. Its index does not have update 7, 8 and > maxVersionSpecified for fingerprint is 9, therefore compare fingerprint will > fail > My idea here is why replica request update 9 (step 6) while it knows that > updates with lower version ( update 7, 8 ) are on its buffering tlog. Should > we request only updates that lower than the lowest update in its buffering > tlog ( < 7 )? > Someone my ask that what if replica won't receive update 9. In that case, > leader will put the replica into LIR state, so replica will run recovery > process again. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Propose hiding/removing JIRA Environment text input
OK, this is done. I was rather aggressive about removing fields for the SOLR project that I know we don't use, but much less so for the LUCENE project. I did ensure that the Environment field is after Description in both projects. I used a mix of looking up the field description in JIRA, querying to see if a field was populated in the JIRA db, and looking up INFRA issues to find out why the field might have been added before removing fields I didn't know already. I have less familiarity with LUCENE issues, so I took a lighter hand, not wanting to ruin individual workflows I'm not fully aware of. As an example, I removed the "Bugzilla ID" field from SOLR screens because it contained no data in the db, but kept it for LUCENE because it does have historical data. I removed "Bugtraq ID" for both, since neither had data there. A "Status Whiteboard" field appeared in the list 3 times but doesn't display and I couldn't figure out at all, so I removed all of them (and that fieldname appears 4x in the JIRA db, but is only used on one single issue system-wide...Oh JIRA & your duplicate fieldnames...). There's probably more to do to tighten it all up, but I thought that was good enough for now and the main goal is accomplished (move Environment down). If I screwed something up, I apologize in advance - let me know and I'll try to put it back. Issues looked the same to me before and afterwards (I checked several, in both projects), but you never know with JIRA when a field is lurking somewhere. Hope it helps - Cassandra On Tue, Jun 12, 2018 at 8:34 AM Cassandra Targett wrote: > Sure, David, I'll do it this morning. > > When I looked at the fields list for the form in JIRA, there are over 100 > fields set up to display on that form - there's some other bit of arcane > JIRA configuration that defines the fields available for the project - but > I'll remove all but the ones I know we use so they don't just appear one > day and confuse us all again (in case you're curious, some are related to > Bugzilla integration, some are for Hadoop projects, some are duplicates, > etc.). > > On Tue, Jun 12, 2018 at 7:47 AM David Smiley > wrote: > >> Cassandra, can you please try editing the JIRA config to re-order >> Environment below Description? I suppose Atlassian chose the current order >> because it matches the order it's seen when viewing the issue, which makes >> sense but I don't mind sacrificing that -- whatever it takes to diminish >> Environment. >> >> IMO it also is only suitable for a "bug" and not other issue types. >> >> We also don't use "Sprint"; can you remove that? >> >> Scope creep ok and these Lucene Fields, two checkboxes, New and Patch >> Available... I just don't think we really use this but I should raise this >> separately. >> >> On Fri, Jun 8, 2018 at 2:52 PM Steve Rowe wrote: >> >>> +1 to try to fix the form ourselves, thanks Cassandra. I think putting >>> Description above Environment will do the trick. (I just created an issue >>> and put the description in the environment field…) >>> >>> -- >>> Steve >>> www.lucidworks.com >>> >>> > On Jun 8, 2018, at 8:44 AM, Cassandra Targett >>> wrote: >>> > >>> > I've been debating saying something about this too - I think it >>> happened when INFRA added some text to direct users to use the mailing list >>> or IRC if they really have a support question instead of a bug >>> (INFRA-16507). >>> > >>> > The most basic solution is a simple re-ordering of the form, which in >>> JIRA is really easy to do. We could put the environment field near the >>> bottom and if someone is paying attention to the form and wants to fill it >>> in, fine, but the rest of us can get at the most commonly used/needed >>> fields quicker. >>> > >>> > As I was writing that I thought I'd refresh my memory of where screen >>> editing is done in JIRA, and it looks like those of us with committer >>> status have access to edit that form. So we can solve this quickly, and >>> probably we can do it on our own without asking INFRA. >>> > >>> > If we come to consensus on either burying or removing the field, I'd >>> be happy to be the one that makes the change. >>> > >>> > On Fri, Jun 8, 2018 at 7:24 AM David Smiley >>> wrote: >>> > Many of us have accidentally added a long-form description of our JIRA >>> issues into the Environment field of JIRA instead of the Description. I >>> think we can agree this is pretty annoying. It seems to have been >>> happening more lately with a change to JIRA that for whatever reason has >>> made it more visually tempting to start typing there. I want to arrange >>> for some sort of fix with infra. I'm willing to work with them to explore >>> what can be done. But what should we propose infra do exactly? I'd like >>> to get a sense of that here with our community first. >>> > >>> > IMO, I don't think a dedicated Environment input field is useful when >>> someone could just as easily type anything pertinent into the description >>> field of a
[jira] [Commented] (SOLR-12209) add Paging Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-12209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509687#comment-16509687
]
Joel Bernstein commented on SOLR-12209:
---
Unfortunately no, I'm just absolutely swamped at work currently. So, this
didn't make into the 7.4 release, but I will commit as soon as I have some time
to work on it.
> add Paging Streaming Expression
> ---
>
> Key: SOLR-12209
> URL: https://issues.apache.org/jira/browse/SOLR-12209
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: mosh
>Priority: Major
> Attachments: SOLR-12209.patch, SOLR-12209.patch, SOLR-12209.patch
>
>
> Currently the closest streaming expression that allows some sort of
> pagination is top.
> I propose we add a new streaming expression, which is based on the
> RankedStream class to add offset to the stream. currently it can only be done
> in code by reading the stream until the desired offset is reached.
> The new expression will be used as such:
> {{paging(rows=3, search(collection1, q="*:*", qt="/export",
> fl="id,a_s,a_i,a_f", sort="a_f desc, a_i desc"), sort="a_f asc, a_i asc",
> start=100)}}
> {{this will offset the returned stream by 100 documents}}
>
> [~joel.bernstein] what to you think?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12208) Don't use "INDEX.sizeInBytes" as a tag name in policy calculations
[ https://issues.apache.org/jira/browse/SOLR-12208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509683#comment-16509683 ] ASF subversion and git services commented on SOLR-12208: Commit 7c4bad0e8f6c6befa1aeb79b9a047cae40134ba8 in lucene-solr's branch refs/heads/master from Andrzej Bialecki [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7c4bad0 ] SOLR-12208: Add simulator support for properly tracking INDEX.sizeInBytes and INDEX.sizeInGB. > Don't use "INDEX.sizeInBytes" as a tag name in policy calculations > -- > > Key: SOLR-12208 > URL: https://issues.apache.org/jira/browse/SOLR-12208 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Fix For: master (8.0), 7.5 > > Attachments: SOLR-12208.patch, SOLR-12208.patch, SOLR-12208.patch > > > CORE_IDX and FREEDISK ConditionType reuse this metric name, but they assume > the values are expressed in gigabytes. This alone is confusing considering > the name of the metric. > Additionally, it causes conflicts in the simulation framework that would > require substantial changes to resolve (ReplicaInfo-s in > SimClusterStateProvider keep metric values in their variables, expressed in > original units - but then the Policy assumes it can put the values expressed > in GB under the same key... hilarity ensues). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #395: WIP SOLR-12362: add tests for working relatio...
Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/395#discussion_r194755084
--- Diff: solr/core/src/java/org/apache/solr/handler/loader/JsonLoader.java
---
@@ -249,14 +251,27 @@ public void handle(Map record, String
path) {
private SolrInputDocument buildDoc(Map m) {
SolrInputDocument result = new SolrInputDocument();
for (Map.Entry e : m.entrySet()) {
-if (e.getKey() == null) {// special case. JsonRecordReader emits
child docs with null key
+if (entryIsChildDoc(e.getValue())) {// special case.
JsonRecordReader emits child docs with null key
if (e.getValue() instanceof List) {
List value = (List) e.getValue();
for (Object o : value) {
- if (o instanceof Map) result.addChildDocument(buildDoc((Map)
o));
+ if (o instanceof Map) {
+if (anonChildDocFlag) {
+ result.addChildDocument(buildDoc((Map) o));
+} else {
+ if(!result.containsKey(e.getKey())) {
+result.setField(e.getKey(), new ArrayList<>(1));
--- End diff --
Any way; lets not increase the scope of this particular issue with my idea
to add this info to the schema. It seems adequate to force the use of an
internal array for a single value in SolrInputField that we know originated
from an array.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9685) tag a query in JSON syntax
[
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509676#comment-16509676
]
Mikhail Khludnev commented on SOLR-9685:
+1.
Although, this test doesn't assert the effective tag, also it doesn't assert
currently working verbose syntax. {{"#tag":{lucene:{query:'foo:bar'
> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-9685-doc.patch, SOLR-9685.patch, SOLR-9685.patch,
> SOLR-9685.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
