Creating a single segment reader
Hi,
Currently I am using the below code to create segment readers. On a
different node, I want to create a single SegmentReader. So what is the
minimum information that I need to pass to that node so that it can create
a specific SegmentReader? I am trying to avoid serializing a lot of
low-level state information.
segmentInfos =
SegmentInfos.readLatestCommit(FSDirectory.open(Paths.get(selectionRoot)));
segmentsFilename = segmentInfos.getSegmentsFileName();
segmentReaders = new ArrayList();
for (SegmentCommitInfo sci : segmentInfos.asList()) {
segmentReaders.add(new SegmentReader(sci, IOContext.READ));
}
Any help is greatly appreciated
- Rahul
[jira] [Commented] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659546#comment-14659546 ] Gregory Chanan commented on SOLR-7855: -- Committed to trunk. I tried to merge to branch_5x, but SOLR-7766 not being there causes a bunch of conflicts. Going to wait until that is committed before proceeding. > OverseerCollectionProcessor: separate general task management from collection > message handling > -- > > Key: SOLR-7855 > URL: https://issues.apache.org/jira/browse/SOLR-7855 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7855.patch, SOLR-7855.patch, SOLR-7855.patch > > > While working on SOLR-7789, I realized it would be easier if I split up the > OverseerCollectionProcessor into two parts: > 1) General handling of tasks (work queues, etc) > 2) Processing a collection handler request > I haven't decided whether the ConfigSet should have its own processor, i.e. > OverseerConfigSetProcessor or reuse at least the thread for the > OverseerCollectionProcessor, but in either case this refactoring will be > helpful. That is, if the ConfigSet processing has its own processing, I can > reuse the general handling of tasks part. If the ConfigSet processing reuses > the OverseerCollectionProcessing thread, I won't complicate the > implementation with ConfigSet operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659545#comment-14659545 ] ASF subversion and git services commented on SOLR-7855: --- Commit 1694406 from gcha...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1694406 ] SOLR-7855: OverseerCollectionProcessor: separate general task management from collection message handling > OverseerCollectionProcessor: separate general task management from collection > message handling > -- > > Key: SOLR-7855 > URL: https://issues.apache.org/jira/browse/SOLR-7855 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7855.patch, SOLR-7855.patch, SOLR-7855.patch > > > While working on SOLR-7789, I realized it would be easier if I split up the > OverseerCollectionProcessor into two parts: > 1) General handling of tasks (work queues, etc) > 2) Processing a collection handler request > I haven't decided whether the ConfigSet should have its own processor, i.e. > OverseerConfigSetProcessor or reuse at least the thread for the > OverseerCollectionProcessor, but in either case this refactoring will be > helpful. That is, if the ConfigSet processing has its own processing, I can > reuse the general handling of tasks part. If the ConfigSet processing reuses > the OverseerCollectionProcessing thread, I won't complicate the > implementation with ConfigSet operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[CI] Lucene 5x Linux 64 Test Only - Build # 58031 - Failure!
BUILD FAILURE Build URLhttp://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/58031/ Project:lucene_linux_java8_64_test_only Randomization: JDK8,network,heap[512m],-server +UseConcMarkSweepGC +UseCompressedOops +AggressiveOpts,assert off,sec manager on Date of build:Thu, 06 Aug 2015 06:25:27 +0200 Build duration:9 min 1 sec CHANGES No Changes BUILD ARTIFACTS checkout/lucene/build/misc/test/temp/junit4-J0-20150806_063415_040.events checkout/lucene/build/misc/test/temp/junit4-J1-20150806_063415_040.events checkout/lucene/build/misc/test/temp/junit4-J2-20150806_063415_040.events checkout/lucene/build/misc/test/temp/junit4-J3-20150806_063415_040.events checkout/lucene/build/misc/test/temp/junit4-J4-20150806_063415_040.events checkout/lucene/build/misc/test/temp/junit4-J5-20150806_063415_040.events checkout/lucene/build/misc/test/temp/junit4-J6-20150806_063415_041.events checkout/lucene/build/misc/test/temp/junit4-J7-20150806_063415_041.events FAILED JUNIT TESTS Name: org.apache.lucene.search Failed: 1 test(s), Passed: 802 test(s), Skipped: 2 test(s), Total: 805 test(s) Failed: org.apache.lucene.search.TestEarlyTerminatingSortingCollector.testTerminatedEarly CONSOLE OUTPUT [...truncated 9905 lines...] [junit4] [junit4] [junit4] JVM J0: 0.61 ..12.70 =12.10s [junit4] JVM J1: 0.86 .. 8.33 = 7.47s [junit4] JVM J2: 0.89 .. 9.92 = 9.03s [junit4] JVM J3: 0.86 .. 8.37 = 7.51s [junit4] JVM J4: 0.86 .. 8.32 = 7.47s [junit4] JVM J5: 0.83 ..10.04 = 9.21s [junit4] JVM J6: 0.83 ..12.49 =11.66s [junit4] JVM J7: 0.92 ..13.07 =12.15s [junit4] Execution time total: 13 seconds [junit4] Tests summary: 25 suites, 184 tests, 1 failure, 1 ignored (1 assumption) BUILD FAILED /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:470: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:2245: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/module-build.xml:58: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1449: The following error occurred while executing this line: /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1003: There were test failures: 25 suites, 184 tests, 1 failure, 1 ignored (1 assumption) Total time: 8 minutes 40 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results [description-setter] Description set: JDK8,network,heap[512m],-server +UseConcMarkSweepGC +UseCompressedOops +AggressiveOpts,assert off,sec manager on Email was triggered for: Failure - 1st Trigger Failure - Any was overridden by another trigger and will not send an email. Trigger Failure - Still was overridden by another trigger and will not send an email. Sending email for trigger: Failure - 1st - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7873) prefix query parser fails with two words and a second field
[
https://issues.apache.org/jira/browse/SOLR-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659440#comment-14659440
]
Randy Jacobsen commented on SOLR-7873:
--
Thanks for your suggestion.
With debugQuery=on the first two queries generate what you would expect.
You can use as many terms as you want with only one field.
You can use as many fields as you want with only one term.
The third query generates "+pub_name:5 +journal_name:radar* +journal+name:c"
which is obviously bogus.
>From StackOverflow:
"Might I suggest the solr prefix query plugin if you are only using it for
wildcards on the suffix as we were
http://lucene.apache.org/solr/4_0_0/solr-core/org/apache/solr/search/PrefixQParserPlugin.html
example usage
http://localhost:8983/solr/collection/select?q={!prefix%20f=name}Bob%20Smi
would match "Bob Smith" or "Bob Smit" but not convert into a check of ("Bob" OR
"Smi*") as would happen if you used the first solution you might consider along
the lines of q=name:Bob%20Smi*
Hopefully this is of some help to you or someone else looking for a simple
solution because I was banging my head against a wall for hours before I found
this!"
> prefix query parser fails with two words and a second field
> ---
>
> Key: SOLR-7873
> URL: https://issues.apache.org/jira/browse/SOLR-7873
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.8
>Reporter: Randy Jacobsen
>Priority: Minor
>
> works: {!prefix f=journal_name}radar c
> works: pub_name:5 AND {!prefix f=journal_name}radar
> fails: pub_name:5 AND {!prefix f=journal_name}radar c
> both fields are lowercased text fields
> fail results in 0 matches
> any equivalent queries would be welcome
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7560) Parallel SQL Support
[ https://issues.apache.org/jira/browse/SOLR-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-7560: - Attachment: SOLR-7560.calcite.patch Trunk patch that works with Apache Calcite's SQL parser instead of Presto. The existing SQL tests pass with this patch. More work to be done as far as removing Presto and properly adding Calcite to the build. > Parallel SQL Support > > > Key: SOLR-7560 > URL: https://issues.apache.org/jira/browse/SOLR-7560 > Project: Solr > Issue Type: New Feature > Components: clients - java, search >Reporter: Joel Bernstein > Fix For: 5.3 > > Attachments: SOLR-7560.calcite.patch, SOLR-7560.patch, > SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch > > > This ticket provides support for executing *Parallel SQL* queries across > SolrCloud collections. The SQL engine will be built on top of the Streaming > API (SOLR-7082), which provides support for *parallel relational algebra* and > *real-time map-reduce*. > Basic design: > 1) A new SQLHandler will be added to process SQL requests. The SQL statements > will be compiled to live Streaming API objects for parallel execution across > SolrCloud worker nodes. > 2) SolrCloud collections will be abstracted as *Relational Tables*. > 3) The Presto SQL parser will be used to parse the SQL statements. > 4) A JDBC thin client will be added as a Solrj client. > This ticket will focus on putting the framework in place and providing basic > SELECT support and GROUP BY aggregate support. > Future releases will build on this framework to provide additional SQL > features. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene / Solr and Topic Modeling?
Hi Chris, Just an FYI. NLP4L has a function that extracts document vectors (in libsvm format) from Lucene index. Spark MLlib can be used for executing LDA on it. We have a short tutorial about it. See "Clustering" section in "Working with Spark" chapter. http://nlp4l.github.io/tutorial.html#useWithSpark Koji On 2015/08/01 11:12, Mattmann, Chris A (3980) wrote: Hey Folks, Does anyone know of a good ALv2 compatible approach to Lucene and to topic modeling? I’m looking to not have to do it post-facto e.g. with a specific library, but to actually perform topic modeling like LDA (or something else) while building the index. The topic modeling needs to be scalable and dynamic - e.g., if I change a query on years, the topics should be updated accordingly. Is this possible with Lucene? I’ve found this: https://github.com/stepthom/lucene-lda But it seems like it stopped short of the calls to actual topic modeling e.g., with MALLET, etc. Thanks for any help here. Cheers, Chris ++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-5.3-Linux (32bit/jdk1.8.0_60-ea-b24) - Build # 3 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.3-Linux/3/ Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.CloudExitableDirectoryReaderTest.test Error Message: No live SolrServers available to handle this request:[http://127.0.0.1:56094/collection1] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:56094/collection1] at __randomizedtesting.SeedInfo.seed([8C03942E2B1BC7F9:457ABF485E7AA01]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:355) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.queryServer(AbstractFullDistribZkTestBase.java:1376) at org.apache.solr.cloud.CloudExitableDirectoryReaderTest.assertPartialResults(CloudExitableDirectoryReaderTest.java:102) at org.apache.solr.cloud.CloudExitableDirectoryReaderTest.doTimeoutTests(CloudExitableDirectoryReaderTest.java:86) at org.apache.solr.cloud.CloudExitableDirectoryReaderTest.test(CloudExitableDirectoryReaderTest.java:53) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluat
[jira] [Updated] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Chanan updated SOLR-7855: - Attachment: SOLR-7855.patch Here's a version with Mark's comments addressed and rebased to trunk (there were some changes to OverseerCollectionProcessor). I'll commit this soon unless I hear objections. I spent some time moving the packages, but I got stuck at the ZkController. Let's move that discussion to the linked jira. > OverseerCollectionProcessor: separate general task management from collection > message handling > -- > > Key: SOLR-7855 > URL: https://issues.apache.org/jira/browse/SOLR-7855 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7855.patch, SOLR-7855.patch, SOLR-7855.patch > > > While working on SOLR-7789, I realized it would be easier if I split up the > OverseerCollectionProcessor into two parts: > 1) General handling of tasks (work queues, etc) > 2) Processing a collection handler request > I haven't decided whether the ConfigSet should have its own processor, i.e. > OverseerConfigSetProcessor or reuse at least the thread for the > OverseerCollectionProcessor, but in either case this refactoring will be > helpful. That is, if the ConfigSet processing has its own processing, I can > reuse the general handling of tasks part. If the ConfigSet processing reuses > the OverseerCollectionProcessing thread, I won't complicate the > implementation with ConfigSet operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7866) getMaxVersionFromIndex is throwing an NPE if some segments are not current
[
https://issues.apache.org/jira/browse/SOLR-7866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Potter resolved SOLR-7866.
--
Resolution: Fixed
Fix Version/s: Trunk
> getMaxVersionFromIndex is throwing an NPE if some segments are not current
> --
>
> Key: SOLR-7866
> URL: https://issues.apache.org/jira/browse/SOLR-7866
> Project: Solr
> Issue Type: Bug
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7866.patch
>
>
> Reported by user on #solr irc (via Shalin)
> {code}
> java.lang.NullPointerException
> at
> org.apache.lucene.util.NumericUtils.prefixCodedToLong(NumericUtils.java:226)
> at org.apache.lucene.util.NumericUtils.getMaxLong(NumericUtils.java:582)
> at
> org.apache.solr.update.VersionInfo.getMaxVersionFromIndex(VersionInfo.java:234)
> at
> org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1580)
> at
> org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1610)
> at org.apache.solr.core.SolrCore.seedVersionBuckets(SolrCore.java:861)
> at org.apache.solr.core.SolrCore.(SolrCore.java:843)
> at org.apache.solr.core.SolrCore.(SolrCore.java:658)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:637)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:381)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:375)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:148)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7866) getMaxVersionFromIndex is throwing an NPE if some segments are not current
[
https://issues.apache.org/jira/browse/SOLR-7866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659294#comment-14659294
]
ASF subversion and git services commented on SOLR-7866:
---
Commit 1694389 from [~thelabdude] in branch 'dev/branches/lucene_solr_5_3'
[ https://svn.apache.org/r1694389 ]
SOLR-7866: Harden code to prevent an unhandled NPE when trying to determine the
max value of the version field.
> getMaxVersionFromIndex is throwing an NPE if some segments are not current
> --
>
> Key: SOLR-7866
> URL: https://issues.apache.org/jira/browse/SOLR-7866
> Project: Solr
> Issue Type: Bug
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7866.patch
>
>
> Reported by user on #solr irc (via Shalin)
> {code}
> java.lang.NullPointerException
> at
> org.apache.lucene.util.NumericUtils.prefixCodedToLong(NumericUtils.java:226)
> at org.apache.lucene.util.NumericUtils.getMaxLong(NumericUtils.java:582)
> at
> org.apache.solr.update.VersionInfo.getMaxVersionFromIndex(VersionInfo.java:234)
> at
> org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1580)
> at
> org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1610)
> at org.apache.solr.core.SolrCore.seedVersionBuckets(SolrCore.java:861)
> at org.apache.solr.core.SolrCore.(SolrCore.java:843)
> at org.apache.solr.core.SolrCore.(SolrCore.java:658)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:637)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:381)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:375)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:148)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7866) getMaxVersionFromIndex is throwing an NPE if some segments are not current
[
https://issues.apache.org/jira/browse/SOLR-7866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659291#comment-14659291
]
ASF subversion and git services commented on SOLR-7866:
---
Commit 1694388 from [~thelabdude] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694388 ]
SOLR-7866: Harden code to prevent an unhandled NPE when trying to determine the
max value of the version field.
> getMaxVersionFromIndex is throwing an NPE if some segments are not current
> --
>
> Key: SOLR-7866
> URL: https://issues.apache.org/jira/browse/SOLR-7866
> Project: Solr
> Issue Type: Bug
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: 5.3
>
> Attachments: SOLR-7866.patch
>
>
> Reported by user on #solr irc (via Shalin)
> {code}
> java.lang.NullPointerException
> at
> org.apache.lucene.util.NumericUtils.prefixCodedToLong(NumericUtils.java:226)
> at org.apache.lucene.util.NumericUtils.getMaxLong(NumericUtils.java:582)
> at
> org.apache.solr.update.VersionInfo.getMaxVersionFromIndex(VersionInfo.java:234)
> at
> org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1580)
> at
> org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1610)
> at org.apache.solr.core.SolrCore.seedVersionBuckets(SolrCore.java:861)
> at org.apache.solr.core.SolrCore.(SolrCore.java:843)
> at org.apache.solr.core.SolrCore.(SolrCore.java:658)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:637)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:381)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:375)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:148)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_51) - Build # 13746 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13746/ Java: 32bit/jdk1.8.0_51 -server -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestCryptoKeys Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([AE7E9E22798D439C]:0) FAILED: org.apache.solr.cloud.TestCryptoKeys.test Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([AE7E9E22798D439C]:0) Build Log: [...truncated 11155 lines...] [junit4] Suite: org.apache.solr.cloud.TestCryptoKeys [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.TestCryptoKeys_AE7E9E22798D439C-001/init-core-data-001 [junit4] 2> 216657 INFO (SUITE-TestCryptoKeys-seed#[AE7E9E22798D439C]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) [junit4] 2> 216657 INFO (SUITE-TestCryptoKeys-seed#[AE7E9E22798D439C]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /vj_xb/cg [junit4] 2> 216658 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 216659 INFO (Thread-616) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 216659 INFO (Thread-616) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 216759 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.ZkTestServer start zk server on port:45421 [junit4] 2> 216759 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 216759 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 216768 INFO (zkCallback-127-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@4a2270 name:ZooKeeperConnection Watcher:127.0.0.1:45421 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 216768 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 216768 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2> 216768 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.c.SolrZkClient makePath: /solr [junit4] 2> 216770 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 216770 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 216771 INFO (zkCallback-128-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@1ada2db name:ZooKeeperConnection Watcher:127.0.0.1:45421/solr got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 216771 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 216771 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2> 216771 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.c.SolrZkClient makePath: /collections/collection1 [junit4] 2> 216772 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.c.SolrZkClient makePath: /collections/collection1/shards [junit4] 2> 216773 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.c.SolrZkClient makePath: /collections/control_collection [junit4] 2> 216773 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.c.SolrZkClient makePath: /collections/control_collection/shards [junit4] 2> 216774 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2> 216774 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.c.SolrZkClient makePath: /configs/conf1/solrconfig.xml [junit4] 2> 216775 INFO (TEST-TestCryptoKeys.test-seed#[AE7E9E22798D439C]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/schema.xml to /configs/conf1/schema.xml [j
[jira] [Commented] (LUCENE-6719) NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior when no docs have value - throw NPE
[ https://issues.apache.org/jira/browse/LUCENE-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659288#comment-14659288 ] ASF subversion and git services commented on LUCENE-6719: - Commit 1694387 from [~thelabdude] in branch 'dev/branches/lucene_solr_5_3' [ https://svn.apache.org/r1694387 ] LUCENE-6719: Fix NumericUtils getMin/Max methods to return null if there are no terms for the specified field > NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior > when no docs have value - throw NPE > --- > > Key: LUCENE-6719 > URL: https://issues.apache.org/jira/browse/LUCENE-6719 > Project: Lucene - Core > Issue Type: Bug >Reporter: Hoss Man >Assignee: Timothy Potter > Fix For: 5.3, Trunk > > Attachments: LUCENE-6719.patch, LUCENE-6719.patch, LUCENE-6719.patch, > LUCENE-6719.patch > > > Tracked down a possible cause of SOLR-7866 to situations where a (numeric) > field doesn't have any values in an index and you try to get the min/max. > javadocs for NumericUtils.getMinLong and NumericUtils.getMaxLong don't > actually say what that method will do in this case, throw NPE when it happens -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6719) NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior when no docs have value - throw NPE
[ https://issues.apache.org/jira/browse/LUCENE-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter resolved LUCENE-6719. Resolution: Fixed Fix Version/s: Trunk 5.3 > NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior > when no docs have value - throw NPE > --- > > Key: LUCENE-6719 > URL: https://issues.apache.org/jira/browse/LUCENE-6719 > Project: Lucene - Core > Issue Type: Bug >Reporter: Hoss Man >Assignee: Timothy Potter > Fix For: 5.3, Trunk > > Attachments: LUCENE-6719.patch, LUCENE-6719.patch, LUCENE-6719.patch, > LUCENE-6719.patch > > > Tracked down a possible cause of SOLR-7866 to situations where a (numeric) > field doesn't have any values in an index and you try to get the min/max. > javadocs for NumericUtils.getMinLong and NumericUtils.getMaxLong don't > actually say what that method will do in this case, throw NPE when it happens -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6719) NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior when no docs have value - throw NPE
[ https://issues.apache.org/jira/browse/LUCENE-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659285#comment-14659285 ] ASF subversion and git services commented on LUCENE-6719: - Commit 1694386 from [~thelabdude] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1694386 ] LUCENE-6719: Fix NumericUtils getMin/Max methods to return null if there are no terms for the specified field > NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior > when no docs have value - throw NPE > --- > > Key: LUCENE-6719 > URL: https://issues.apache.org/jira/browse/LUCENE-6719 > Project: Lucene - Core > Issue Type: Bug >Reporter: Hoss Man >Assignee: Timothy Potter > Attachments: LUCENE-6719.patch, LUCENE-6719.patch, LUCENE-6719.patch, > LUCENE-6719.patch > > > Tracked down a possible cause of SOLR-7866 to situations where a (numeric) > field doesn't have any values in an index and you try to get the min/max. > javadocs for NumericUtils.getMinLong and NumericUtils.getMaxLong don't > actually say what that method will do in this case, throw NPE when it happens -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7866) getMaxVersionFromIndex is throwing an NPE if some segments are not current
[
https://issues.apache.org/jira/browse/SOLR-7866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659280#comment-14659280
]
ASF subversion and git services commented on SOLR-7866:
---
Commit 1694385 from [~thelabdude] in branch 'dev/trunk'
[ https://svn.apache.org/r1694385 ]
SOLR-7866: Harden code to prevent an unhandled NPE when trying to determine the
max value of the version field.
> getMaxVersionFromIndex is throwing an NPE if some segments are not current
> --
>
> Key: SOLR-7866
> URL: https://issues.apache.org/jira/browse/SOLR-7866
> Project: Solr
> Issue Type: Bug
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: 5.3
>
> Attachments: SOLR-7866.patch
>
>
> Reported by user on #solr irc (via Shalin)
> {code}
> java.lang.NullPointerException
> at
> org.apache.lucene.util.NumericUtils.prefixCodedToLong(NumericUtils.java:226)
> at org.apache.lucene.util.NumericUtils.getMaxLong(NumericUtils.java:582)
> at
> org.apache.solr.update.VersionInfo.getMaxVersionFromIndex(VersionInfo.java:234)
> at
> org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1580)
> at
> org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1610)
> at org.apache.solr.core.SolrCore.seedVersionBuckets(SolrCore.java:861)
> at org.apache.solr.core.SolrCore.(SolrCore.java:843)
> at org.apache.solr.core.SolrCore.(SolrCore.java:658)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:637)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:381)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:375)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:148)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6719) NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior when no docs have value - throw NPE
[ https://issues.apache.org/jira/browse/LUCENE-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659273#comment-14659273 ] ASF subversion and git services commented on LUCENE-6719: - Commit 1694384 from [~thelabdude] in branch 'dev/trunk' [ https://svn.apache.org/r1694384 ] LUCENE-6719: Fix NumericUtils getMin/Max methods to return null if there are no terms for the specified field > NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior > when no docs have value - throw NPE > --- > > Key: LUCENE-6719 > URL: https://issues.apache.org/jira/browse/LUCENE-6719 > Project: Lucene - Core > Issue Type: Bug >Reporter: Hoss Man >Assignee: Timothy Potter > Attachments: LUCENE-6719.patch, LUCENE-6719.patch, LUCENE-6719.patch, > LUCENE-6719.patch > > > Tracked down a possible cause of SOLR-7866 to situations where a (numeric) > field doesn't have any values in an index and you try to get the min/max. > javadocs for NumericUtils.getMinLong and NumericUtils.getMaxLong don't > actually say what that method will do in this case, throw NPE when it happens -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6719) NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior when no docs have value - throw NPE
[ https://issues.apache.org/jira/browse/LUCENE-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter updated LUCENE-6719: --- Attachment: LUCENE-6719.patch Here's the updated patch with the lucene/CHANGES.txt entry ... I'm ready to commit this. > NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior > when no docs have value - throw NPE > --- > > Key: LUCENE-6719 > URL: https://issues.apache.org/jira/browse/LUCENE-6719 > Project: Lucene - Core > Issue Type: Bug >Reporter: Hoss Man >Assignee: Timothy Potter > Attachments: LUCENE-6719.patch, LUCENE-6719.patch, LUCENE-6719.patch, > LUCENE-6719.patch > > > Tracked down a possible cause of SOLR-7866 to situations where a (numeric) > field doesn't have any values in an index and you try to get the min/max. > javadocs for NumericUtils.getMinLong and NumericUtils.getMaxLong don't > actually say what that method will do in this case, throw NPE when it happens -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-6719) NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior when no docs have value - throw NPE
[ https://issues.apache.org/jira/browse/LUCENE-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter reassigned LUCENE-6719: -- Assignee: Timothy Potter > NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior > when no docs have value - throw NPE > --- > > Key: LUCENE-6719 > URL: https://issues.apache.org/jira/browse/LUCENE-6719 > Project: Lucene - Core > Issue Type: Bug >Reporter: Hoss Man >Assignee: Timothy Potter > Attachments: LUCENE-6719.patch, LUCENE-6719.patch, LUCENE-6719.patch > > > Tracked down a possible cause of SOLR-7866 to situations where a (numeric) > field doesn't have any values in an index and you try to get the min/max. > javadocs for NumericUtils.getMinLong and NumericUtils.getMaxLong don't > actually say what that method will do in this case, throw NPE when it happens -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6417) Upgrade ANTLR to version 4.5
[ https://issues.apache.org/jira/browse/LUCENE-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659252#comment-14659252 ] Jack Conradson edited comment on LUCENE-6417 at 8/6/15 12:30 AM: - Attached a new patch with the requested changes. All classes should be package-private now except for VariableContext and the JavascriptCompiler. The ANTLR visitor is now encapsulated in an anonymous inner class to hide the implementation details of the compiler. was (Author: jdconradson): Attached a new patch with the requested changes. All classes should be package-private now except for VariableContext and the JavascriptCompiler. > Upgrade ANTLR to version 4.5 > > > Key: LUCENE-6417 > URL: https://issues.apache.org/jira/browse/LUCENE-6417 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jack Conradson >Assignee: Uwe Schindler > Attachments: LUCENE-6417.patch, LUCENE-6471.patch, LUCENE-6471.patch, > LUCENE-6471.patch > > > I would like to upgrade ANTLR from 3.5 to 4.5. This version adds several > features that will improve the existing grammars. The main improvement would > be the allowance of left-hand recursion in grammar rules which will reduce > the number of rules significantly for expressions. > This change will require some code refactoring to the existing expressions > work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6417) Upgrade ANTLR to version 4.5
[ https://issues.apache.org/jira/browse/LUCENE-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Conradson updated LUCENE-6417: --- Attachment: LUCENE-6417.patch Attached a new patch with the requested changes. All classes should be package-private now except for VariableContext and the JavascriptCompiler. > Upgrade ANTLR to version 4.5 > > > Key: LUCENE-6417 > URL: https://issues.apache.org/jira/browse/LUCENE-6417 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jack Conradson >Assignee: Uwe Schindler > Attachments: LUCENE-6417.patch, LUCENE-6471.patch, LUCENE-6471.patch, > LUCENE-6471.patch > > > I would like to upgrade ANTLR from 3.5 to 4.5. This version adds several > features that will improve the existing grammars. The main improvement would > be the allowance of left-hand recursion in grammar rules which will reduce > the number of rules significantly for expressions. > This change will require some code refactoring to the existing expressions > work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7867) implicit sharded, facet grouping problem with multivalued string field starting with digits
[
https://issues.apache.org/jira/browse/SOLR-7867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659224#comment-14659224
]
Jonathan Gonzalez edited comment on SOLR-7867 at 8/6/15 12:02 AM:
--
The problem rely on the docValues attribute, for some reason the dvd file
becomes corrupted after several incremental feedings (at least in my case),
I'm able to reproduce this problem either on SolrCloud and Standalone instance,
the query has to have &group.facet=true and the facet field definition
docValues=true.
A short-term fix: disable the docValues attribute (docValues=false).
Fields definition:
{code}
{code}
Query:
The query is using &group.field=&group.facet=true and a
simple facet like:
{code}
&facet.field={!key=FacetKey_12345678%20facet.prefix=12345678}fieldForFacet
{code}
The following image, shows Solr reading the index file of type dvd
(Per-Document Values .dvd, .dvm - Encodes additional scoring factors or other
per-document information.
https://lucene.apache.org/core/5_2_0/core/org/apache/lucene/codecs/lucene50/Lucene50DocValuesFormat.html),
enabled by the docValues=true.
(https://cwiki.apache.org/confluence/display/solr/DocValues)
!ErrorReadingDocValues.PNG!
Then trying to read the facet.prefix value from this dvd file, there is an
attempt to read more than the current buffer size causing this issue:
!DocValuesException.PNG!
I hope it helps!
was (Author: jonathan gv):
The problem rely on docValues attribute, for some reason the dvd file becomes
corrupted after several incremental feeding, I'm able to reproduce this
problem and fix it by disabling the docValues attribute docValues=false.
Fields definition:
{code}
{code}
Query:
The query is using &group.field=&group.facet=true and a
simple facet like:
{code}
&facet.field={!key=FacetKey_12345678%20facet.prefix=12345678}fieldForFacet
{code}
The following image, shows Solr reading the index file of type dvd
(Per-Document Values .dvd, .dvm - Encodes additional scoring factors or other
per-document information.
https://lucene.apache.org/core/5_2_0/core/org/apache/lucene/codecs/lucene50/Lucene50DocValuesFormat.html),
enabled by the docValues=true.
(https://cwiki.apache.org/confluence/display/solr/DocValues)
!ErrorReadingDocValues.PNG!
Then trying to read the facet.prefix value from this dvd file, there is an
attempt to read more than the current buffer size causing this issue:
!DocValuesException.PNG!
I hope it helps!
> implicit sharded, facet grouping problem with multivalued string field
> starting with digits
> ---
>
> Key: SOLR-7867
> URL: https://issues.apache.org/jira/browse/SOLR-7867
> Project: Solr
> Issue Type: Bug
> Components: faceting, SolrCloud
>Affects Versions: 5.2
> Environment: 3.13.0-48-generic #80-Ubuntu SMP x86_64 GNU/Linux
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
>Reporter: Umut Erogul
> Labels: docValues, facet, group, sharding
> Attachments: DocValuesException.PNG, ErrorReadingDocValues.PNG
>
>
> related parts @ schema.xml:
> {code} docValues="true" multiValued="true"/>
> docValues="true"/>{code}
> every document has valid author_s and keyword_ss fields;
> we can make successful facet group queries on single node, single collection,
> solr-4.9.0 server
> {code}
> q: *:* fq: keyword_ss:3m
> facet=true&facet.field=keyword_ss&group=true&group.field=author_s&group.facet=true
> {code}
> when querying on solr-5.2.0 server with implicit sharded environment with:
> {code}
> required="true"/>{code}
> with example shard names; affinity1 affinity2 affinity3 affinity4
> the same query with same documents gets:
> {code}
> ERROR - 2015-08-04 08:15:15.222; [document affinity3 core_node32
> document_affinity3_replica2] org.apache.solr.common.SolrException;
> org.apache.solr.common.SolrException: Exception during facet.field: keyword_ss
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:632)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:617)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:571)
> at
> org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:642)
> ...
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.lucene.codecs.lucene50.Lucene50DocValuesProducer$CompressedBinaryDocValues$CompressedBinaryTermsEnum.readTerm(Lucene50DocValuesProd
[jira] [Commented] (SOLR-7867) implicit sharded, facet grouping problem with multivalued string field starting with digits
[
https://issues.apache.org/jira/browse/SOLR-7867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659224#comment-14659224
]
Jonathan Gonzalez commented on SOLR-7867:
-
The problem rely on docValues attribute, for some reason the dvd file becomes
corrupted after several incremental feeding, I'm able to reproduce this
problem and fix it by disabling the docValues attribute docValues=false.
Fields definition:
{code}
{code}
Query:
The query is using &group.field=&group.facet=true and a
simple facet like:
{code}
&facet.field={!key=FacetKey_12345678%20facet.prefix=12345678}fieldForFacet
{code}
The following image, shows Solr reading the index file of type dvd
(Per-Document Values .dvd, .dvm - Encodes additional scoring factors or other
per-document information.
https://lucene.apache.org/core/5_2_0/core/org/apache/lucene/codecs/lucene50/Lucene50DocValuesFormat.html),
enabled by the docValues=true.
(https://cwiki.apache.org/confluence/display/solr/DocValues)
!ErrorReadingDocValues.PNG!
Then trying to read the facet.prefix value from this dvd file, there is an
attempt to read more than the current buffer size causing this issue:
!DocValuesException.PNG!
I hope it helps!
> implicit sharded, facet grouping problem with multivalued string field
> starting with digits
> ---
>
> Key: SOLR-7867
> URL: https://issues.apache.org/jira/browse/SOLR-7867
> Project: Solr
> Issue Type: Bug
> Components: faceting, SolrCloud
>Affects Versions: 5.2
> Environment: 3.13.0-48-generic #80-Ubuntu SMP x86_64 GNU/Linux
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
>Reporter: Umut Erogul
> Labels: docValues, facet, group, sharding
> Attachments: DocValuesException.PNG, ErrorReadingDocValues.PNG
>
>
> related parts @ schema.xml:
> {code} docValues="true" multiValued="true"/>
> docValues="true"/>{code}
> every document has valid author_s and keyword_ss fields;
> we can make successful facet group queries on single node, single collection,
> solr-4.9.0 server
> {code}
> q: *:* fq: keyword_ss:3m
> facet=true&facet.field=keyword_ss&group=true&group.field=author_s&group.facet=true
> {code}
> when querying on solr-5.2.0 server with implicit sharded environment with:
> {code}
> required="true"/>{code}
> with example shard names; affinity1 affinity2 affinity3 affinity4
> the same query with same documents gets:
> {code}
> ERROR - 2015-08-04 08:15:15.222; [document affinity3 core_node32
> document_affinity3_replica2] org.apache.solr.common.SolrException;
> org.apache.solr.common.SolrException: Exception during facet.field: keyword_ss
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:632)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:617)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:571)
> at
> org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:642)
> ...
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.lucene.codecs.lucene50.Lucene50DocValuesProducer$CompressedBinaryDocValues$CompressedBinaryTermsEnum.readTerm(Lucene50DocValuesProducer.java:1008)
> at
> org.apache.lucene.codecs.lucene50.Lucene50DocValuesProducer$CompressedBinaryDocValues$CompressedBinaryTermsEnum.next(Lucene50DocValuesProducer.java:1026)
> at
> org.apache.lucene.search.grouping.term.TermGroupFacetCollector$MV$SegmentResult.nextTerm(TermGroupFacetCollector.java:373)
> at
> org.apache.lucene.search.grouping.AbstractGroupFacetCollector.mergeSegmentResults(AbstractGroupFacetCollector.java:91)
> at
> org.apache.solr.request.SimpleFacets.getGroupedCounts(SimpleFacets.java:541)
> at
> org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:463)
> at
> org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:386)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:626)
> ... 33 more
> {code}
> all the problematic queries are caused by strings starting with digits;
> ("3m", "8 saniye", "2 broke girls", "1v1y")
> there are some strings that the query works like ("24", "90+", "45 dakika")
> we do not observe the problem when querying with
> -keyword_ss:(0-9)*
> updating the problematic documents (a small subset of keyword_ss:(0-9)*),
> fixes the query,
> but we cannot find an easy solution to find the problematic
[jira] [Commented] (SOLR-5398) Global properties in new-style solr.xml doesn´t work anymore
[ https://issues.apache.org/jira/browse/SOLR-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659215#comment-14659215 ] Erick Erickson commented on SOLR-5398: -- Care to contribute a patch? > Global properties in new-style solr.xml doesn´t work anymore > - > > Key: SOLR-5398 > URL: https://issues.apache.org/jira/browse/SOLR-5398 > Project: Solr > Issue Type: Bug > Components: multicore >Affects Versions: 4.5 >Reporter: Sergio Garcia Maroto > > It is not possible to define global properties in Solr.xml as follow anymore. > > > > As result you have to copy properies in each core.properties file. > If you have many cores you have to copy many times repeated properties. > Don´t you think this is something should stay in new Solr versions? > Link > http://lucene.472066.n3.nabble.com/Global-User-defined-properties-solr-xml-from-Solr-4-4-to-Solr-4-5-td4097740.html > Regards, > Sergio -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7867) implicit sharded, facet grouping problem with multivalued string field starting with digits
[
https://issues.apache.org/jira/browse/SOLR-7867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Gonzalez updated SOLR-7867:
Attachment: DocValuesException.PNG
ErrorReadingDocValues.PNG
> implicit sharded, facet grouping problem with multivalued string field
> starting with digits
> ---
>
> Key: SOLR-7867
> URL: https://issues.apache.org/jira/browse/SOLR-7867
> Project: Solr
> Issue Type: Bug
> Components: faceting, SolrCloud
>Affects Versions: 5.2
> Environment: 3.13.0-48-generic #80-Ubuntu SMP x86_64 GNU/Linux
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
>Reporter: Umut Erogul
> Labels: docValues, facet, group, sharding
> Attachments: DocValuesException.PNG, ErrorReadingDocValues.PNG
>
>
> related parts @ schema.xml:
> {code} docValues="true" multiValued="true"/>
> docValues="true"/>{code}
> every document has valid author_s and keyword_ss fields;
> we can make successful facet group queries on single node, single collection,
> solr-4.9.0 server
> {code}
> q: *:* fq: keyword_ss:3m
> facet=true&facet.field=keyword_ss&group=true&group.field=author_s&group.facet=true
> {code}
> when querying on solr-5.2.0 server with implicit sharded environment with:
> {code}
> required="true"/>{code}
> with example shard names; affinity1 affinity2 affinity3 affinity4
> the same query with same documents gets:
> {code}
> ERROR - 2015-08-04 08:15:15.222; [document affinity3 core_node32
> document_affinity3_replica2] org.apache.solr.common.SolrException;
> org.apache.solr.common.SolrException: Exception during facet.field: keyword_ss
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:632)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:617)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:571)
> at
> org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:642)
> ...
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.lucene.codecs.lucene50.Lucene50DocValuesProducer$CompressedBinaryDocValues$CompressedBinaryTermsEnum.readTerm(Lucene50DocValuesProducer.java:1008)
> at
> org.apache.lucene.codecs.lucene50.Lucene50DocValuesProducer$CompressedBinaryDocValues$CompressedBinaryTermsEnum.next(Lucene50DocValuesProducer.java:1026)
> at
> org.apache.lucene.search.grouping.term.TermGroupFacetCollector$MV$SegmentResult.nextTerm(TermGroupFacetCollector.java:373)
> at
> org.apache.lucene.search.grouping.AbstractGroupFacetCollector.mergeSegmentResults(AbstractGroupFacetCollector.java:91)
> at
> org.apache.solr.request.SimpleFacets.getGroupedCounts(SimpleFacets.java:541)
> at
> org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:463)
> at
> org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:386)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:626)
> ... 33 more
> {code}
> all the problematic queries are caused by strings starting with digits;
> ("3m", "8 saniye", "2 broke girls", "1v1y")
> there are some strings that the query works like ("24", "90+", "45 dakika")
> we do not observe the problem when querying with
> -keyword_ss:(0-9)*
> updating the problematic documents (a small subset of keyword_ss:(0-9)*),
> fixes the query,
> but we cannot find an easy solution to find the problematic documents
> there is around 400m docs; seperated at 28 shards;
> -keyword_ss:(0-9)* matches %97 of documents
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5398) Global properties in new-style solr.xml doesn´t work anymore
[ https://issues.apache.org/jira/browse/SOLR-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659160#comment-14659160 ] Brad commented on SOLR-5398: Could you please fix this. I can't believe you dropped this. I have 12 cores and kept my sql connection information in one place so UPGRADING was easier. This just made upgrading a lot more annoying. 12 cores * 4 environments * 2 (every server has a backup) I used to only have to update 8. > Global properties in new-style solr.xml doesn´t work anymore > - > > Key: SOLR-5398 > URL: https://issues.apache.org/jira/browse/SOLR-5398 > Project: Solr > Issue Type: Bug > Components: multicore >Affects Versions: 4.5 >Reporter: Sergio Garcia Maroto > > It is not possible to define global properties in Solr.xml as follow anymore. > > > > As result you have to copy properies in each core.properties file. > If you have many cores you have to copy many times repeated properties. > Don´t you think this is something should stay in new Solr versions? > Link > http://lucene.472066.n3.nabble.com/Global-User-defined-properties-solr-xml-from-Solr-4-4-to-Solr-4-5-td4097740.html > Regards, > Sergio -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7880) Update commons-cli to 1.3.1, fix usage of deprecated classes/methods
[ https://issues.apache.org/jira/browse/SOLR-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-7880: --- Fix Version/s: 5.4 > Update commons-cli to 1.3.1, fix usage of deprecated classes/methods > > > Key: SOLR-7880 > URL: https://issues.apache.org/jira/browse/SOLR-7880 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Affects Versions: 5.2.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey > Fix For: 5.4 > > Attachments: SOLR-7880.patch > > > While looking at SOLR-7847, I noticed that commons-cli was an old version, > and once I upgraded it in the ivy config, found that SolrCLI is using > deprecated classes/methods. > This issue is to complete the upgrade and fix the deprecations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7880) Update commons-cli to 1.3.1, fix usage of deprecated classes/methods
[ https://issues.apache.org/jira/browse/SOLR-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659138#comment-14659138 ] Shawn Heisey commented on SOLR-7880: As recommended by [~thelabdude], I will do more testing (especially on Windows) and make sure that I haven't missed any other usages of the commons-cli package. I don't know if it matters, but when I ran the tests that passed, I did so on Windows. I did the precommit on Linux, though -- I don't have all the prerequisites for that build target on my Windows machine. > Update commons-cli to 1.3.1, fix usage of deprecated classes/methods > > > Key: SOLR-7880 > URL: https://issues.apache.org/jira/browse/SOLR-7880 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Affects Versions: 5.2.1 >Reporter: Shawn Heisey > Attachments: SOLR-7880.patch > > > While looking at SOLR-7847, I noticed that commons-cli was an old version, > and once I upgraded it in the ivy config, found that SolrCLI is using > deprecated classes/methods. > This issue is to complete the upgrade and fix the deprecations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-7880) Update commons-cli to 1.3.1, fix usage of deprecated classes/methods
[ https://issues.apache.org/jira/browse/SOLR-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey reassigned SOLR-7880: -- Assignee: Shawn Heisey > Update commons-cli to 1.3.1, fix usage of deprecated classes/methods > > > Key: SOLR-7880 > URL: https://issues.apache.org/jira/browse/SOLR-7880 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Affects Versions: 5.2.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey > Attachments: SOLR-7880.patch > > > While looking at SOLR-7847, I noticed that commons-cli was an old version, > and once I upgraded it in the ivy config, found that SolrCLI is using > deprecated classes/methods. > This issue is to complete the upgrade and fix the deprecations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7880) Update commons-cli to 1.3.1, fix usage of deprecated classes/methods
[ https://issues.apache.org/jira/browse/SOLR-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-7880: --- Attachment: SOLR-7880.patch This is the same patch that can be found on SOLR-7847 with this filename: SOLR-7847-upgrade-commons-cli.patch > Update commons-cli to 1.3.1, fix usage of deprecated classes/methods > > > Key: SOLR-7880 > URL: https://issues.apache.org/jira/browse/SOLR-7880 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Affects Versions: 5.2.1 >Reporter: Shawn Heisey > Attachments: SOLR-7880.patch > > > While looking at SOLR-7847, I noticed that commons-cli was an old version, > and once I upgraded it in the ivy config, found that SolrCLI is using > deprecated classes/methods. > This issue is to complete the upgrade and fix the deprecations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7880) Update commons-cli to 1.3.1, fix usage of deprecated classes/methods
[ https://issues.apache.org/jira/browse/SOLR-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-7880: --- Summary: Update commons-cli to 1.3.1, fix usage of deprecated classes/methods (was: Update commons-cli, fix usage of deprecated classes/methods) > Update commons-cli to 1.3.1, fix usage of deprecated classes/methods > > > Key: SOLR-7880 > URL: https://issues.apache.org/jira/browse/SOLR-7880 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Affects Versions: 5.2.1 >Reporter: Shawn Heisey > > While looking at SOLR-7847, I noticed that commons-cli was an old version, > and once I upgraded it in the ivy config, found that SolrCLI is using > deprecated classes/methods. > This issue is to complete the upgrade and fix the deprecations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6719) NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior when no docs have value - throw NPE
[ https://issues.apache.org/jira/browse/LUCENE-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659127#comment-14659127 ] Michael McCandless commented on LUCENE-6719: +1, thanks [~thelabdude] > NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior > when no docs have value - throw NPE > --- > > Key: LUCENE-6719 > URL: https://issues.apache.org/jira/browse/LUCENE-6719 > Project: Lucene - Core > Issue Type: Bug >Reporter: Hoss Man > Attachments: LUCENE-6719.patch, LUCENE-6719.patch, LUCENE-6719.patch > > > Tracked down a possible cause of SOLR-7866 to situations where a (numeric) > field doesn't have any values in an index and you try to get the min/max. > javadocs for NumericUtils.getMinLong and NumericUtils.getMaxLong don't > actually say what that method will do in this case, throw NPE when it happens -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7880) Update commons-cli, fix usage of deprecated classes/methods
Shawn Heisey created SOLR-7880: -- Summary: Update commons-cli, fix usage of deprecated classes/methods Key: SOLR-7880 URL: https://issues.apache.org/jira/browse/SOLR-7880 Project: Solr Issue Type: Improvement Components: scripts and tools Affects Versions: 5.2.1 Reporter: Shawn Heisey While looking at SOLR-7847, I noticed that commons-cli was an old version, and once I upgraded it in the ivy config, found that SolrCLI is using deprecated classes/methods. This issue is to complete the upgrade and fix the deprecations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60-ea-b24) - Build # 13745 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13745/ Java: 32bit/jdk1.8.0_60-ea-b24 -client -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([F8CF4A5C6C92680B:5F8BF2F801297BB2]:0) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.collectInfo(BaseCdcrDistributedZkTest.java:748) at org.apache.solr.cloud.CdcrReplicationHandlerTest.assertUpdateLogsEquals(CdcrReplicationHandlerTest.java:213) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplicationAfterPeerSync(CdcrReplicationHandlerTest.java:198) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:53) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(
[jira] [Updated] (LUCENE-6719) NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior when no docs have value - throw NPE
[ https://issues.apache.org/jira/browse/LUCENE-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter updated LUCENE-6719: --- Attachment: LUCENE-6719.patch Hossman is OOO ... so I'm taking this up as I'd like to get SOLR-7866 into 5.3. > NumericUtils.getMinLong and NumericUtils.getMaxLong have undefined behavior > when no docs have value - throw NPE > --- > > Key: LUCENE-6719 > URL: https://issues.apache.org/jira/browse/LUCENE-6719 > Project: Lucene - Core > Issue Type: Bug >Reporter: Hoss Man > Attachments: LUCENE-6719.patch, LUCENE-6719.patch, LUCENE-6719.patch > > > Tracked down a possible cause of SOLR-7866 to situations where a (numeric) > field doesn't have any values in an index and you try to get the min/max. > javadocs for NumericUtils.getMinLong and NumericUtils.getMaxLong don't > actually say what that method will do in this case, throw NPE when it happens -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7847) Implement the logic that runs examples in Java instead of in OS specific scripts (bin/solr and bin/solr.cmd)
[
https://issues.apache.org/jira/browse/SOLR-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659101#comment-14659101
]
Timothy Potter commented on SOLR-7847:
--
Also, I recommend handling these changes in a separate issue that can be
tracked as Jenkins is now passing with the code as committed. Moreover, {{ant
nightly-smoke}} test should also be run against trunk and branch_5x before
committing as that is affected by this code.
> Implement the logic that runs examples in Java instead of in OS specific
> scripts (bin/solr and bin/solr.cmd)
>
>
> Key: SOLR-7847
> URL: https://issues.apache.org/jira/browse/SOLR-7847
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7847-upgrade-commons-cli.patch, SOLR-7847.patch,
> SOLR-7847.patch, SOLR-7847_fixtest.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Off-shoot from SOLR-7043 to tackle the specific task of moving the logic that
> runs the examples (cloud, techproducts, etc) to Java code instead of complex
> OS-specific scripts.
> This is only one small step along the way to get SOLR-7043 resolved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7847) Implement the logic that runs examples in Java instead of in OS specific scripts (bin/solr and bin/solr.cmd)
[ https://issues.apache.org/jira/browse/SOLR-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659085#comment-14659085 ] Timothy Potter commented on SOLR-7847: -- Be sure to test the cli changes on Windows manually ... the code I committed for this was tested pretty thoroughly on Windows and while it shouldn't matter because it's just Java, I've seen that it does sometimes with that OS ;-) > Implement the logic that runs examples in Java instead of in OS specific > scripts (bin/solr and bin/solr.cmd) > > > Key: SOLR-7847 > URL: https://issues.apache.org/jira/browse/SOLR-7847 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Reporter: Timothy Potter >Assignee: Timothy Potter > Fix For: 5.3, Trunk > > Attachments: SOLR-7847-upgrade-commons-cli.patch, SOLR-7847.patch, > SOLR-7847.patch, SOLR-7847_fixtest.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > Off-shoot from SOLR-7043 to tackle the specific task of moving the logic that > runs the examples (cloud, techproducts, etc) to Java code instead of complex > OS-specific scripts. > This is only one small step along the way to get SOLR-7043 resolved. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7879) Null pointer exception when
[ https://issues.apache.org/jira/browse/SOLR-7879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659052#comment-14659052 ] Yonik Seeley commented on SOLR-7879: Looking at the code, it looks like maybe this could happen if you specify something like "sort x desc" when "x" isn't defined? > Null pointer exception when > > > Key: SOLR-7879 > URL: https://issues.apache.org/jira/browse/SOLR-7879 > Project: Solr > Issue Type: Bug > Components: Facet Module, search >Affects Versions: 5.2.1 > Environment: Oracle jdk1.8 >Reporter: Gary Yang > Labels: faceting, jsonapi, subfacet > > This can be reproduce by certain inputs, but I can't find a pattern in the > inputs that cause this error: > Caused by: > org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error > from server at http://192.168.1.47:8983/solr/core1: > java.lang.NullPointerException > at > org.apache.solr.search.facet.FacetFieldProcessorFCBase.findTopSlots(FacetField.java:301) > at > org.apache.solr.search.facet.FacetFieldProcessorFCBase.getFieldCacheCounts(FacetField.java:254) > at > org.apache.solr.search.facet.FacetFieldProcessorFCBase.process(FacetField.java:218) > at > org.apache.solr.search.facet.FacetProcessor.processSubs(FacetRequest.java:267) > at > org.apache.solr.search.facet.FacetFieldProcessorNumeric.calcFacets(FacetFieldProcessorNumeric.java:472) > at > org.apache.solr.search.facet.FacetFieldProcessorNumeric.process(FacetFieldProcessorNumeric.java:151) > at > org.apache.solr.search.facet.FacetProcessor.processSubs(FacetRequest.java:267) > at > org.apache.solr.search.facet.FacetProcessor.fillBucket(FacetRequest.java:354) > at > org.apache.solr.search.facet.FacetQueryProcessor.process(FacetQuery.java:57) > at org.apache.solr.search.facet.FacetModule.process(FacetModule.java:87) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > at org.eclipse.jetty.server.Server.handle(Server.java:497) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) > at > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 920 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/920/ 2 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: KeeperErrorCode = Session expired for /live_nodes Stack Trace: org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = Session expired for /live_nodes at org.apache.zookeeper.KeeperException.create(KeeperException.java:127) at org.apache.zookeeper.KeeperException.create(KeeperException.java:51) at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1472) at org.apache.solr.common.cloud.SolrZkClient$6.execute(SolrZkClient.java:328) at org.apache.solr.common.cloud.SolrZkClient$6.execute(SolrZkClient.java:325) at org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:61) at org.apache.solr.common.cloud.SolrZkClient.getChildren(SolrZkClient.java:325) at org.apache.solr.common.cloud.ZkStateReader.updateClusterState(ZkStateReader.java:487) at org.apache.solr.common.cloud.ZkStateReader.updateClusterState(ZkStateReader.java:225) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testNoCollectionSpecified(CollectionsAPIDistributedZkTest.java:464) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:169) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ru
Re: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60)
Locally changed createRandomIndex to add not the 1 but 2 documents before the forceMerge. Still ends up with an unsorted segment: SortingMergePolicy.java:197 isSorted(reader=FilterLeafReader(Uninverting(_24(6.0.0):C2)), sort=)=false Will investigate more tomorrow/Thursday. - Original Message - From: dev@lucene.apache.org To: dev@lucene.apache.org At: Aug 5 2015 22:04:20 Seeing this when adding trace locally: SortingMergePolicy.java:197 isSorted(reader=FilterLeafReader(Uninverting(_24(6.0.0):C1)), sort=)=false So the segment really is not sorted, but actually couldn't we consider all segments that contain just 1 document (and 0 deletes) to be sorted by *any* criteria? - Original Message - From: dev@lucene.apache.org To: dev@lucene.apache.org At: Aug 5 2015 21:32:49 This seed reproduces 100% (3/3 trials) for me on OS X, Java8. [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestEarlyTerminatingSortingCollector -Dtests.method=testTerminatedEarly -Dtests.seed=A2457E720C1058BA -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=et -Dtests.timezone=Africa/Monrovia -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 > On Aug 5, 2015, at 4:08 PM, Policeman Jenkins Server > wrote: > > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13744/ > Java: 64bit/jdk1.9.0-ea-b60 -XX:+UseCompressedOops -XX:+UseG1GC > -Djava.locale.providers=JRE,SPI > > 1 tests failed. > FAILED: > org.apache.lucene.search.TestEarlyTerminatingSortingCollector.testTerminatedEarly > > Error Message: > should have terminated early > (searcher.reader=ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_24(6.0.0):C1 > > Stack Trace: > java.lang.AssertionError: should have terminated early > (searcher.reader=ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_24(6.0.0):C1 > at > __randomizedtesting.SeedInfo.seed([A2457E720C1058BA:83DEC4C0AD2A163D]:0) > at org.junit.Assert.fail(Assert.java:93) > at org.junit.Assert.assertTrue(Assert.java:43) > at > org.apache.lucene.search.TestEarlyTerminatingSortingCollector.testTerminatedEarly(TestEarlyTerminatingSortingCollector.java:298) > 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:502) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) > at > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) > at > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) > at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) >
[jira] [Commented] (LUCENE-6722) Java 8 as the minimum supported JVM version for branch_5x
[ https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658988#comment-14658988 ] Shawn Heisey commented on LUCENE-6722: -- bq. The hardships we face while merging changes from trunk to branch_5x is a PITA. I have occasionally run into things that had to be manually backported, but for the most part, when I merge a commit from trunk to the stable branch, it works without incident. I am not personally seeing a problem that's large enough to warrant the Java upgrade. Even if both branches use the same Java version, there will still be discrepancies that will complicate backporting. That's just how things are when there's a trunk/master in addition to a stable branch. I'm really curious how often people run into merge conflicts, and what percentage of those problems are due to differences related to the Java version as opposed to other code changes. > Java 8 as the minimum supported JVM version for branch_5x > - > > Key: LUCENE-6722 > URL: https://issues.apache.org/jira/browse/LUCENE-6722 > Project: Lucene - Core > Issue Type: Wish >Reporter: Shalin Shekhar Mangar >Priority: Blocker > Fix For: 5.4 > > > Require Java 8 as the minimum supported JVM version for branch_5x. > # Java 7 is already EOL'ed > # Trunk is already at Java8 > # Important Solr components such as Jetty 9.3.x already require Java 8 > # Nashorn Javascript engine available in Java 8 is just so much faster and we > may see more usage of JS inside Solr (SOLR-7576 etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7877) TestAuthenticationFramework.testBasics to preserve/restore the original request(Username|Password)
[
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658973#comment-14658973
]
ASF subversion and git services commented on SOLR-7877:
---
Commit 1694333 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694333 ]
SOLR-7877: TestAuthenticationFramework.testBasics to preserve/restore the
original request(Username|Password) - svn r1694322 missed out the svn:mergeinfo
for branch_5x itself, oops, sorry.
> TestAuthenticationFramework.testBasics to preserve/restore the original
> request(Username|Password)
> --
>
> Key: SOLR-7877
> URL: https://issues.apache.org/jira/browse/SOLR-7877
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3, Trunk
>Reporter: Noble Paul
>Assignee: Christine Poerschke
>Priority: Blocker
>
> {code}
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
> Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
> 1 tests failed.
> FAILED:
> org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
> Error Message:
> Error from server at http://127.0.0.1:51573/solr: Expected mime type
> application/octet-stream but got text/html.http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
> Error 401HTTP ERROR: 401 Problem
> accessing /solr/admin/collections. Reason: Unauthorized
> request Powered by Jetty://
>
> Stack Trace:
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://127.0.0.1:51573/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401
>
>
> HTTP ERROR: 401
> Problem accessing /solr/admin/collections. Reason:
> Unauthorized request
> Powered by Jetty://
>
>
> at
> __randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
> at
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
> at
> org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
> at
> org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60)
On Wed, Aug 5, 2015 at 11:04 PM, Christine Poerschke (BLOOMBERG/ LONDON) wrote: > So the segment really is not sorted, but actually couldn't we consider all > segments that contain just 1 document (and 0 deletes) to be sorted by *any* > criteria? We could, but I don't think we should add a branch for this particular case: it has no practical benefit and would be rarely tested? -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60)
Seeing this when adding trace locally: SortingMergePolicy.java:197 isSorted(reader=FilterLeafReader(Uninverting(_24(6.0.0):C1)), sort=)=false So the segment really is not sorted, but actually couldn't we consider all segments that contain just 1 document (and 0 deletes) to be sorted by *any* criteria? - Original Message - From: dev@lucene.apache.org To: dev@lucene.apache.org At: Aug 5 2015 21:32:49 This seed reproduces 100% (3/3 trials) for me on OS X, Java8. [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestEarlyTerminatingSortingCollector -Dtests.method=testTerminatedEarly -Dtests.seed=A2457E720C1058BA -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=et -Dtests.timezone=Africa/Monrovia -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 > On Aug 5, 2015, at 4:08 PM, Policeman Jenkins Server > wrote: > > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13744/ > Java: 64bit/jdk1.9.0-ea-b60 -XX:+UseCompressedOops -XX:+UseG1GC > -Djava.locale.providers=JRE,SPI > > 1 tests failed. > FAILED: > org.apache.lucene.search.TestEarlyTerminatingSortingCollector.testTerminatedEarly > > Error Message: > should have terminated early > (searcher.reader=ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_24(6.0.0):C1 > > Stack Trace: > java.lang.AssertionError: should have terminated early > (searcher.reader=ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_24(6.0.0):C1 > at > __randomizedtesting.SeedInfo.seed([A2457E720C1058BA:83DEC4C0AD2A163D]:0) > at org.junit.Assert.fail(Assert.java:93) > at org.junit.Assert.assertTrue(Assert.java:43) > at > org.apache.lucene.search.TestEarlyTerminatingSortingCollector.testTerminatedEarly(TestEarlyTerminatingSortingCollector.java:298) > 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:502) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) > at > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) > at > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) > at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) > 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:54) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(Test
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_51) - Build # 5111 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5111/ Java: 64bit/jdk1.8.0_51 -XX:+UseCompressedOops -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.lucene.store.TestNativeFSLockFactory.testStressLocks Error Message: Captured an uncaught exception in thread: Thread[id=1446, name=Thread-987, state=RUNNABLE, group=TGRP-TestNativeFSLockFactory] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=1446, name=Thread-987, state=RUNNABLE, group=TGRP-TestNativeFSLockFactory] at __randomizedtesting.SeedInfo.seed([6CAE129E8CE6E8DD:329F5C63904A20BB]:0) Caused by: java.lang.AssertionError: hit unexpected NoSuchFileException: file=segments_5 at __randomizedtesting.SeedInfo.seed([6CAE129E8CE6E8DD]:0) at org.apache.lucene.index.IndexFileDeleter.deleteFile(IndexFileDeleter.java:750) at org.apache.lucene.index.IndexFileDeleter.deletePendingFiles(IndexFileDeleter.java:515) at org.apache.lucene.index.IndexFileDeleter.decRef(IndexFileDeleter.java:636) at org.apache.lucene.index.IndexFileDeleter.close(IndexFileDeleter.java:470) at org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2080) at org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1067) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1109) at org.apache.lucene.store.BaseLockFactoryTestCase$WriterThread.run(BaseLockFactoryTestCase.java:221) FAILED: org.apache.lucene.store.TestSimpleFSLockFactory.testStressLocks Error Message: IndexWriter hit unexpected exceptions Stack Trace: java.lang.AssertionError: IndexWriter hit unexpected exceptions at __randomizedtesting.SeedInfo.seed([6CAE129E8CE6E8DD:329F5C63904A20BB]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.lucene.store.BaseLockFactoryTestCase.testStressLocks(BaseLockFactoryTestCase.java:169) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rule
[jira] [Commented] (SOLR-7877) TestAuthenticationFramework.testBasics to preserve/restore the original request(Username|Password)
[
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658879#comment-14658879
]
ASF subversion and git services commented on SOLR-7877:
---
Commit 1694322 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694322 ]
SOLR-7877: TestAuthenticationFramework.testBasics to preserve/restore the
original request(Username|Password)
> TestAuthenticationFramework.testBasics to preserve/restore the original
> request(Username|Password)
> --
>
> Key: SOLR-7877
> URL: https://issues.apache.org/jira/browse/SOLR-7877
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3, Trunk
>Reporter: Noble Paul
>Assignee: Christine Poerschke
>Priority: Blocker
>
> {code}
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
> Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
> 1 tests failed.
> FAILED:
> org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
> Error Message:
> Error from server at http://127.0.0.1:51573/solr: Expected mime type
> application/octet-stream but got text/html.http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
> Error 401HTTP ERROR: 401 Problem
> accessing /solr/admin/collections. Reason: Unauthorized
> request Powered by Jetty://
>
> Stack Trace:
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://127.0.0.1:51573/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401
>
>
> HTTP ERROR: 401
> Problem accessing /solr/admin/collections. Reason:
> Unauthorized request
> Powered by Jetty://
>
>
> at
> __randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
> at
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
> at
> org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
> at
> org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13744 - Still Failing!
This seed reproduces 100% (3/3 trials) for me on OS X, Java8. [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestEarlyTerminatingSortingCollector -Dtests.method=testTerminatedEarly -Dtests.seed=A2457E720C1058BA -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=et -Dtests.timezone=Africa/Monrovia -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 > On Aug 5, 2015, at 4:08 PM, Policeman Jenkins Server > wrote: > > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13744/ > Java: 64bit/jdk1.9.0-ea-b60 -XX:+UseCompressedOops -XX:+UseG1GC > -Djava.locale.providers=JRE,SPI > > 1 tests failed. > FAILED: > org.apache.lucene.search.TestEarlyTerminatingSortingCollector.testTerminatedEarly > > Error Message: > should have terminated early > (searcher.reader=ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_24(6.0.0):C1 > > Stack Trace: > java.lang.AssertionError: should have terminated early > (searcher.reader=ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_24(6.0.0):C1 > at > __randomizedtesting.SeedInfo.seed([A2457E720C1058BA:83DEC4C0AD2A163D]:0) > at org.junit.Assert.fail(Assert.java:93) > at org.junit.Assert.assertTrue(Assert.java:43) > at > org.apache.lucene.search.TestEarlyTerminatingSortingCollector.testTerminatedEarly(TestEarlyTerminatingSortingCollector.java:298) > 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:502) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) > at > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) > at > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) > at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) > 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:54) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) > at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) > at > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter
[jira] [Commented] (LUCENE-6722) Java 8 as the minimum supported JVM version for branch_5x
[ https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658839#comment-14658839 ] Joel Bernstein commented on LUCENE-6722: +1 Responded to list on this but I'll add my two cents here as well. I was almost boxed in the SQL interface because the SQL parser I chose first (Presto) relied on Java 8. Turns out there is a solid Java 7 alternative (Calcite), otherwise I would have been stuck. But I've had to spend time working around this issue that could have been spent elsewhere. > Java 8 as the minimum supported JVM version for branch_5x > - > > Key: LUCENE-6722 > URL: https://issues.apache.org/jira/browse/LUCENE-6722 > Project: Lucene - Core > Issue Type: Wish >Reporter: Shalin Shekhar Mangar >Priority: Blocker > Fix For: 5.4 > > > Require Java 8 as the minimum supported JVM version for branch_5x. > # Java 7 is already EOL'ed > # Trunk is already at Java8 > # Important Solr components such as Jetty 9.3.x already require Java 8 > # Nashorn Javascript engine available in Java 8 is just so much faster and we > may see more usage of JS inside Solr (SOLR-7576 etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6722) Java 8 as the minimum supported JVM version for branch_5x
[ https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658831#comment-14658831 ] Dawid Weiss commented on LUCENE-6722: - bq. At least to make the life of developers easy , we must do it This leads us to an interesting question -- is software for users or for developers? :) > Java 8 as the minimum supported JVM version for branch_5x > - > > Key: LUCENE-6722 > URL: https://issues.apache.org/jira/browse/LUCENE-6722 > Project: Lucene - Core > Issue Type: Wish >Reporter: Shalin Shekhar Mangar >Priority: Blocker > Fix For: 5.4 > > > Require Java 8 as the minimum supported JVM version for branch_5x. > # Java 7 is already EOL'ed > # Trunk is already at Java8 > # Important Solr components such as Jetty 9.3.x already require Java 8 > # Nashorn Javascript engine available in Java 8 is just so much faster and we > may see more usage of JS inside Solr (SOLR-7576 etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5872) Eliminate overseer queue
[ https://issues.apache.org/jira/browse/SOLR-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658807#comment-14658807 ] Scott Blum commented on SOLR-5872: -- Now that SOLR-5756 is close to landed, I want to take a serious stab at making updates to format2 collections not go through overseer. IE, anything that modifies clusterstate.json goes through overseer, but anything that modifies a /collection/foo/state.json would be handled by the local node with a CAS loop. I realize that for a collection with a huge number of shards+replicas, there could be contention on that single node. Worth nothing that the current implementation doesn't batch format2 updates anyway, it ends up doing a (non-contended) write for every individual mutation. > Eliminate overseer queue > - > > Key: SOLR-5872 > URL: https://issues.apache.org/jira/browse/SOLR-5872 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Noble Paul >Assignee: Noble Paul > > The overseer queue is one of the busiest points in the entire system. The > raison d'être of the queue is > * Provide batching of operations for the main clusterstate,json so that > state updates are minimized > * Avoid race conditions and ensure order > Now , as we move the individual collection states out of the main > clusterstate.json, the batching is not useful anymore. > Race conditions can easily be solved by using a compare and set in Zookeeper. > The proposed solution is , whenever an operation is required to be performed > on the clusterstate, the same thread (and of course the same JVM) > # read the fresh state and version of zk node > # construct the new state > # perform a compare and set > # if compare and set fails go to step 1 > This should be limited to all operations performed on external collections > because batching would be required for others -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13744 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13744/ Java: 64bit/jdk1.9.0-ea-b60 -XX:+UseCompressedOops -XX:+UseG1GC -Djava.locale.providers=JRE,SPI 1 tests failed. FAILED: org.apache.lucene.search.TestEarlyTerminatingSortingCollector.testTerminatedEarly Error Message: should have terminated early (searcher.reader=ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_24(6.0.0):C1 Stack Trace: java.lang.AssertionError: should have terminated early (searcher.reader=ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_24(6.0.0):C1 at __randomizedtesting.SeedInfo.seed([A2457E720C1058BA:83DEC4C0AD2A163D]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.lucene.search.TestEarlyTerminatingSortingCollector.testTerminatedEarly(TestEarlyTerminatingSortingCollector.java:298) 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:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 7316 lines...] [junit4] Suite: org.apache.lucene.search.TestEarlyTerminatingSortingCollector [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestEarlyTerminatingSortingCollector -Dtests.method=testTerminatedEarly -Dtests.seed=A2457E720C1058BA -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=et -Dtests.timezone=Africa
[jira] [Updated] (SOLR-7877) TestAuthenticationFramework.testBasics to preserve/restore the original request(Username|Password)
[
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-7877:
--
Summary: TestAuthenticationFramework.testBasics to preserve/restore the
original request(Username|Password) (was: TestAuthenticationFramework test
failures)
> TestAuthenticationFramework.testBasics to preserve/restore the original
> request(Username|Password)
> --
>
> Key: SOLR-7877
> URL: https://issues.apache.org/jira/browse/SOLR-7877
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3, Trunk
>Reporter: Noble Paul
>Assignee: Christine Poerschke
>Priority: Blocker
>
> {code}
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
> Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
> 1 tests failed.
> FAILED:
> org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
> Error Message:
> Error from server at http://127.0.0.1:51573/solr: Expected mime type
> application/octet-stream but got text/html.http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
> Error 401HTTP ERROR: 401 Problem
> accessing /solr/admin/collections. Reason: Unauthorized
> request Powered by Jetty://
>
> Stack Trace:
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://127.0.0.1:51573/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401
>
>
> HTTP ERROR: 401
> Problem accessing /solr/admin/collections. Reason:
> Unauthorized request
> Powered by Jetty://
>
>
> at
> __randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
> at
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
> at
> org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
> at
> org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7877) TestAuthenticationFramework test failures
[
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658792#comment-14658792
]
ASF subversion and git services commented on SOLR-7877:
---
Commit 1694314 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1694314 ]
SOLR-7877: TestAuthenticationFramework.testBasics to preserve/restore the
original request(Username|Password)
> TestAuthenticationFramework test failures
> -
>
> Key: SOLR-7877
> URL: https://issues.apache.org/jira/browse/SOLR-7877
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3, Trunk
>Reporter: Noble Paul
>Assignee: Christine Poerschke
>Priority: Blocker
>
> {code}
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
> Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
> 1 tests failed.
> FAILED:
> org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
> Error Message:
> Error from server at http://127.0.0.1:51573/solr: Expected mime type
> application/octet-stream but got text/html.http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
> Error 401HTTP ERROR: 401 Problem
> accessing /solr/admin/collections. Reason: Unauthorized
> request Powered by Jetty://
>
> Stack Trace:
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://127.0.0.1:51573/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401
>
>
> HTTP ERROR: 401
> Problem accessing /solr/admin/collections. Reason:
> Unauthorized request
> Powered by Jetty://
>
>
> at
> __randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
> at
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
> at
> org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
> at
> org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7730) speed-up faceting on doc values fields
[
https://issues.apache.org/jira/browse/SOLR-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658789#comment-14658789
]
Mikhail Khludnev commented on SOLR-7730:
[~ysee...@gmail.com] how much gain did you evidence?
> speed-up faceting on doc values fields
> --
>
> Key: SOLR-7730
> URL: https://issues.apache.org/jira/browse/SOLR-7730
> Project: Solr
> Issue Type: Improvement
> Components: faceting
>Affects Versions: 5.2.1
>Reporter: Mikhail Khludnev
> Labels: patch
> Fix For: 5.3
>
> Attachments: LUCENE-7730.patch, LUCENE-7730.patch, SOLR-7730.patch
>
>
> every time we count facets on DocValues fields in Solr on many segments index
> we see the unnecessary hotspot:
> {code}
>
> at
> org.apache.lucene.index.MultiFields.getMergedFieldInfos(MultiFields.java:248)
> at
> org.apache.lucene.index.SlowCompositeReaderWrapper.getFieldInfos(SlowCompositeReaderWrapper.java:239)
> at
> org.apache.lucene.index.SlowCompositeReaderWrapper.getSortedSetDocValues(SlowCompositeReaderWrapper.java:176)
> at
> org.apache.solr.request.DocValuesFacets.getCounts(DocValuesFacets.java:72)
> at
> org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:460)
> {code}
> the reason is SlowCompositeReaderWrapper.getSortedSetDocValues() Line 136 and
> SlowCompositeReaderWrapper.getSortedDocValues() Line 174
> before return composite doc values, SCWR merges segment field infos, which is
> expensive, but after fieldinfo is merged, it checks *only* docvalue type in
> it. This dv type check can be done much easier in per segment basis.
> This patch gets some performance gain for those who count DV facets in Solr.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6722) Java 8 as the minimum supported JVM version for branch_5x
[ https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658777#comment-14658777 ] Noble Paul commented on LUCENE-6722: The hardships we face while merging changes from trunk to branch_5x is a PITA. Atl east to make the life of developers easy , we must do it > Java 8 as the minimum supported JVM version for branch_5x > - > > Key: LUCENE-6722 > URL: https://issues.apache.org/jira/browse/LUCENE-6722 > Project: Lucene - Core > Issue Type: Wish >Reporter: Shalin Shekhar Mangar >Priority: Blocker > Fix For: 5.4 > > > Require Java 8 as the minimum supported JVM version for branch_5x. > # Java 7 is already EOL'ed > # Trunk is already at Java8 > # Important Solr components such as Jetty 9.3.x already require Java 8 > # Nashorn Javascript engine available in Java 8 is just so much faster and we > may see more usage of JS inside Solr (SOLR-7576 etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7874) two terms in brackets interpreted as range query
[
https://issues.apache.org/jira/browse/SOLR-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-7874.
--
Resolution: Not A Problem
This is working as intended. The need to escape square brackets has been
documented at least since since the 2.9 Lucene days, see:
https://lucene.apache.org/core/2_9_4/queryparsersyntax.html#Escaping Special
Characters.
> two terms in brackets interpreted as range query
>
>
> Key: SOLR-7874
> URL: https://issues.apache.org/jira/browse/SOLR-7874
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 5.2.1
>Reporter: Ryan Steinberg
>
> Queries with two strings between brackets are parsed as range queries even
> when missing the " TO " keyword. This creates performance problems from
> extremely expensive unintended range queries.
> Example: [string1 string2]
> "rawquerystring": "[string1 string2]",
> "querystring": "[string1 string2]",
> "parsedquery": "(+DisjunctionMaxQuery((text:[string1 TO
> string2])))/no_coord",
> "parsedquery_toString": "+(text:[string1 TO string2])",
> "explain": {},
> "QParser": "ExtendedDismaxQParser"
> Same behavior for LuceneQParser:
> "rawquerystring": "[string1 string2]",
> "querystring": "[string1 string2]",
> "parsedquery": "text:[string1 TO string2]",
> "parsedquery_toString": "text:[string1 TO string2]",
> "explain": {},
> "QParser": "LuceneQParser"
> Three strings between brackets is parsed correctly by ExtendedDismaxQParser:
> "rawquerystring": "[string1 string2 string3]",
> "querystring": "[string1 string2 string3]",
> "parsedquery": "(+(DisjunctionMaxQuery((text:string1))
> DisjunctionMaxQuery((text:string2))
> DisjunctionMaxQuery((text:string3/no_coord",
> "parsedquery_toString": "+((text:string1) (text:string2) (text:string3))",
> "explain": {},
> "QParser": "ExtendedDismaxQParser"
> Query examples from live search application (copy and pasted book titles):
> The biology of cancer [electronic resource]
> Prostate cancer principles and practice. [1st ed.]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Possible to avoid hangs in org.apache.solr.handler.admin.SystemInfoHandler
Robert:
Just create a JIRA and submit it. It would be great if there were a
test that illustrated this, but I'm not sure how that would be
written. See: https://wiki.apache.org/solr/HowToContribute for the
general bits on checking out code, creating and attaching patches and
the like.
Note that the naming conventions are SOLR-.patch and we use the
same name for multiple versions.
Best,
Erick
On Wed, Aug 5, 2015 at 2:52 PM, Robert Krüger wrote:
> Just to follow up on this: Replacing getCanonicalHostName() by getHostName()
> would solve the problem AFAICS and e.g. Logback does exactly that for
> exactly the same purpose.
>
> http://logback.qos.ch/xref/ch/qos/logback/core/util/ContextUtil.html
>
> How do I submit a patch? Via this mailing list?
>
> Best regards,
>
> Robert
>
> On Wed, Aug 5, 2015 at 6:57 PM, Robert Krüger wrote:
>>
>>
>> Hi,
>>
>> I am tracking down a problem with huge startup delays of a solr instance
>> and tracked it down to this code in SystemInfoHandler:
>>
>> private void init() {
>> try {
>> InetAddress addr = InetAddress.getLocalHost();
>> hostname = addr.getCanonicalHostName();
>> this is where it hangs
>> } catch (UnknownHostException e) {
>> //default to null
>> }
>> }
>>
>> The setup I have gives me no control over the local network configuration
>> as solr is delivered as part of a larger software that users install on
>> their machines and that has worked really well and it is technically fit for
>> this purpose just as other no-sql stores or rdbmss. However, when our
>> software users have problems like a reverse lookup not working because they
>> work in a VPN environment (which in no other way affects the correct
>> operation of solr) they currently have to wait a minute for solr startup
>> (otherwise about a second) because two timeouts of these lookups happen, one
>> when setting up the container, another for the core and that only to have
>> the "host" info contain a name that was reverse-looked up.
>>
>> Would it be acceptable to submit a patch that allows this to be disabled
>> overidden by a system property be acceptable? I.e. suppress the lookup and
>> just use what can be retrieved about the host without a lookup (e.g. the ip
>> address).
>>
>> Best regards,
>>
>> Robert
>>
>
>
>
> --
> Robert Krüger
> Managing Partner
> Lesspain GmbH & Co. KG
>
> www.lesspain-software.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (LUCENE-6722) Java 8 as the minimum supported JVM version for branch_5x
+1 The Java 8 requirement has delayed the release of the SQL interface because Presto relies on Java 8. I'm mostly finished with replacing Presto with Calcite, which is Java 7 compatible, so it's not going to save me much work at this point. But it would be good to have the freedom of using libraries that rely on Java 8. Joel Bernstein http://joelsolr.blogspot.com/ On Wed, Aug 5, 2015 at 3:38 PM, Erick Erickson (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658739#comment-14658739 > ] > > Erick Erickson commented on LUCENE-6722: > > > bq: Personally, unless we are boxed in a corner, I think this is what > major versions are for. > > So does this really become "relase 6.0"? I think this is premature but > thought I'd ask. > > bq: Yeah, but we have precedence. We upgraded to Java 7 in 4.8.0. > > That was itself an outlier. That said, it's instructive that it seemed to > go pretty smoothly. > > > Java 8 as the minimum supported JVM version for branch_5x > > - > > > > Key: LUCENE-6722 > > URL: https://issues.apache.org/jira/browse/LUCENE-6722 > > Project: Lucene - Core > > Issue Type: Wish > >Reporter: Shalin Shekhar Mangar > >Priority: Blocker > > Fix For: 5.4 > > > > > > Require Java 8 as the minimum supported JVM version for branch_5x. > > # Java 7 is already EOL'ed > > # Trunk is already at Java8 > > # Important Solr components such as Jetty 9.3.x already require Java 8 > > # Nashorn Javascript engine available in Java 8 is just so much faster > and we may see more usage of JS inside Solr (SOLR-7576 etc.) > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Commented] (LUCENE-6722) Java 8 as the minimum supported JVM version for branch_5x
[ https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658739#comment-14658739 ] Erick Erickson commented on LUCENE-6722: bq: Personally, unless we are boxed in a corner, I think this is what major versions are for. So does this really become "relase 6.0"? I think this is premature but thought I'd ask. bq: Yeah, but we have precedence. We upgraded to Java 7 in 4.8.0. That was itself an outlier. That said, it's instructive that it seemed to go pretty smoothly. > Java 8 as the minimum supported JVM version for branch_5x > - > > Key: LUCENE-6722 > URL: https://issues.apache.org/jira/browse/LUCENE-6722 > Project: Lucene - Core > Issue Type: Wish >Reporter: Shalin Shekhar Mangar >Priority: Blocker > Fix For: 5.4 > > > Require Java 8 as the minimum supported JVM version for branch_5x. > # Java 7 is already EOL'ed > # Trunk is already at Java8 > # Important Solr components such as Jetty 9.3.x already require Java 8 > # Nashorn Javascript engine available in Java 8 is just so much faster and we > may see more usage of JS inside Solr (SOLR-7576 etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-5756: - Attachment: SOLR-5756-part2.patch Part 2 of the patch, adds a MIGRATESTATEFORMAT collection command. Bikeshedding on name is welcome. > A utility API to move collections from internal to external > --- > > Key: SOLR-5756 > URL: https://issues.apache.org/jira/browse/SOLR-5756 > Project: Solr > Issue Type: Bug >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar > Attachments: SOLR-5756-part2.patch, SOLR-5756-trunk.patch > > > SOLR-5473 allows creation of collection with state stored outside of > clusterstate.json. We would need an API to move existing 'internal' > collections outside -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-5756: - Attachment: (was: SOLR-5756-vs-5.2.1.patch) > A utility API to move collections from internal to external > --- > > Key: SOLR-5756 > URL: https://issues.apache.org/jira/browse/SOLR-5756 > Project: Solr > Issue Type: Bug >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar > Attachments: SOLR-5756-part2.patch, SOLR-5756-trunk.patch > > > SOLR-5473 allows creation of collection with state stored outside of > clusterstate.json. We would need an API to move existing 'internal' > collections outside -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 5.3 release
Uwe, I don’t think renaming the preexisting 5.2 jobs is ideal, because preexisting release branch jobs can have stale config (inactive jobs’ configs don’t always get updated when other jobs’ configs do). When setting up release branch jobs, I like to instead clone the branch_5x jobs. I’ll delete the 5.2 workspaces via ssh/sudo, thanks for the reminder. Steve www.lucidworks.com > On Aug 5, 2015, at 3:10 PM, Uwe Schindler wrote: > > I added the 5.3 Policeman Job! > > Steve: For ASF Jenkins, it would be ideal to rename the preexisting 5.2 jobs > and simply change the branch in the subversion settings. Before doing that, > be sure to delete the old workspace using the GUI (I am not sure if I did > that already...)!!! This is important, because Jenkins does not delete the > workspace automatically on rename/job delete, so it consumes large amounts of > disk space, which is very limited on the lucene machine. > > Otherwise create the jobs and delete the outdated workspaces afterwards using > SSH / sudo. > > Uwe > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > >> -Original Message- >> From: Steve Rowe [mailto:sar...@gmail.com] >> Sent: Wednesday, August 05, 2015 5:16 PM >> To: Lucene Dev >> Cc: Uwe Schindler; Noble Paul >> Subject: Re: 5.3 release >> >> I can work on setting up 5.3 release branch jobs on ASF Jenkins later today >> if >> Uwe doesn’t beat me to it. - Steve >> >>> On Aug 5, 2015, at 11:09 AM, Noble Paul wrote: >>> >>> I have created the lucene_solr_5_3 branch. >>> If anything new must go into 5.3 release please communicate it here >>> and commit to the new branch as well >>> >>> @uwe, @sarowe , can someone help me setup jenkins for the same. >>> --Noble >>> >>> On Wed, Aug 5, 2015 at 7:27 PM, Varun Thacker >>> wrote: Hi Noble, I've just now committed SOLR-7818 and SOLR-7756. Both were bug fixes. I'm done from my side for 5.3 On Wed, Aug 5, 2015 at 1:22 PM, Noble Paul >> wrote: > > https://issues.apache.org/jira/browse/SOLR-7692 is slated to be a > part of 5.3 . I'm wrapping it up. > As you suggested , it makes sense to cut a branch and stabilize stuff. > I shall cut a branch as soon as possible > > I guess there could be other things too. > --Noble > > On Tue, Aug 4, 2015 at 6:55 PM, Adrien Grand >> wrote: >> Hi Noble, >> >> Which changes are delaying the branch creation? Even if everything >> that we want for 5.3 is not ready yet, it could be useful to create >> the branch now to help stabilize it? We could still merge the >> changes we want in after the branch is created. >> >> On Mon, Aug 3, 2015 at 4:52 PM, Noble Paul >> wrote: >>> I may have to push the branch by a day or two. There are some more >>> loose ends to be tied up from my side. Sorry for the trouble >>> >>> --Noble >>> >>> On Thu, Jul 30, 2015 at 12:48 PM, Adrien Grand >>> wrote: +1 to releasing 5.3, and thanks for volunteering! On Mon, Jul 27, 2015 at 10:56 AM, Noble Paul wrote: > Hi, > I would like to volunteer myself as the RM for 5.3 release. I > plan to cut the 5.3 release branch by next Monday (03/Aug). > > -- > - > Noble Paul > > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >>> >>> -- >>> - >>> Noble Paul >>> >>> -- >>> --- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For >>> additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> >> >> -- >> Adrien >> >> --- >> -- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For >> additional commands, e-mail: dev-h...@lucene.apache.org >> > > > > -- > - > Noble Paul > > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > additional commands, e-mail: dev-h...@lucene.apache.org > -- R
RE: 5.3 release
I added the 5.3 Policeman Job! Steve: For ASF Jenkins, it would be ideal to rename the preexisting 5.2 jobs and simply change the branch in the subversion settings. Before doing that, be sure to delete the old workspace using the GUI (I am not sure if I did that already...)!!! This is important, because Jenkins does not delete the workspace automatically on rename/job delete, so it consumes large amounts of disk space, which is very limited on the lucene machine. Otherwise create the jobs and delete the outdated workspaces afterwards using SSH / sudo. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Steve Rowe [mailto:sar...@gmail.com] > Sent: Wednesday, August 05, 2015 5:16 PM > To: Lucene Dev > Cc: Uwe Schindler; Noble Paul > Subject: Re: 5.3 release > > I can work on setting up 5.3 release branch jobs on ASF Jenkins later today if > Uwe doesn’t beat me to it. - Steve > > > On Aug 5, 2015, at 11:09 AM, Noble Paul wrote: > > > > I have created the lucene_solr_5_3 branch. > > If anything new must go into 5.3 release please communicate it here > > and commit to the new branch as well > > > > @uwe, @sarowe , can someone help me setup jenkins for the same. > > --Noble > > > > On Wed, Aug 5, 2015 at 7:27 PM, Varun Thacker > > wrote: > >> Hi Noble, > >> > >> I've just now committed SOLR-7818 and SOLR-7756. Both were bug fixes. > >> I'm done from my side for 5.3 > >> > >> On Wed, Aug 5, 2015 at 1:22 PM, Noble Paul > wrote: > >>> > >>> https://issues.apache.org/jira/browse/SOLR-7692 is slated to be a > >>> part of 5.3 . I'm wrapping it up. > >>> As you suggested , it makes sense to cut a branch and stabilize stuff. > >>> I shall cut a branch as soon as possible > >>> > >>> I guess there could be other things too. > >>> --Noble > >>> > >>> On Tue, Aug 4, 2015 at 6:55 PM, Adrien Grand > wrote: > Hi Noble, > > Which changes are delaying the branch creation? Even if everything > that we want for 5.3 is not ready yet, it could be useful to create > the branch now to help stabilize it? We could still merge the > changes we want in after the branch is created. > > On Mon, Aug 3, 2015 at 4:52 PM, Noble Paul > wrote: > > I may have to push the branch by a day or two. There are some more > > loose ends to be tied up from my side. Sorry for the trouble > > > > --Noble > > > > On Thu, Jul 30, 2015 at 12:48 PM, Adrien Grand > > wrote: > >> +1 to releasing 5.3, and thanks for volunteering! > >> > >> On Mon, Jul 27, 2015 at 10:56 AM, Noble Paul > >> > >> wrote: > >>> Hi, > >>> I would like to volunteer myself as the RM for 5.3 release. I > >>> plan to cut the 5.3 release branch by next Monday (03/Aug). > >>> > >>> -- > >>> - > >>> Noble Paul > >>> > >>> > >>> - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>> > >> > >> > >> > >> -- > >> Adrien > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > > > > > > > -- > > - > > Noble Paul > > > > -- > > --- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > > additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > -- > Adrien > > --- > -- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > additional commands, e-mail: dev-h...@lucene.apache.org > > >>> > >>> > >>> > >>> -- > >>> - > >>> Noble Paul > >>> > >>> > >>> - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > >>> additional commands, e-mail: dev-h...@lucene.apache.org > >>> > >> > >> > >> > >> -- > >> > >> > >> Regards, > >> Varun Thacker > > > > > > > > -- > > - > > Noble Paul > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6720) new FunctionRangeQuery, plus ValueSourceScorer improvements
[ https://issues.apache.org/jira/browse/LUCENE-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-6720: - Attachment: LUCENE-6720__FunctionRangeQuery.patch Thanks for the review Adrien! I was hoping you'd chime in. This addresses your two main concerns, I hope. * Both equals() & hashCode() implementations were re-generated using Objects.equals & Objects.hash. FYI I use IntelliJ which has multiple templates, so I switched it to the template that uses these methods. * explain() no longer calls advance to detect if the doc matches; instead it uses the ValueSourceScorer.match method. I added a comment to clarify why this is done. I'd like to file a _separate_ issue for ValueSourceScorer implementations to honor exists() when matching. I don't want that to delay or crowd out the point of this issue. > new FunctionRangeQuery, plus ValueSourceScorer improvements > --- > > Key: LUCENE-6720 > URL: https://issues.apache.org/jira/browse/LUCENE-6720 > Project: Lucene - Core > Issue Type: Bug >Reporter: David Smiley >Assignee: David Smiley > Attachments: LUCENE-6720__FunctionRangeQuery.patch, > LUCENE-6720__FunctionRangeQuery.patch > > > This issue provides a new FunctionRangeQuery, which is basically a wrapper > around ValueSourceScorer (retrieved from FunctionValues.getRangeScorer). It > replaces ValueSourceFilter in the spatial module. Solr has a class by the > same name which is similar but isn't suitable to being ported. > Also, it includes refactorings to the ValueSourceScorer, to include > performance enhancements by making it work with the TwoPhaseIterator API. > note: I posted this to LUCENE-4251 initially but then felt it's really its > own issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Possible to avoid hangs in org.apache.solr.handler.admin.SystemInfoHandler
Just to follow up on this: Replacing getCanonicalHostName() by
getHostName() would solve the problem AFAICS and e.g. Logback does exactly
that for exactly the same purpose.
http://logback.qos.ch/xref/ch/qos/logback/core/util/ContextUtil.html
How do I submit a patch? Via this mailing list?
Best regards,
Robert
On Wed, Aug 5, 2015 at 6:57 PM, Robert Krüger wrote:
>
> Hi,
>
> I am tracking down a problem with huge startup delays of a solr instance
> and tracked it down to this code in SystemInfoHandler:
>
> private void init() {
> try {
> InetAddress addr = InetAddress.getLocalHost();
> hostname = addr.getCanonicalHostName();
> this is where it hangs
> } catch (UnknownHostException e) {
> //default to null
> }
> }
>
> The setup I have gives me no control over the local network configuration
> as solr is delivered as part of a larger software that users install on
> their machines and that has worked really well and it is technically fit
> for this purpose just as other no-sql stores or rdbmss. However, when our
> software users have problems like a reverse lookup not working because they
> work in a VPN environment (which in no other way affects the correct
> operation of solr) they currently have to wait a minute for solr startup
> (otherwise about a second) because two timeouts of these lookups happen,
> one when setting up the container, another for the core and that only to
> have the "host" info contain a name that was reverse-looked up.
>
> Would it be acceptable to submit a patch that allows this to be disabled
> overidden by a system property be acceptable? I.e. suppress the lookup and
> just use what can be retrieved about the host without a lookup (e.g. the ip
> address).
>
> Best regards,
>
> Robert
>
>
--
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG
www.lesspain-software.com
[jira] [Commented] (LUCENE-6417) Upgrade ANTLR to version 4.5
[ https://issues.apache.org/jira/browse/LUCENE-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658667#comment-14658667 ] Uwe Schindler commented on LUCENE-6417: --- bq. I'm fairly confident the VariableContext is meant to be used outside of the package for help parsing variables into their individual pieces OK. I just have not seen any method signature taking the context, so I had the feeling its internal only. But thats unrelated to this issue. > Upgrade ANTLR to version 4.5 > > > Key: LUCENE-6417 > URL: https://issues.apache.org/jira/browse/LUCENE-6417 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jack Conradson >Assignee: Uwe Schindler > Attachments: LUCENE-6471.patch, LUCENE-6471.patch, LUCENE-6471.patch > > > I would like to upgrade ANTLR from 3.5 to 4.5. This version adds several > features that will improve the existing grammars. The main improvement would > be the allowance of left-hand recursion in grammar rules which will reduce > the number of rules significantly for expressions. > This change will require some code refactoring to the existing expressions > work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6722) Java 8 as the minimum supported JVM version for branch_5x
[ https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658666#comment-14658666 ] Shawn Heisey commented on LUCENE-6722: -- bq. Personally, unless we are boxed in a corner, I think this is what major versions are for. I agree. I'm not planning to drop a formal veto on this, but I don't think it's time yet. If the group consensus is that we are *seriously* hampered by Java 7, perhaps we should be working on stabilizing trunk for a 6.0 release. It's true that the switch to Java 7 in version 4.8 has not resulted in the major community backlash that was feared by some, but it was still a risky move, and I don't think we should do it again without a situation where we are frequently fighting with the limitations of the older version and code differences between trunk and the stable branch. I haven't seen any evidence that we are in that situation. My company has a far less stringent policy regarding major upgrades than Erick described, but we still don't do such upgrades just because the new version has been out for X months and the old version is end of life. We still have a small number of things running Java 6, because we don't want to spend the time doing the necessary quality testing to upgrade. Chances are that we could drop Java 7 or 8 in and everything would work great ... but our customers would likely move elsewhere if they found out that we did a major Java upgrade without testing it thoroughly. That's even more likely if they learn about what we did because their website stopped working. > Java 8 as the minimum supported JVM version for branch_5x > - > > Key: LUCENE-6722 > URL: https://issues.apache.org/jira/browse/LUCENE-6722 > Project: Lucene - Core > Issue Type: Wish >Reporter: Shalin Shekhar Mangar >Priority: Blocker > Fix For: 5.4 > > > Require Java 8 as the minimum supported JVM version for branch_5x. > # Java 7 is already EOL'ed > # Trunk is already at Java8 > # Important Solr components such as Jetty 9.3.x already require Java 8 > # Nashorn Javascript engine available in Java 8 is just so much faster and we > may see more usage of JS inside Solr (SOLR-7576 etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Remove empty /clusterstate.json?
FYI - the issue is SOLR-6629 On Wed, Aug 5, 2015 at 11:16 PM, Erick Erickson wrote: > Makes sense, Thanks! > > On Wed, Aug 5, 2015 at 1:33 PM, Noble Paul wrote: >> Though it is not used to store anything in the new scheme of things, >> It is used as a watch and notify node which notifies other nodes of >> creation/deletion of new collections. >> >> There is a JIRA which is created to get rid of that watch and use the >> /collections node for the same. Once it is implemented this can be >> removed >> >> On Wed, Aug 5, 2015 at 10:38 PM, Erick Erickson >> wrote: >>> In response to a note on the user's list, it occurred to me that >>> removing /clusterstate.json when we're in the per-collection format >>> would be less confusing. But that lead me to wonder if we have any >>> current or projected uses for /cluserstate.json. >>> >>> Raise a JIRA? >>> >>> Erick >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> >> >> -- >> - >> Noble Paul >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- Regards, Shalin Shekhar Mangar. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6723) Date field problems using ExtractingRequestHandler and java 9 (b71)
[
https://issues.apache.org/jira/browse/LUCENE-6723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler resolved LUCENE-6723.
---
Resolution: Fixed
Fix Version/s: 5.4
Trunk
5.3
I also committed to 5.3.
> Date field problems using ExtractingRequestHandler and java 9 (b71)
> ---
>
> Key: LUCENE-6723
> URL: https://issues.apache.org/jira/browse/LUCENE-6723
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: 5.3, Trunk, 5.4
>
> Attachments: SOLR-7770.patch
>
>
> Tracking bug to note that the (Tika based) ExtractingRequestHandler will not
> work properly with jdk9 starting with build71.
> This first manifested itself with failures like this from the tests...
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ExtractingRequestHandlerTest
> -Dtests.method=testArabicPDF -Dtests.seed=232D0A5404C2ADED
> -Dtests.multiplier=3 -Dtests.slow=true
> -Dtests.locale=en_JM -Dtests.timezone=Etc/GMT-7 -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR 0.58s | ExtractingRequestHandlerTest.testArabicPDF <<<
>[junit4]> Throwable #1: org.apache.solr.common.SolrException: Invalid
> Date String:'Tue Mar 09 13:44:49
> GMT+07:00 2010'
> {noformat}
> Workarround noted by Uwe...
> {quote}
> The test passes on JDK 9 b71 with:
> -Dargs="-Djava.locale.providers=JRE,SPI"
> This reenabled the old Locale data. I will add this to the build parameters
> of policeman Jenkins to stop this from
> failing. To me it looks like the locale data somehow is not able to correctly
> parse weekdays and/or timezones. I
> will check this out tomorrow and report a bug to the OpenJDK people. There is
> something fishy with CLDR locale data.
> There are already some bugs open, so work is not yet finished (e.g. sometimes
> it uses wrong timezone shortcuts,...)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6723) Date field problems using ExtractingRequestHandler and java 9 (b71)
[
https://issues.apache.org/jira/browse/LUCENE-6723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658655#comment-14658655
]
ASF subversion and git services commented on LUCENE-6723:
-
Commit 1694278 from [~thetaphi] in branch 'dev/branches/lucene_solr_5_3'
[ https://svn.apache.org/r1694278 ]
Merged revision(s) 1694277 from lucene/dev/branches/branch_5x:
Merged revision(s) 1694276 from lucene/dev/trunk:
LUCENE-6723: Fix date parsing problems in Java 9 with date formats using
English weekday/month names.
> Date field problems using ExtractingRequestHandler and java 9 (b71)
> ---
>
> Key: LUCENE-6723
> URL: https://issues.apache.org/jira/browse/LUCENE-6723
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Uwe Schindler
>Priority: Critical
> Attachments: SOLR-7770.patch
>
>
> Tracking bug to note that the (Tika based) ExtractingRequestHandler will not
> work properly with jdk9 starting with build71.
> This first manifested itself with failures like this from the tests...
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ExtractingRequestHandlerTest
> -Dtests.method=testArabicPDF -Dtests.seed=232D0A5404C2ADED
> -Dtests.multiplier=3 -Dtests.slow=true
> -Dtests.locale=en_JM -Dtests.timezone=Etc/GMT-7 -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR 0.58s | ExtractingRequestHandlerTest.testArabicPDF <<<
>[junit4]> Throwable #1: org.apache.solr.common.SolrException: Invalid
> Date String:'Tue Mar 09 13:44:49
> GMT+07:00 2010'
> {noformat}
> Workarround noted by Uwe...
> {quote}
> The test passes on JDK 9 b71 with:
> -Dargs="-Djava.locale.providers=JRE,SPI"
> This reenabled the old Locale data. I will add this to the build parameters
> of policeman Jenkins to stop this from
> failing. To me it looks like the locale data somehow is not able to correctly
> parse weekdays and/or timezones. I
> will check this out tomorrow and report a bug to the OpenJDK people. There is
> something fishy with CLDR locale data.
> There are already some bugs open, so work is not yet finished (e.g. sometimes
> it uses wrong timezone shortcuts,...)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6722) Java 8 as the minimum supported JVM version for branch_5x
[ https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658654#comment-14658654 ] Shalin Shekhar Mangar commented on LUCENE-6722: --- bq. So I'm just sayin' be prepared for a number of requests to "backport JIRAs to Solr 5.3 since we have to stay on Java 7 please". We're not obligated to do that of course. Yeah, I am aware of that, Erick. That is probably going to happen whether we like it or not but let's cross that bridge when we get there. bq. Personally, unless we are boxed in a corner, I think this is what major versions are for. Yeah, but we have precedence. We upgraded to Java 7 in 4.8.0. > Java 8 as the minimum supported JVM version for branch_5x > - > > Key: LUCENE-6722 > URL: https://issues.apache.org/jira/browse/LUCENE-6722 > Project: Lucene - Core > Issue Type: Wish >Reporter: Shalin Shekhar Mangar >Priority: Blocker > Fix For: 5.4 > > > Require Java 8 as the minimum supported JVM version for branch_5x. > # Java 7 is already EOL'ed > # Trunk is already at Java8 > # Important Solr components such as Jetty 9.3.x already require Java 8 > # Nashorn Javascript engine available in Java 8 is just so much faster and we > may see more usage of JS inside Solr (SOLR-7576 etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7879) Null pointer exception when
[ https://issues.apache.org/jira/browse/SOLR-7879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Yang updated SOLR-7879: Component/s: search > Null pointer exception when > > > Key: SOLR-7879 > URL: https://issues.apache.org/jira/browse/SOLR-7879 > Project: Solr > Issue Type: Bug > Components: Facet Module, search >Affects Versions: 5.2.1 > Environment: Oracle jdk1.8 >Reporter: Gary Yang > Labels: faceting, jsonapi, subfacet > > This can be reproduce by certain inputs, but I can't find a pattern in the > inputs that cause this error: > Caused by: > org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error > from server at http://192.168.1.47:8983/solr/core1: > java.lang.NullPointerException > at > org.apache.solr.search.facet.FacetFieldProcessorFCBase.findTopSlots(FacetField.java:301) > at > org.apache.solr.search.facet.FacetFieldProcessorFCBase.getFieldCacheCounts(FacetField.java:254) > at > org.apache.solr.search.facet.FacetFieldProcessorFCBase.process(FacetField.java:218) > at > org.apache.solr.search.facet.FacetProcessor.processSubs(FacetRequest.java:267) > at > org.apache.solr.search.facet.FacetFieldProcessorNumeric.calcFacets(FacetFieldProcessorNumeric.java:472) > at > org.apache.solr.search.facet.FacetFieldProcessorNumeric.process(FacetFieldProcessorNumeric.java:151) > at > org.apache.solr.search.facet.FacetProcessor.processSubs(FacetRequest.java:267) > at > org.apache.solr.search.facet.FacetProcessor.fillBucket(FacetRequest.java:354) > at > org.apache.solr.search.facet.FacetQueryProcessor.process(FacetQuery.java:57) > at org.apache.solr.search.facet.FacetModule.process(FacetModule.java:87) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > at org.eclipse.jetty.server.Server.handle(Server.java:497) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) > at > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 261 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/261/ 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.update.HardAutoCommitTest Error Message: ObjectTracker found 2 object(s) that were not released!!! [TransactionLog] Stack Trace: java.lang.AssertionError: ObjectTracker found 2 object(s) that were not released!!! [TransactionLog] at __randomizedtesting.SeedInfo.seed([21987850F5B91097]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:236) at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 10598 lines...] [junit4] Suite: org.apache.solr.update.HardAutoCommitTest [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J1/temp/solr.update.HardAutoCommitTest_21987850F5B91097-001/init-core-data-001 [junit4] 2> 1395809 INFO (SUITE-HardAutoCommitTest-seed#[21987850F5B91097]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) [junit4] 2> 1395810 INFO (SUITE-HardAutoCommitTest-seed#[21987850F5B91097]-worker) [] o.a.s.SolrTestCaseJ4 initCore [junit4] 2> 1395810 INFO (SUITE-HardAutoCommitTest-seed#[21987850F5B91097]-worker) [] o.a.s.c.SolrResourceLoader new SolrResourceLoader for directory: '/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/core/src/test-files/solr/collection1/' [junit4] 2> 1395810 INFO (SUITE-HardAutoCommitTest-seed#[21987850F5B91097]-worker) [] o.a.s.c.SolrResourceLoader Adding 'file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/core/src/test-files/solr/collection1/lib/.svn/' to classloader [junit4] 2> 1395811 INFO (SUITE-HardAutoCommitTest-seed#[21987850F5B91097]-worker) [] o.a.s.c.SolrResourceLoader Adding 'file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/core/src/test-files/solr/collection1/lib/classes/' to classloader [junit4] 2> 1395811 INFO (SUITE-HardAutoCommitTest-seed#[21987850F5B91097]-worker) [] o.a.s.c.SolrResourceLoader Adding 'file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/core/src/test-files/solr/collection1/lib/README' to classloader [junit4] 2> 1395923 INFO (SUITE-HardAutoCommitTest-seed#[21987850F5B91097]-worker) [] o.a.s.c.SolrConfig current version of requestparams : -1 [junit4] 2> 1395948 INFO (SUITE-HardAutoCommitTest-seed#[21987850F5B91097]-worker) [] o.a.s.c.SolrConfig Using Lucene MatchVersion: 6.0.0 [junit4] 2> 1396072 INFO (
Re: 5.3 release
Figured out the SOLR-7877 issue, patch to follow. - Original Message - From: dev@lucene.apache.org To: dev@lucene.apache.org At: Aug 5 2015 18:39:45 I have opened this ticket to track the test failures https://issues.apache.org/jira/browse/SOLR-7877 On Wed, Aug 5, 2015 at 11:04 PM, Noble Paul wrote: > Which is the JIRA? > > On Wed, Aug 5, 2015 at 9:00 PM, Upayavira wrote: >> I need to update CHANGES.txt to account for a number of bug fixes to the >> angular UI. I'll add a single entry to account for them all. >> >> Upayavira >> >> On Wed, Aug 5, 2015, at 04:15 PM, Steve Rowe wrote: >>> I can work on setting up 5.3 release branch jobs on ASF Jenkins later >>> today if Uwe doesn’t beat me to it. - Steve >>> >>> > On Aug 5, 2015, at 11:09 AM, Noble Paul wrote: >>> > >>> > I have created the lucene_solr_5_3 branch. >>> > If anything new must go into 5.3 release please communicate it here >>> > and commit to the new branch as well >>> > >>> > @uwe, @sarowe , can someone help me setup jenkins for the same. >>> > --Noble >>> > >>> > On Wed, Aug 5, 2015 at 7:27 PM, Varun Thacker >>> > wrote: >>> >> Hi Noble, >>> >> >>> >> I've just now committed SOLR-7818 and SOLR-7756. Both were bug fixes. I'm >>> >> done from my side for 5.3 >>> >> >>> >> On Wed, Aug 5, 2015 at 1:22 PM, Noble Paul wrote: >>> >>> >>> >>> https://issues.apache.org/jira/browse/SOLR-7692 is slated to be a part >>> >>> of 5.3 . I'm wrapping it up. >>> >>> As you suggested , it makes sense to cut a branch and stabilize stuff. >>> >>> I shall cut a branch as soon as possible >>> >>> >>> >>> I guess there could be other things too. >>> >>> --Noble >>> >>> >>> >>> On Tue, Aug 4, 2015 at 6:55 PM, Adrien Grand wrote: >>> Hi Noble, >>> >>> Which changes are delaying the branch creation? Even if everything >>> that we want for 5.3 is not ready yet, it could be useful to create >>> the branch now to help stabilize it? We could still merge the changes >>> we want in after the branch is created. >>> >>> On Mon, Aug 3, 2015 at 4:52 PM, Noble Paul >>> wrote: >>> > I may have to push the branch by a day or two. There are some more >>> > loose ends to be tied up from my side. Sorry for the trouble >>> > >>> > --Noble >>> > >>> > On Thu, Jul 30, 2015 at 12:48 PM, Adrien Grand >>> > wrote: >>> >> +1 to releasing 5.3, and thanks for volunteering! >>> >> >>> >> On Mon, Jul 27, 2015 at 10:56 AM, Noble Paul >>> >> wrote: >>> >>> Hi, >>> >>> I would like to volunteer myself as the RM for 5.3 release. I plan >>> >>> to >>> >>> cut the 5.3 release branch by next Monday (03/Aug). >>> >>> >>> >>> -- >>> >>> - >>> >>> Noble Paul >>> >>> >>> >>> - >>> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Adrien >>> >> >>> >> - >>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> >> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >>> > >>> > >>> > >>> > -- >>> > - >>> > Noble Paul >>> > >>> > - >>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> > For additional commands, e-mail: dev-h...@lucene.apache.org >>> > >>> >>> >>> >>> -- >>> Adrien >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> - >>> >>> Noble Paul >>> >>> >>> >>> - >>> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> >>> >> Regards, >>> >> Varun Thacker >>> > >>> > >>> > >>> > -- >>> > - >>> > Noble Paul >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > > > -- > -
[jira] [Commented] (SOLR-7877) TestAuthenticationFramework test failures
[
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658646#comment-14658646
]
Christine Poerschke commented on SOLR-7877:
---
Test result inspection confirms the theory of test execution ordering within
TestAuthenticationFramework mattering. I will make a change so that
{{TestAuthenticationFramework.testBasics}} restores {{requestUsername}} and
{{requestPassword}} to the values they were at the beginning of the method.
> TestAuthenticationFramework test failures
> -
>
> Key: SOLR-7877
> URL: https://issues.apache.org/jira/browse/SOLR-7877
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3, Trunk
>Reporter: Noble Paul
>Priority: Blocker
>
> {code}
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
> Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
> 1 tests failed.
> FAILED:
> org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
> Error Message:
> Error from server at http://127.0.0.1:51573/solr: Expected mime type
> application/octet-stream but got text/html.http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
> Error 401HTTP ERROR: 401 Problem
> accessing /solr/admin/collections. Reason: Unauthorized
> request Powered by Jetty://
>
> Stack Trace:
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://127.0.0.1:51573/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401
>
>
> HTTP ERROR: 401
> Problem accessing /solr/admin/collections. Reason:
> Unauthorized request
> Powered by Jetty://
>
>
> at
> __randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
> at
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
> at
> org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
> at
> org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-7877) TestAuthenticationFramework test failures
[
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke reassigned SOLR-7877:
-
Assignee: Christine Poerschke
> TestAuthenticationFramework test failures
> -
>
> Key: SOLR-7877
> URL: https://issues.apache.org/jira/browse/SOLR-7877
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3, Trunk
>Reporter: Noble Paul
>Assignee: Christine Poerschke
>Priority: Blocker
>
> {code}
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
> Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
> 1 tests failed.
> FAILED:
> org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
> Error Message:
> Error from server at http://127.0.0.1:51573/solr: Expected mime type
> application/octet-stream but got text/html.http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
> Error 401HTTP ERROR: 401 Problem
> accessing /solr/admin/collections. Reason: Unauthorized
> request Powered by Jetty://
>
> Stack Trace:
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://127.0.0.1:51573/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401
>
>
> HTTP ERROR: 401
> Problem accessing /solr/admin/collections. Reason:
> Unauthorized request
> Powered by Jetty://
>
>
> at
> __randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
> at
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
> at
> org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
> at
> org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6724) Add support for computing GeoHash neighbors to GeoHashUtils
[ https://issues.apache.org/jira/browse/LUCENE-6724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6724: --- Attachment: LUCENE-6724.patch Initial patch that computes the neighbor(s) from a provided GeoHash. Javadocs and unit testing included. > Add support for computing GeoHash neighbors to GeoHashUtils > --- > > Key: LUCENE-6724 > URL: https://issues.apache.org/jira/browse/LUCENE-6724 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Nicholas Knize > Attachments: LUCENE-6724.patch > > > This simple feature adds the ability to compute the geohash neighbor(s) at a > given level, from a provided geohash. Such a utility is beneficial for simple > grid faceting/aggregations and geohash based bounding box queries. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6723) Date field problems using ExtractingRequestHandler and java 9 (b71)
[
https://issues.apache.org/jira/browse/LUCENE-6723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658638#comment-14658638
]
ASF subversion and git services commented on LUCENE-6723:
-
Commit 1694277 from [~thetaphi] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694277 ]
Merged revision(s) 1694276 from lucene/dev/trunk:
LUCENE-6723: Fix date parsing problems in Java 9 with date formats using
English weekday/month names.
> Date field problems using ExtractingRequestHandler and java 9 (b71)
> ---
>
> Key: LUCENE-6723
> URL: https://issues.apache.org/jira/browse/LUCENE-6723
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Uwe Schindler
>Priority: Critical
> Attachments: SOLR-7770.patch
>
>
> Tracking bug to note that the (Tika based) ExtractingRequestHandler will not
> work properly with jdk9 starting with build71.
> This first manifested itself with failures like this from the tests...
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ExtractingRequestHandlerTest
> -Dtests.method=testArabicPDF -Dtests.seed=232D0A5404C2ADED
> -Dtests.multiplier=3 -Dtests.slow=true
> -Dtests.locale=en_JM -Dtests.timezone=Etc/GMT-7 -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR 0.58s | ExtractingRequestHandlerTest.testArabicPDF <<<
>[junit4]> Throwable #1: org.apache.solr.common.SolrException: Invalid
> Date String:'Tue Mar 09 13:44:49
> GMT+07:00 2010'
> {noformat}
> Workarround noted by Uwe...
> {quote}
> The test passes on JDK 9 b71 with:
> -Dargs="-Djava.locale.providers=JRE,SPI"
> This reenabled the old Locale data. I will add this to the build parameters
> of policeman Jenkins to stop this from
> failing. To me it looks like the locale data somehow is not able to correctly
> parse weekdays and/or timezones. I
> will check this out tomorrow and report a bug to the OpenJDK people. There is
> something fishy with CLDR locale data.
> There are already some bugs open, so work is not yet finished (e.g. sometimes
> it uses wrong timezone shortcuts,...)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658636#comment-14658636
]
Christine Poerschke commented on SOLR-7766:
---
Nothing interesting from SOLR-6971 dumper patch so far, but have a theory re:
TestAuthenticationFramework test method call ordering, will add further notes
on SOLR-7877.
> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
> Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7766.patch, SOLR-7766.txt
>
>
> By supplying the special value of EMPTY for the createNodeSet parameter (via
> {{.../solr/admin/collections?action=CREATE&createNodeSet=EMPTY&name=myCollection&...}})
> a collection can be created in the usual manner but it will just not yet
> contain any cores for any of its shards. Later on
> {{.../solr/admin/collections?wt=json&action=ADDREPLICA&collection=myCollection&...}}
> calls can create cores as and when and where required.
> github pull request with proposed changes to follow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7877) TestAuthenticationFramework test failures
[
https://issues.apache.org/jira/browse/SOLR-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658634#comment-14658634
]
Christine Poerschke commented on SOLR-7877:
---
TestAuthenticationFramework overrides the {{testBasics}} method but does not
override the {{testCollectionCreateWithoutCoresThenDelete}} method. Would this
mean that if testCollectionCreateWithoutCoresThenDelete runs after testBasics
the former is bound to fail because it will use the requestUsername and
requestPassword last set by the latter?
{code}
public class TestAuthenticationFramework extends TestMiniSolrCloudCluster {
...
static String requestUsername = MockAuthenticationPlugin.expectedUsername;
static String requestPassword = MockAuthenticationPlugin.expectedPassword;
...
@Test
@Override
public void testBasics() throws Exception {
requestUsername = MockAuthenticationPlugin.expectedUsername;
requestPassword = MockAuthenticationPlugin.expectedPassword;
final String collectionName = "testAuthenticationFrameworkCollection";
// Should pass
testCollectionCreateSearchDelete(collectionName);
requestUsername = MockAuthenticationPlugin.expectedUsername;
requestPassword = "junkpassword";
// Should fail with 401
try {
testCollectionCreateSearchDelete(collectionName);
fail("Should've returned a 401 error");
} catch (Exception ex) {
if (!ex.getMessage().contains("Error 401")) {
fail("Should've returned a 401 error");
}
}
}
{code}
> TestAuthenticationFramework test failures
> -
>
> Key: SOLR-7877
> URL: https://issues.apache.org/jira/browse/SOLR-7877
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.3, Trunk
>Reporter: Noble Paul
>Priority: Blocker
>
> {code}
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
> Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
> 1 tests failed.
> FAILED:
> org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
> Error Message:
> Error from server at http://127.0.0.1:51573/solr: Expected mime type
> application/octet-stream but got text/html.http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
> Error 401HTTP ERROR: 401 Problem
> accessing /solr/admin/collections. Reason: Unauthorized
> request Powered by Jetty://
>
> Stack Trace:
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://127.0.0.1:51573/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401
>
>
> HTTP ERROR: 401
> Problem accessing /solr/admin/collections. Reason:
> Unauthorized request
> Powered by Jetty://
>
>
> at
> __randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
> at
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
> at
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
> at
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
> at
> org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
> at
> org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6723) Date field problems using ExtractingRequestHandler and java 9 (b71)
[
https://issues.apache.org/jira/browse/LUCENE-6723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658633#comment-14658633
]
ASF subversion and git services commented on LUCENE-6723:
-
Commit 1694276 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1694276 ]
LUCENE-6723: Fix date parsing problems in Java 9 with date formats using
English weekday/month names.
> Date field problems using ExtractingRequestHandler and java 9 (b71)
> ---
>
> Key: LUCENE-6723
> URL: https://issues.apache.org/jira/browse/LUCENE-6723
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Uwe Schindler
>Priority: Critical
> Attachments: SOLR-7770.patch
>
>
> Tracking bug to note that the (Tika based) ExtractingRequestHandler will not
> work properly with jdk9 starting with build71.
> This first manifested itself with failures like this from the tests...
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ExtractingRequestHandlerTest
> -Dtests.method=testArabicPDF -Dtests.seed=232D0A5404C2ADED
> -Dtests.multiplier=3 -Dtests.slow=true
> -Dtests.locale=en_JM -Dtests.timezone=Etc/GMT-7 -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR 0.58s | ExtractingRequestHandlerTest.testArabicPDF <<<
>[junit4]> Throwable #1: org.apache.solr.common.SolrException: Invalid
> Date String:'Tue Mar 09 13:44:49
> GMT+07:00 2010'
> {noformat}
> Workarround noted by Uwe...
> {quote}
> The test passes on JDK 9 b71 with:
> -Dargs="-Djava.locale.providers=JRE,SPI"
> This reenabled the old Locale data. I will add this to the build parameters
> of policeman Jenkins to stop this from
> failing. To me it looks like the locale data somehow is not able to correctly
> parse weekdays and/or timezones. I
> will check this out tomorrow and report a bug to the OpenJDK people. There is
> something fishy with CLDR locale data.
> There are already some bugs open, so work is not yet finished (e.g. sometimes
> it uses wrong timezone shortcuts,...)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6724) Add support for computing GeoHash neighbors to GeoHashUtils
Nicholas Knize created LUCENE-6724: -- Summary: Add support for computing GeoHash neighbors to GeoHashUtils Key: LUCENE-6724 URL: https://issues.apache.org/jira/browse/LUCENE-6724 Project: Lucene - Core Issue Type: Improvement Reporter: Nicholas Knize This simple feature adds the ability to compute the geohash neighbor(s) at a given level, from a provided geohash. Such a utility is beneficial for simple grid faceting/aggregations and geohash based bounding box queries. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Moved] (LUCENE-6723) Date field problems using ExtractingRequestHandler and java 9 (b71)
[
https://issues.apache.org/jira/browse/LUCENE-6723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler moved SOLR-7770 to LUCENE-6723:
-
Lucene Fields: New
Key: LUCENE-6723 (was: SOLR-7770)
Project: Lucene - Core (was: Solr)
> Date field problems using ExtractingRequestHandler and java 9 (b71)
> ---
>
> Key: LUCENE-6723
> URL: https://issues.apache.org/jira/browse/LUCENE-6723
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Uwe Schindler
>Priority: Critical
> Attachments: SOLR-7770.patch
>
>
> Tracking bug to note that the (Tika based) ExtractingRequestHandler will not
> work properly with jdk9 starting with build71.
> This first manifested itself with failures like this from the tests...
> {noformat}
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ExtractingRequestHandlerTest
> -Dtests.method=testArabicPDF -Dtests.seed=232D0A5404C2ADED
> -Dtests.multiplier=3 -Dtests.slow=true
> -Dtests.locale=en_JM -Dtests.timezone=Etc/GMT-7 -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR 0.58s | ExtractingRequestHandlerTest.testArabicPDF <<<
>[junit4]> Throwable #1: org.apache.solr.common.SolrException: Invalid
> Date String:'Tue Mar 09 13:44:49
> GMT+07:00 2010'
> {noformat}
> Workarround noted by Uwe...
> {quote}
> The test passes on JDK 9 b71 with:
> -Dargs="-Djava.locale.providers=JRE,SPI"
> This reenabled the old Locale data. I will add this to the build parameters
> of policeman Jenkins to stop this from
> failing. To me it looks like the locale data somehow is not able to correctly
> parse weekdays and/or timezones. I
> will check this out tomorrow and report a bug to the OpenJDK people. There is
> something fishy with CLDR locale data.
> There are already some bugs open, so work is not yet finished (e.g. sometimes
> it uses wrong timezone shortcuts,...)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6722) Java 8 as the minimum supported JVM version for branch_5x
[ https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658624#comment-14658624 ] Mark Miller commented on LUCENE-6722: - Personally, unless we are boxed in a corner, I think this is what major versions are for. > Java 8 as the minimum supported JVM version for branch_5x > - > > Key: LUCENE-6722 > URL: https://issues.apache.org/jira/browse/LUCENE-6722 > Project: Lucene - Core > Issue Type: Wish >Reporter: Shalin Shekhar Mangar >Priority: Blocker > Fix For: 5.4 > > > Require Java 8 as the minimum supported JVM version for branch_5x. > # Java 7 is already EOL'ed > # Trunk is already at Java8 > # Important Solr components such as Jetty 9.3.x already require Java 8 > # Nashorn Javascript engine available in Java 8 is just so much faster and we > may see more usage of JS inside Solr (SOLR-7576 etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6722) Java 8 as the minimum supported JVM version for branch_5x
[ https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658598#comment-14658598 ] Erick Erickson commented on LUCENE-6722: Do be aware that this is significantly painful for a number of organizations. I agree that we _can't_ be hobbled by some Solr user out there who refuses/can't migrate to Java8. But this is a 6 month process involving 8 different departments for some organizations. So I'm just sayin' be prepared for a number of requests to "backport JIRAs to Solr 5.3 since we have to stay on Java 7 please". We're not obligated to do that of course. > Java 8 as the minimum supported JVM version for branch_5x > - > > Key: LUCENE-6722 > URL: https://issues.apache.org/jira/browse/LUCENE-6722 > Project: Lucene - Core > Issue Type: Wish >Reporter: Shalin Shekhar Mangar >Priority: Blocker > Fix For: 5.4 > > > Require Java 8 as the minimum supported JVM version for branch_5x. > # Java 7 is already EOL'ed > # Trunk is already at Java8 > # Important Solr components such as Jetty 9.3.x already require Java 8 > # Nashorn Javascript engine available in Java 8 is just so much faster and we > may see more usage of JS inside Solr (SOLR-7576 etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b60) - Build # 13743 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13743/ Java: 32bit/jdk1.9.0-ea-b60 -client -XX:+UseConcMarkSweepGC -Djava.locale.providers=JRE,SPI 1 tests failed. FAILED: org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete Error Message: Error from server at http://127.0.0.1:58632/solr: Expected mime type application/octet-stream but got text/html.Error 401HTTP ERROR: 401 Problem accessing /solr/admin/collections. Reason: Unauthorized request Powered by Jetty:// Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:58632/solr: Expected mime type application/octet-stream but got text/html. Error 401 HTTP ERROR: 401 Problem accessing /solr/admin/collections. Reason: Unauthorized request Powered by Jetty:// at __randomizedtesting.SeedInfo.seed([C0182B915509A329:73DDE4505A717068]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349) at org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333) at org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115) at org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298) 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:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.
[jira] [Created] (SOLR-7879) Null pointer exception when
Gary Yang created SOLR-7879: --- Summary: Null pointer exception when Key: SOLR-7879 URL: https://issues.apache.org/jira/browse/SOLR-7879 Project: Solr Issue Type: Bug Components: Facet Module Affects Versions: 5.2.1 Environment: Oracle jdk1.8 Reporter: Gary Yang This can be reproduce by certain inputs, but I can't find a pattern in the inputs that cause this error: Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://192.168.1.47:8983/solr/core1: java.lang.NullPointerException at org.apache.solr.search.facet.FacetFieldProcessorFCBase.findTopSlots(FacetField.java:301) at org.apache.solr.search.facet.FacetFieldProcessorFCBase.getFieldCacheCounts(FacetField.java:254) at org.apache.solr.search.facet.FacetFieldProcessorFCBase.process(FacetField.java:218) at org.apache.solr.search.facet.FacetProcessor.processSubs(FacetRequest.java:267) at org.apache.solr.search.facet.FacetFieldProcessorNumeric.calcFacets(FacetFieldProcessorNumeric.java:472) at org.apache.solr.search.facet.FacetFieldProcessorNumeric.process(FacetFieldProcessorNumeric.java:151) at org.apache.solr.search.facet.FacetProcessor.processSubs(FacetRequest.java:267) at org.apache.solr.search.facet.FacetProcessor.fillBucket(FacetRequest.java:354) at org.apache.solr.search.facet.FacetQueryProcessor.process(FacetQuery.java:57) at org.apache.solr.search.facet.FacetModule.process(FacetModule.java:87) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.eclipse.jetty.server.Server.handle(Server.java:497) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7220) comments for query strings
[
https://issues.apache.org/jira/browse/SOLR-7220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-7220.
Resolution: Fixed
Fix Version/s: 5.3
> comments for query strings
> --
>
> Key: SOLR-7220
> URL: https://issues.apache.org/jira/browse/SOLR-7220
> Project: Solr
> Issue Type: New Feature
>Reporter: Yonik Seeley
> Fix For: 5.3
>
> Attachments: SOLR-7220.patch
>
>
> It's often very useful to be able to put comments in a large query string, or
> temporarily comment out part of a large query string.
> This feature adds C-style comments that may be nested.
> Query Comments Example:
> {code}
> description:HDTV /* TODO: +promotion:tv +promotion_date:[NOW/DAY-7DAYS TO
> NOW/DAY+1DAY] */
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7220) comments for query strings
[
https://issues.apache.org/jira/browse/SOLR-7220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658585#comment-14658585
]
ASF subversion and git services commented on SOLR-7220:
---
Commit 1694275 from [~yo...@apache.org] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694275 ]
SOLR-7220: Nested C-style comments in solr queries.
> comments for query strings
> --
>
> Key: SOLR-7220
> URL: https://issues.apache.org/jira/browse/SOLR-7220
> Project: Solr
> Issue Type: New Feature
>Reporter: Yonik Seeley
> Attachments: SOLR-7220.patch
>
>
> It's often very useful to be able to put comments in a large query string, or
> temporarily comment out part of a large query string.
> This feature adds C-style comments that may be nested.
> Query Comments Example:
> {code}
> description:HDTV /* TODO: +promotion:tv +promotion_date:[NOW/DAY-7DAYS TO
> NOW/DAY+1DAY] */
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7730) speed-up faceting on doc values fields
[
https://issues.apache.org/jira/browse/SOLR-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-7730.
Resolution: Fixed
> speed-up faceting on doc values fields
> --
>
> Key: SOLR-7730
> URL: https://issues.apache.org/jira/browse/SOLR-7730
> Project: Solr
> Issue Type: Improvement
> Components: faceting
>Affects Versions: 5.2.1
>Reporter: Mikhail Khludnev
> Labels: patch
> Fix For: 5.3
>
> Attachments: LUCENE-7730.patch, LUCENE-7730.patch, SOLR-7730.patch
>
>
> every time we count facets on DocValues fields in Solr on many segments index
> we see the unnecessary hotspot:
> {code}
>
> at
> org.apache.lucene.index.MultiFields.getMergedFieldInfos(MultiFields.java:248)
> at
> org.apache.lucene.index.SlowCompositeReaderWrapper.getFieldInfos(SlowCompositeReaderWrapper.java:239)
> at
> org.apache.lucene.index.SlowCompositeReaderWrapper.getSortedSetDocValues(SlowCompositeReaderWrapper.java:176)
> at
> org.apache.solr.request.DocValuesFacets.getCounts(DocValuesFacets.java:72)
> at
> org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:460)
> {code}
> the reason is SlowCompositeReaderWrapper.getSortedSetDocValues() Line 136 and
> SlowCompositeReaderWrapper.getSortedDocValues() Line 174
> before return composite doc values, SCWR merges segment field infos, which is
> expensive, but after fieldinfo is merged, it checks *only* docvalue type in
> it. This dv type check can be done much easier in per segment basis.
> This patch gets some performance gain for those who count DV facets in Solr.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7878) Use SortedNumericDocValues (efficient sort & facet on multi-valued numeric fields)
David Smiley created SOLR-7878: -- Summary: Use SortedNumericDocValues (efficient sort & facet on multi-valued numeric fields) Key: SOLR-7878 URL: https://issues.apache.org/jira/browse/SOLR-7878 Project: Solr Issue Type: Improvement Components: Facet Module Reporter: David Smiley Lucene has a SortedNumericDocValues (i.e. multi-valued numeric DocValues), ever since late in the 4x versions. Solr's TrieField.createFields unfortunately still uses SortedSetDocValues for the multi-valued case. SortedNumericDocValues is more efficient than SortedSetDocValues; for example there is no 'ordinal' mapping for sorting/faceting needed. Unfortunately, updating Solr here would be quite a bit of work, since there are backwards-compatibility concerns, and faceting code would need a new code path implementation just for this. Sorting is relatively simple thanks to SortedNumericSortField, and today multi-valued sorting isn't directly possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7220) comments for query strings
[
https://issues.apache.org/jira/browse/SOLR-7220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658580#comment-14658580
]
ASF subversion and git services commented on SOLR-7220:
---
Commit 1694273 from [~yo...@apache.org] in branch 'dev/trunk'
[ https://svn.apache.org/r1694273 ]
SOLR-7220: Nested C-style comments in solr queries.
> comments for query strings
> --
>
> Key: SOLR-7220
> URL: https://issues.apache.org/jira/browse/SOLR-7220
> Project: Solr
> Issue Type: New Feature
>Reporter: Yonik Seeley
> Attachments: SOLR-7220.patch
>
>
> It's often very useful to be able to put comments in a large query string, or
> temporarily comment out part of a large query string.
> This feature adds C-style comments that may be nested.
> Query Comments Example:
> {code}
> description:HDTV /* TODO: +promotion:tv +promotion_date:[NOW/DAY-7DAYS TO
> NOW/DAY+1DAY] */
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Remove empty /clusterstate.json?
Makes sense, Thanks! On Wed, Aug 5, 2015 at 1:33 PM, Noble Paul wrote: > Though it is not used to store anything in the new scheme of things, > It is used as a watch and notify node which notifies other nodes of > creation/deletion of new collections. > > There is a JIRA which is created to get rid of that watch and use the > /collections node for the same. Once it is implemented this can be > removed > > On Wed, Aug 5, 2015 at 10:38 PM, Erick Erickson > wrote: >> In response to a note on the user's list, it occurred to me that >> removing /clusterstate.json when we're in the per-collection format >> would be less confusing. But that lead me to wonder if we have any >> current or projected uses for /cluserstate.json. >> >> Raise a JIRA? >> >> Erick >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > > > -- > - > Noble Paul > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 5.3 release
I have opened this ticket to track the test failures https://issues.apache.org/jira/browse/SOLR-7877 On Wed, Aug 5, 2015 at 11:04 PM, Noble Paul wrote: > Which is the JIRA? > > On Wed, Aug 5, 2015 at 9:00 PM, Upayavira wrote: >> I need to update CHANGES.txt to account for a number of bug fixes to the >> angular UI. I'll add a single entry to account for them all. >> >> Upayavira >> >> On Wed, Aug 5, 2015, at 04:15 PM, Steve Rowe wrote: >>> I can work on setting up 5.3 release branch jobs on ASF Jenkins later >>> today if Uwe doesn’t beat me to it. - Steve >>> >>> > On Aug 5, 2015, at 11:09 AM, Noble Paul wrote: >>> > >>> > I have created the lucene_solr_5_3 branch. >>> > If anything new must go into 5.3 release please communicate it here >>> > and commit to the new branch as well >>> > >>> > @uwe, @sarowe , can someone help me setup jenkins for the same. >>> > --Noble >>> > >>> > On Wed, Aug 5, 2015 at 7:27 PM, Varun Thacker >>> > wrote: >>> >> Hi Noble, >>> >> >>> >> I've just now committed SOLR-7818 and SOLR-7756. Both were bug fixes. I'm >>> >> done from my side for 5.3 >>> >> >>> >> On Wed, Aug 5, 2015 at 1:22 PM, Noble Paul wrote: >>> >>> >>> >>> https://issues.apache.org/jira/browse/SOLR-7692 is slated to be a part >>> >>> of 5.3 . I'm wrapping it up. >>> >>> As you suggested , it makes sense to cut a branch and stabilize stuff. >>> >>> I shall cut a branch as soon as possible >>> >>> >>> >>> I guess there could be other things too. >>> >>> --Noble >>> >>> >>> >>> On Tue, Aug 4, 2015 at 6:55 PM, Adrien Grand wrote: >>> Hi Noble, >>> >>> Which changes are delaying the branch creation? Even if everything >>> that we want for 5.3 is not ready yet, it could be useful to create >>> the branch now to help stabilize it? We could still merge the changes >>> we want in after the branch is created. >>> >>> On Mon, Aug 3, 2015 at 4:52 PM, Noble Paul >>> wrote: >>> > I may have to push the branch by a day or two. There are some more >>> > loose ends to be tied up from my side. Sorry for the trouble >>> > >>> > --Noble >>> > >>> > On Thu, Jul 30, 2015 at 12:48 PM, Adrien Grand >>> > wrote: >>> >> +1 to releasing 5.3, and thanks for volunteering! >>> >> >>> >> On Mon, Jul 27, 2015 at 10:56 AM, Noble Paul >>> >> wrote: >>> >>> Hi, >>> >>> I would like to volunteer myself as the RM for 5.3 release. I plan >>> >>> to >>> >>> cut the 5.3 release branch by next Monday (03/Aug). >>> >>> >>> >>> -- >>> >>> - >>> >>> Noble Paul >>> >>> >>> >>> - >>> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Adrien >>> >> >>> >> - >>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> >> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >>> > >>> > >>> > >>> > -- >>> > - >>> > Noble Paul >>> > >>> > - >>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> > For additional commands, e-mail: dev-h...@lucene.apache.org >>> > >>> >>> >>> >>> -- >>> Adrien >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> - >>> >>> Noble Paul >>> >>> >>> >>> - >>> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> >>> >> Regards, >>> >> Varun Thacker >>> > >>> > >>> > >>> > -- >>> > - >>> > Noble Paul >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > > > -- > - > Noble Paul -- - Noble Paul -
[jira] [Commented] (SOLR-7730) speed-up faceting on doc values fields
[
https://issues.apache.org/jira/browse/SOLR-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658567#comment-14658567
]
ASF subversion and git services commented on SOLR-7730:
---
Commit 1694269 from [~yo...@apache.org] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1694269 ]
SOLR-7730: SlowCompositeReaderWrapper.getSortedSetDocValues - don't merge
FieldInfos just to check DocValueType
> speed-up faceting on doc values fields
> --
>
> Key: SOLR-7730
> URL: https://issues.apache.org/jira/browse/SOLR-7730
> Project: Solr
> Issue Type: Improvement
> Components: faceting
>Affects Versions: 5.2.1
>Reporter: Mikhail Khludnev
> Labels: patch
> Fix For: 5.3
>
> Attachments: LUCENE-7730.patch, LUCENE-7730.patch, SOLR-7730.patch
>
>
> every time we count facets on DocValues fields in Solr on many segments index
> we see the unnecessary hotspot:
> {code}
>
> at
> org.apache.lucene.index.MultiFields.getMergedFieldInfos(MultiFields.java:248)
> at
> org.apache.lucene.index.SlowCompositeReaderWrapper.getFieldInfos(SlowCompositeReaderWrapper.java:239)
> at
> org.apache.lucene.index.SlowCompositeReaderWrapper.getSortedSetDocValues(SlowCompositeReaderWrapper.java:176)
> at
> org.apache.solr.request.DocValuesFacets.getCounts(DocValuesFacets.java:72)
> at
> org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:460)
> {code}
> the reason is SlowCompositeReaderWrapper.getSortedSetDocValues() Line 136 and
> SlowCompositeReaderWrapper.getSortedDocValues() Line 174
> before return composite doc values, SCWR merges segment field infos, which is
> expensive, but after fieldinfo is merged, it checks *only* docvalue type in
> it. This dv type check can be done much easier in per segment basis.
> This patch gets some performance gain for those who count DV facets in Solr.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7877) TestAuthenticationFramework test failures
Noble Paul created SOLR-7877:
Summary: TestAuthenticationFramework test failures
Key: SOLR-7877
URL: https://issues.apache.org/jira/browse/SOLR-7877
Project: Solr
Issue Type: Bug
Affects Versions: 5.3, Trunk
Reporter: Noble Paul
Priority: Blocker
{code}
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13742/
Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
1 tests failed.
FAILED:
org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateWithoutCoresThenDelete
Error Message:
Error from server at http://127.0.0.1:51573/solr: Expected mime type
application/octet-stream but got text/html.Error
401HTTP ERROR: 401 Problem accessing
/solr/admin/collections. Reason: Unauthorized request Powered by Jetty://
Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:51573/solr: Expected mime type
application/octet-stream but got text/html.
Error 401
HTTP ERROR: 401
Problem accessing /solr/admin/collections. Reason:
Unauthorized request
Powered by Jetty://
at
__randomizedtesting.SeedInfo.seed([A454441B503006EB:17918BDA5F48D5AA]:0)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:528)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at
org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:349)
at
org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:333)
at
org.apache.solr.cloud.TestMiniSolrCloudCluster.createCollection(TestMiniSolrCloudCluster.java:115)
at
org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete(TestMiniSolrCloudCluster.java:298)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6722) Java 8 as the minimum supported JVM version for branch_5x
[ https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658564#comment-14658564 ] Anshum Gupta commented on LUCENE-6722: -- +1. Glad to see this happening. > Java 8 as the minimum supported JVM version for branch_5x > - > > Key: LUCENE-6722 > URL: https://issues.apache.org/jira/browse/LUCENE-6722 > Project: Lucene - Core > Issue Type: Wish >Reporter: Shalin Shekhar Mangar >Priority: Blocker > Fix For: 5.4 > > > Require Java 8 as the minimum supported JVM version for branch_5x. > # Java 7 is already EOL'ed > # Trunk is already at Java8 > # Important Solr components such as Jetty 9.3.x already require Java 8 > # Nashorn Javascript engine available in Java 8 is just so much faster and we > may see more usage of JS inside Solr (SOLR-7576 etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 5.3 release
Which is the JIRA? On Wed, Aug 5, 2015 at 9:00 PM, Upayavira wrote: > I need to update CHANGES.txt to account for a number of bug fixes to the > angular UI. I'll add a single entry to account for them all. > > Upayavira > > On Wed, Aug 5, 2015, at 04:15 PM, Steve Rowe wrote: >> I can work on setting up 5.3 release branch jobs on ASF Jenkins later >> today if Uwe doesn’t beat me to it. - Steve >> >> > On Aug 5, 2015, at 11:09 AM, Noble Paul wrote: >> > >> > I have created the lucene_solr_5_3 branch. >> > If anything new must go into 5.3 release please communicate it here >> > and commit to the new branch as well >> > >> > @uwe, @sarowe , can someone help me setup jenkins for the same. >> > --Noble >> > >> > On Wed, Aug 5, 2015 at 7:27 PM, Varun Thacker >> > wrote: >> >> Hi Noble, >> >> >> >> I've just now committed SOLR-7818 and SOLR-7756. Both were bug fixes. I'm >> >> done from my side for 5.3 >> >> >> >> On Wed, Aug 5, 2015 at 1:22 PM, Noble Paul wrote: >> >>> >> >>> https://issues.apache.org/jira/browse/SOLR-7692 is slated to be a part >> >>> of 5.3 . I'm wrapping it up. >> >>> As you suggested , it makes sense to cut a branch and stabilize stuff. >> >>> I shall cut a branch as soon as possible >> >>> >> >>> I guess there could be other things too. >> >>> --Noble >> >>> >> >>> On Tue, Aug 4, 2015 at 6:55 PM, Adrien Grand wrote: >> Hi Noble, >> >> Which changes are delaying the branch creation? Even if everything >> that we want for 5.3 is not ready yet, it could be useful to create >> the branch now to help stabilize it? We could still merge the changes >> we want in after the branch is created. >> >> On Mon, Aug 3, 2015 at 4:52 PM, Noble Paul wrote: >> > I may have to push the branch by a day or two. There are some more >> > loose ends to be tied up from my side. Sorry for the trouble >> > >> > --Noble >> > >> > On Thu, Jul 30, 2015 at 12:48 PM, Adrien Grand >> > wrote: >> >> +1 to releasing 5.3, and thanks for volunteering! >> >> >> >> On Mon, Jul 27, 2015 at 10:56 AM, Noble Paul >> >> wrote: >> >>> Hi, >> >>> I would like to volunteer myself as the RM for 5.3 release. I plan to >> >>> cut the 5.3 release branch by next Monday (03/Aug). >> >>> >> >>> -- >> >>> - >> >>> Noble Paul >> >>> >> >>> - >> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>> >> >> >> >> >> >> >> >> -- >> >> Adrien >> >> >> >> - >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> > >> > >> > >> > -- >> > - >> > Noble Paul >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> >> >> >> -- >> Adrien >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >>> >> >>> >> >>> >> >>> -- >> >>> - >> >>> Noble Paul >> >>> >> >>> - >> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> Regards, >> >> Varun Thacker >> > >> > >> > >> > -- >> > - >> > Noble Paul >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6722) Java 8 as the minimum supported JVM version for branch_5x
[ https://issues.apache.org/jira/browse/LUCENE-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658563#comment-14658563 ] Noble Paul commented on LUCENE-6722: +1 Please do it > Java 8 as the minimum supported JVM version for branch_5x > - > > Key: LUCENE-6722 > URL: https://issues.apache.org/jira/browse/LUCENE-6722 > Project: Lucene - Core > Issue Type: Wish >Reporter: Shalin Shekhar Mangar >Priority: Blocker > Fix For: 5.4 > > > Require Java 8 as the minimum supported JVM version for branch_5x. > # Java 7 is already EOL'ed > # Trunk is already at Java8 > # Important Solr components such as Jetty 9.3.x already require Java 8 > # Nashorn Javascript engine available in Java 8 is just so much faster and we > may see more usage of JS inside Solr (SOLR-7576 etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
