[JENKINS] Lucene-Solr-BadApples-NightlyTests-8.x - Build # 18 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-8.x/18/ 4 tests failed. FAILED: org.apache.solr.cloud.cdcr.CdcrReplicationHandlerTest.testReplicationWithBufferedUpdates Error Message: Timeout while trying to assert number of documents @ source_collection Stack Trace: java.lang.AssertionError: Timeout while trying to assert number of documents @ source_collection at __randomizedtesting.SeedInfo.seed([4B3A2CC6A678FCFA:98337CD8E3EB606D]:0) at org.apache.solr.cloud.cdcr.BaseCdcrDistributedZkTest.assertNumDocs(BaseCdcrDistributedZkTest.java:277) at org.apache.solr.cloud.cdcr.CdcrReplicationHandlerTest.testReplicationWithBufferedUpdates(CdcrReplicationHandlerTest.java:233) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakCont
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11.0.2) - Build # 24139 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24139/
Java: 64bit/jdk-11.0.2 -XX:-UseCompressedOops -XX:+UseSerialGC
All tests passed
Build Log:
[...truncated 62717 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1372855617
[ecj-lint] Compiling 69 source files to /tmp/ecj1372855617
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 28)
[ecj-lint] import javax.naming.InitialContext;
[ecj-lint]^^^
[ecj-lint] The type javax.naming.InitialContext is not accessible
[ecj-lint] --
[ecj-lint] 2. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 29)
[ecj-lint] import javax.naming.NamingException;
[ecj-lint]
[ecj-lint] The type javax.naming.NamingException is not accessible
[ecj-lint] --
[ecj-lint] 3. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 182)
[ecj-lint] c = getFromJndi(initProps, jndiName);
[ecj-lint] ^^^
[ecj-lint] The method getFromJndi(Properties, String) from the type new
Callable(){} refers to the missing type NamingException
[ecj-lint] --
[ecj-lint] 4. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 245)
[ecj-lint] private Connection getFromJndi(final Properties initProps,
final String jndiName) throws NamingException,
[ecj-lint]
^^^
[ecj-lint] NamingException cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 5. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 249)
[ecj-lint] InitialContext ctx = new InitialContext();
[ecj-lint] ^^
[ecj-lint] InitialContext cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 6. ERROR in
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
(at line 249)
[ecj-lint] InitialContext ctx = new InitialContext();
[ecj-lint] ^^
[ecj-lint] InitialContext cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 6 problems (6 errors)
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:634: The following
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:101: The following
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build.xml:651: The
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/common-build.xml:479: The
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2009:
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2048:
Compile failed; see the compiler error output for details.
Total time: 84 minutes 30 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For a
[jira] [Commented] (SOLR-13490) waitForState/registerCollectionStateWatcher can see stale liveNodes data due to (Zk) Watcher race condition
[
https://issues.apache.org/jira/browse/SOLR-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847973#comment-16847973
]
Hoss Man commented on SOLR-13490:
-
Here are some half thought out solutions for this problem in general...
# {{StateWatcher.process()}} (and {{LegacyClusterStateWatcher.process()}} )
could forcibly call {{updateLiveNodes()}} before evaluating the
{{CollectionWatch}} instances for the collection(s)
# {{refreshLiveNodes(...)}} could (in the 'fire listeners' block) compute
{{oldLiveNodes xor newLiveNodes}} then loop over every {{DocCollection}} in
{{legacyCollectionStates}} and {{watchedCollectionStates}} and evaluated the
{{CollectionWatch}} instances for any collection with a
replica on one of hte affected nodes
# Deprecate/Redesign the {{CollectionStateWatcher}} API so that instead of
{{boolean onStateChanged(Set liveNodes, DocCollection collectionState);
}} we have \{{boolean onStateChanged(ZkStateReader stateReader, DocCollection
collectionState); }} ... impls that care about the live nodes can call
{{stateReader.updateLiveNodes()}} themselves (although that method would also
need to be changed to return {{Set}} instead of {{void}} but that seems
like a good idea in general.
...
All of these have their pros/cons in terms of human work to make the change vs
wasted CPU cost ... although I wonder if there could be a good hybrid between
#2 and #3 where we:
* add a new (simplified) versions of {{CollectionStateWatcher}} /
{{CollectionStatePredicate}} that are *only* told to know about the (updated)
{{DocCollection}}
** For now assume we'd call them {{DocCollectionWatcher}} &
{{DocCollectionPredicate}}
* switch as many instances as possible to this new API if they don't care
about live nodes
* refactor the existing {{ZkStateReader.registerCollectionStateWatcher(...)}}
impl to automatically create & register both a {{LiveNodesListener}} and
{{DocCollectionWatcher}} wrapper around any client specified
{{CollectionStateWatcher}}
?
> waitForState/registerCollectionStateWatcher can see stale liveNodes data due
> to (Zk) Watcher race condition
> ---
>
> Key: SOLR-13490
> URL: https://issues.apache.org/jira/browse/SOLR-13490
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Priority: Major
> Attachments: SOLR-13490.patch
>
>
> I was investigating some failures in
> {{TestCloudSearcherWarming.testRepFactor1LeaderStartup}} which lead me to the
> hunch that {{waitForState}} wasn't ensuring that the predicates registered
> would always be called if/when a node was shutdown.
> Digging into it a bit more, I found that the root cause seems to be the way
> the {{CollectionStateWatcher}} / {{CollectionStatePredicate}} APIs pass in
> *both* the {{DocCollection}}, and the "current" {{liveNodes}} - but are only
> _triggered_ by the {{StateWatcher}} on the {{state.json}} (which is used to
> rebuild the {{DocCollection}}) - when the {{CollectionStateWatcher}} /
> {{CollectionStatePredicate}} are called, they get the "fresh"
> {{DocCollection}} but they get the _cached_ {{ZkStateReader.liveNodes}}
> Meanwhile, the {{LiveNodeWatcher}} only calls {{refreshLiveNodes()}} only
> updates {{ZkStateReader.liveNodes}} and triggers any {{LiveNodesListener}} -
> it does *NOT* invoke any {{CollectionStateWatcher}} that may have replicas
> hosted on any of changed nodes.
> Since there is no garunteed order that Watchers will be triggered, this means
> there is a race condition where the following can happen...
> * client1 has a ZkStateReader with cached {{liveNodes=[N1, N2, N3]}}
> * client1 registers a {{CollectionStateWatcher}} "watcherZ" that cares if
> "replicaX" of collectionA is on a "down" node
> * client2 causes shutdown of node N1 which is hosting replicaX
> * client1's zkStateReader gets a WatchedEvent for state.json of collectionA
> ** DocCollection for collectionA is rebuilt
> ** watcherZ is fired w/cached {{liveNodes=[N1, N2, N3]}} and the new
> DocCollection
> *** watcherZ sees that replicaX is on N1, but thinks N1 is live
> *** watcherZ says "everything ok, not the event i was waiting for" and
> doesn't take any action
> * client1's zkStateReader gets a WatchedEvent for LIVE_NODES_ZKNODE
> ** zkStateReader.liveNodes is rebuilt
> ...at no point in this sequence (or after this) will watcherZ be notified
> fired with the updated liveNodes (unless/until another {{state.json}} change
> is made for collectionA.
>
> While this is definitely be problematic in _tests_ that deal with node
> lifecyle and use things like {{SolrCloudTestCase.waitForState(...,
> SolrCloudTestCase.clusterShape(...))}} to chec
[jira] [Created] (SOLR-13490) waitForState/registerCollectionStateWatcher can see stale liveNodes data due to (Zk) Watcher race condition
Hoss Man created SOLR-13490:
---
Summary: waitForState/registerCollectionStateWatcher can see stale
liveNodes data due to (Zk) Watcher race condition
Key: SOLR-13490
URL: https://issues.apache.org/jira/browse/SOLR-13490
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
I was investigating some failures in
{{TestCloudSearcherWarming.testRepFactor1LeaderStartup}} which lead me to the
hunch that {{waitForState}} wasn't ensuring that the predicates registered
would always be called if/when a node was shutdown.
Digging into it a bit more, I found that the root cause seems to be the way the
{{CollectionStateWatcher}} / {{CollectionStatePredicate}} APIs pass in *both*
the {{DocCollection}}, and the "current" {{liveNodes}} - but are only
_triggered_ by the {{StateWatcher}} on the {{state.json}} (which is used to
rebuild the {{DocCollection}}) - when the {{CollectionStateWatcher}} /
{{CollectionStatePredicate}} are called, they get the "fresh" {{DocCollection}}
but they get the _cached_ {{ZkStateReader.liveNodes}}
Meanwhile, the {{LiveNodeWatcher}} only calls {{refreshLiveNodes()}} only
updates {{ZkStateReader.liveNodes}} and triggers any {{LiveNodesListener}} - it
does *NOT* invoke any {{CollectionStateWatcher}} that may have replicas hosted
on any of changed nodes.
Since there is no garunteed order that Watchers will be triggered, this means
there is a race condition where the following can happen...
* client1 has a ZkStateReader with cached {{liveNodes=[N1, N2, N3]}}
* client1 registers a {{CollectionStateWatcher}} "watcherZ" that cares if
"replicaX" of collectionA is on a "down" node
* client2 causes shutdown of node N1 which is hosting replicaX
* client1's zkStateReader gets a WatchedEvent for state.json of collectionA
** DocCollection for collectionA is rebuilt
** watcherZ is fired w/cached {{liveNodes=[N1, N2, N3]}} and the new
DocCollection
*** watcherZ sees that replicaX is on N1, but thinks N1 is live
*** watcherZ says "everything ok, not the event i was waiting for" and doesn't
take any action
* client1's zkStateReader gets a WatchedEvent for LIVE_NODES_ZKNODE
** zkStateReader.liveNodes is rebuilt
...at no point in this sequence (or after this) will watcherZ be notified fired
with the updated liveNodes (unless/until another {{state.json}} change is made
for collectionA.
While this is definitely be problematic in _tests_ that deal with node lifecyle
and use things like {{SolrCloudTestCase.waitForState(...,
SolrCloudTestCase.clusterShape(...))}} to check for the expected
shards/replicas, a cursory search of how/where
{{ZkStateReader.waitForState(...)}} and
{{ZkStateReader.registerCollectionStateWatcher(...)}} are used in solr-core
suggests that could also lead to bad behavior in situations like reacting to
shard leader loss, waiting for all leaders of SYSTEM_COLL to come online for
upgrade, running PrepRecoveryOp, etc... (anywhere that liveNodes is used by the
watcher/predicate)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Linux (32bit/jdk1.8.0_201) - Build # 616 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/616/ Java: 32bit/jdk1.8.0_201 -server -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth Error Message: Error from server at http://127.0.0.1:35151/solr/authCollection: Error from server at null: Expected mime type application/octet-stream but got text/html. Error 401 require authentication HTTP ERROR 401 Problem accessing /solr/authCollection_shard3_replica_n5/select. Reason: require authenticationhttp://eclipse.org/jetty";>Powered by Jetty:// 9.4.14.v20181114 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:35151/solr/authCollection: Error from server at null: Expected mime type application/octet-stream but got text/html. Error 401 require authentication HTTP ERROR 401 Problem accessing /solr/authCollection_shard3_replica_n5/select. Reason: require authenticationhttp://eclipse.org/jetty";>Powered by Jetty:// 9.4.14.v20181114 at __randomizedtesting.SeedInfo.seed([306DAB4BC9405522:8C03DD596D13D658]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1068) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:837) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:769) at org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:290) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
Solr: Disable or modify explicit GCs?
I had a thought I wanted to run by others. I wondered if maybe we should add -XX:+ExplicitGCInvokesConcurrent or -XX:+DisableExplicitGC to Solr's default GC tuning. I checked master with 'git grep System.gc' and the explicit GC calls only show up in test code and the lucene benchmark, nothing production in either Lucene or Solr. I cannot say whether any of Solr's dependencies use it or not. In general I doubt those options would have any effect on a completely stock install ... but it might affect custom code that somebody adds. In that situation, protecting latency by either completely disabling the explicit GC or forcing it to run a concurrent collection seems like a good idea. But maybe it's not worth worrying about, I'm curious what others think. A question for Uwe ... would the following be an acceptable use/abuse of forbidden APIs in our build system? The check passes with it: https://apaste.info/LxIJ Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13489) Fix various issues impacting stability on Zookeeper expiration reconnect.
[ https://issues.apache.org/jira/browse/SOLR-13489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847924#comment-16847924 ] Mark Miller commented on SOLR-13489: This is one of the hardest to test areas and since it often happens in less than ideal conditions it's also important to test reconnect under many different (possibly repeating) failure cases. This area is a bit of our soft under-shell, though developers have made many fixes and improvements over the years. This stuff works a lot more often than it used to in master. I have a few more of those fixes and improvements. > Fix various issues impacting stability on Zookeeper expiration reconnect. > - > > Key: SOLR-13489 > URL: https://issues.apache.org/jira/browse/SOLR-13489 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12562) Clean up RealTimeGetComponent.toSolrDoc
[ https://issues.apache.org/jira/browse/SOLR-12562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847883#comment-16847883 ] Erick Erickson commented on SOLR-12562: --- I did just check and TestRealTimeGet exercises all the code paths that have been changed _except_ the one where the SchemaField is not found, which is what we expect. That code path logs a warning FWIW. If I force the schema field to be null, then the old code fails too. > Clean up RealTimeGetComponent.toSolrDoc > --- > > Key: SOLR-12562 > URL: https://issues.apache.org/jira/browse/SOLR-12562 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-12562.patch, SOLR-12562.patch > > > This code looks really redundant so we should remove one. The one in > RealTimeGet is the only used locally so my vote is to remove that one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk-9) - Build # 148 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/148/ Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.security.AuditLoggerIntegrationTest.testAsync Error Message: expected:<3> but was:<2> Stack Trace: java.lang.AssertionError: expected:<3> but was:<2> at __randomizedtesting.SeedInfo.seed([28EB3DF8148C74D8:57F334313BCA1B23]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:631) at org.apache.solr.security.AuditLoggerIntegrationTest.assertThreeAdminEvents(AuditLoggerIntegrationTest.java:253) at org.apache.solr.security.AuditLoggerIntegrationTest.testAsync(AuditLoggerIntegrationTest.java:109) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) Build Log: [...truncated 15521 lines...] [junit4] Suite: org.apache.solr.securi
[jira] [Created] (LUCENE-8813) testIndexTooManyDocs fails
Nhat Nguyen created LUCENE-8813:
---
Summary: testIndexTooManyDocs fails
Key: LUCENE-8813
URL: https://issues.apache.org/jira/browse/LUCENE-8813
Project: Lucene - Core
Issue Type: Test
Components: core/index
Reporter: Nhat Nguyen
testIndexTooManyDocs fails on [Elastic
CI|https://elasticsearch-ci.elastic.co/job/apache+lucene-solr+branch_8x/6402/console].
This failure does not reproduce locally for me.
{noformat}
[junit4] Suite: org.apache.lucene.index.TestIndexTooManyDocs
[junit4] 2> KTN 23, 2019 4:09:37 PM
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
uncaughtException
[junit4] 2> WARNING: Uncaught exception in thread:
Thread[Thread-612,5,TGRP-TestIndexTooManyDocs]
[junit4] 2> java.lang.AssertionError: only modifications from the current
flushing queue are permitted while doing a full flush
[junit4] 2> at __randomizedtesting.SeedInfo.seed([1F16B1DA7056AA52]:0)
[junit4] 2> at
org.apache.lucene.index.DocumentsWriter.assertTicketQueueModification(DocumentsWriter.java:683)
[junit4] 2> at
org.apache.lucene.index.DocumentsWriter.applyAllDeletes(DocumentsWriter.java:187)
[junit4] 2> at
org.apache.lucene.index.DocumentsWriter.postUpdate(DocumentsWriter.java:411)
[junit4] 2> at
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:514)
[junit4] 2> at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1594)
[junit4] 2> at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1586)
[junit4] 2> at
org.apache.lucene.index.TestIndexTooManyDocs.lambda$testIndexTooManyDocs$0(TestIndexTooManyDocs.java:70)
[junit4] 2> at java.base/java.lang.Thread.run(Thread.java:834)
[junit4] 2>
[junit4] 2> KTN 23, 2019 6:09:36 PM
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
[junit4] 2> WARNING: Suite execution timed out:
org.apache.lucene.index.TestIndexTooManyDocs
[junit4] 2>1) Thread[id=669,
name=SUITE-TestIndexTooManyDocs-seed#[1F16B1DA7056AA52], state=RUNNABLE,
group=TGRP-TestIndexTooManyDocs]
[junit4] 2> at
java.base/java.lang.Thread.getStackTrace(Thread.java:1606)
[junit4] 2> at
com.carrotsearch.randomizedtesting.ThreadLeakControl$4.run(ThreadLeakControl.java:696)
[junit4] 2> at
com.carrotsearch.randomizedtesting.ThreadLeakControl$4.run(ThreadLeakControl.java:693)
[junit4] 2> at
java.base/java.security.AccessController.doPrivileged(Native Method)
[junit4] 2> at
com.carrotsearch.randomizedtesting.ThreadLeakControl.getStackTrace(ThreadLeakControl.java:693)
[junit4] 2> at
com.carrotsearch.randomizedtesting.ThreadLeakControl.getThreadsWithTraces(ThreadLeakControl.java:709)
[junit4] 2> at
com.carrotsearch.randomizedtesting.ThreadLeakControl.formatThreadStacksFull(ThreadLeakControl.java:689)
[junit4] 2> at
com.carrotsearch.randomizedtesting.ThreadLeakControl.access$1000(ThreadLeakControl.java:65)
[junit4] 2> at
com.carrotsearch.randomizedtesting.ThreadLeakControl$2.evaluate(ThreadLeakControl.java:415)
[junit4] 2> at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:708)
[junit4] 2> at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$200(RandomizedRunner.java:138)
[junit4] 2> at
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:629)
[junit4] 2>2) Thread[id=671, name=Thread-606, state=BLOCKED,
group=TGRP-TestIndexTooManyDocs]
[junit4] 2> at
app//org.apache.lucene.index.IndexWriter.nrtIsCurrent(IndexWriter.java:4945)
[junit4] 2> at
app//org.apache.lucene.index.StandardDirectoryReader.doOpenFromWriter(StandardDirectoryReader.java:293)
[junit4] 2> at
app//org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:272)
[junit4] 2> at
app//org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:262)
[junit4] 2> at
app//org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:165)
[junit4] 2> at
app//org.apache.lucene.index.TestIndexTooManyDocs.lambda$testIndexTooManyDocs$1(TestIndexTooManyDocs.java:86)
[junit4] 2> at
app//org.apache.lucene.index.TestIndexTooManyDocs$$Lambda$342/0x0001002bc440.run(Unknown
Source)
[junit4] 2> at
java.base@11.0.2/java.lang.Thread.run(Thread.java:834)
[junit4] 2>3) Thread[id=1, name=main, state=WAITING, group=main]
[junit4] 2> at java.base@11.0.2/java.lang.Object.wait(Native
Method)
[junit4] 2> at
java.base@11.0.2/java.lang.Thread.join(Thread.java:1305)
[junit4]
[jira] [Created] (SOLR-13489) Fix various issues impacting stability on Zookeeper expiration reconnect.
Mark Miller created SOLR-13489: -- Summary: Fix various issues impacting stability on Zookeeper expiration reconnect. Key: SOLR-13489 URL: https://issues.apache.org/jira/browse/SOLR-13489 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Mark Miller Assignee: Mark Miller -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1344 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1344/ No tests ran. Build Log: [...truncated 23473 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2566 links (2099 relative) to 3378 anchors in 253 files [echo] Validated Links & Anchors via: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked [untar] Expanding: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-9.0.0.tgz into /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disal
[jira] [Commented] (SOLR-12562) Clean up RealTimeGetComponent.toSolrDoc
[ https://issues.apache.org/jira/browse/SOLR-12562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847808#comment-16847808 ] Erick Erickson commented on SOLR-12562: --- Updated patch, if all goes well I'll commit this weekend. It incorporates (I think) your suggestions [~dsmiley]. I looked at TestRealTimeGet and it looks like it incorporates all of the variants, so this feels pretty solid. Precommit and all tests pass. I'll enable patch review too. > Clean up RealTimeGetComponent.toSolrDoc > --- > > Key: SOLR-12562 > URL: https://issues.apache.org/jira/browse/SOLR-12562 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-12562.patch, SOLR-12562.patch > > > This code looks really redundant so we should remove one. The one in > RealTimeGet is the only used locally so my vote is to remove that one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12562) Clean up RealTimeGetComponent.toSolrDoc
[ https://issues.apache.org/jira/browse/SOLR-12562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-12562: -- Attachment: SOLR-12562.patch > Clean up RealTimeGetComponent.toSolrDoc > --- > > Key: SOLR-12562 > URL: https://issues.apache.org/jira/browse/SOLR-12562 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-12562.patch, SOLR-12562.patch > > > This code looks really redundant so we should remove one. The one in > RealTimeGet is the only used locally so my vote is to remove that one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8808) Introduce Optional Cap on Number Of Threads Per Query
[ https://issues.apache.org/jira/browse/LUCENE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847742#comment-16847742 ] Atri Sharma commented on LUCENE-8808: - [~jpountz] Essentially, no. My proposal is basically to have a last level limit to ensure that no single query overloads the entire system i.e. a query does not decide to use 72 threads on a 32 core machine. We could potentially not even have a configurable cap, and always set it to number of cores. I am not married to this approach, so happy to hear ideas. > Introduce Optional Cap on Number Of Threads Per Query > - > > Key: LUCENE-8808 > URL: https://issues.apache.org/jira/browse/LUCENE-8808 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Atri Sharma >Priority: Major > > With the presence of https://issues.apache.org/jira/browse/LUCENE-8757 , a > natural progression is to allow advanced users to specify a cap on the number > of threads a query can use. This is especially useful for long polled > IndexSearcher instances, where the same instance is used to fire queries for > multiple runs and there are multiple concurrent IndexSearcher instances on > the same node. > > This will be an optional parameter and local only to the IndexSearcher > instance being configured during construction. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.1-Linux (64bit/jdk-12) - Build # 337 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Linux/337/ Java: 64bit/jdk-12 -XX:-UseCompressedOops -XX:+UseSerialGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.update.TestInPlaceUpdatesDistrib Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([2019C1B1CC53C4F6]:0) FAILED: junit.framework.TestSuite.org.apache.solr.update.TestInPlaceUpdatesDistrib Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([2019C1B1CC53C4F6]:0) FAILED: org.apache.solr.update.TestInPlaceUpdatesDistrib.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([2019C1B1CC53C4F6]:0) FAILED: org.apache.solr.update.TestInPlaceUpdatesDistrib.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([2019C1B1CC53C4F6]:0) Build Log: [...truncated 15977 lines...] [junit4] Suite: org.apache.solr.update.TestInPlaceUpdatesDistrib [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-8.1-Linux/solr/build/solr-core/test/J2/temp/solr.update.TestInPlaceUpdatesDistrib_2019C1B1CC53C4F6-001/init-core-data-001 [junit4] 2> 1960353 INFO (SUITE-TestInPlaceUpdatesDistrib-seed#[2019C1B1CC53C4F6]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2> 1960354 INFO (SUITE-TestInPlaceUpdatesDistrib-seed#[2019C1B1CC53C4F6]-worker) [] o.a.s.c.SolrResourceLoader [null] Added 2 libs to classloader, from paths: [/home/jenkins/workspace/Lucene-Solr-8.1-Linux/solr/core/src/test-files/solr/collection1/lib, /home/jenkins/workspace/Lucene-Solr-8.1-Linux/solr/core/src/test-files/solr/collection1/lib/classes] [junit4] 2> 1960362 INFO (SUITE-TestInPlaceUpdatesDistrib-seed#[2019C1B1CC53C4F6]-worker) [] o.a.s.c.SolrConfig Using Lucene MatchVersion: 8.1.1 [junit4] 2> 1960371 INFO (SUITE-TestInPlaceUpdatesDistrib-seed#[2019C1B1CC53C4F6]-worker) [] o.a.s.s.IndexSchema [null] Schema name=inplace-updates [junit4] 2> 1960373 INFO (SUITE-TestInPlaceUpdatesDistrib-seed#[2019C1B1CC53C4F6]-worker) [] o.a.s.s.IndexSchema Loaded schema inplace-updates/1.6 with uniqueid field id [junit4] 2> 1960485 INFO (SUITE-TestInPlaceUpdatesDistrib-seed#[2019C1B1CC53C4F6]-worker) [] o.a.s.h.c.HttpShardHandlerFactory Host whitelist initialized: WhitelistHostChecker [whitelistHosts=null, whitelistHostCheckingEnabled=false] [junit4] 2> 1960487 WARN (SUITE-TestInPlaceUpdatesDistrib-seed#[2019C1B1CC53C4F6]-worker) [] o.e.j.u.s.S.config No Client EndPointIdentificationAlgorithm configured for SslContextFactory@3ec2af79[provider=null,keyStore=null,trustStore=null] [junit4] 2> 1960488 WARN (SUITE-TestInPlaceUpdatesDistrib-seed#[2019C1B1CC53C4F6]-worker) [] o.e.j.u.s.S.config No Client EndPointIdentificationAlgorithm configured for SslContextFactory@dbfd85e[provider=null,keyStore=null,trustStore=null] [junit4] 2> 1960496 INFO (SUITE-TestInPlaceUpdatesDistrib-seed#[2019C1B1CC53C4F6]-worker) [] o.a.s.c.TransientSolrCoreCacheDefault Allocating transient cache for 2147483647 transient cores [junit4] 2> 1960496 INFO (SUITE-TestInPlaceUpdatesDistrib-seed#[2019C1B1CC53C4F6]-worker) [] o.a.s.h.a.MetricsHistoryHandler No .system collection, keeping metrics history in memory. [junit4] 2> 1960504 INFO (SUITE-TestInPlaceUpdatesDistrib-seed#[2019C1B1CC53C4F6]-worker) [] o.a.s.m.r.SolrJmxReporter JMX monitoring for 'solr.node' (registry 'solr.node') enabled at server: com.sun.jmx.mbeanserver.JmxMBeanServer@1afdbaf1 [junit4] 2> 1960510 INFO (SUITE-TestInPlaceUpdatesDistrib-seed#[2019C1B1CC53C4F6]-worker) [] o.a.s.m.r.SolrJmxReporter JMX monitoring for 'solr.jvm' (registry 'solr.jvm') enabled at server: com.sun.jmx.mbeanserver.JmxMBeanServer@1afdbaf1 [junit4] 2> 1960510 INFO (SUITE-TestInPlaceUpdatesDistrib-seed#[2019C1B1CC53C4F6]-worker) [] o.a.s.m.r.SolrJmxReporter JMX monitoring for 'solr.jetty' (registry 'solr.jetty') enabled at server: com.sun.jmx.mbeanserver.JmxMBeanServer@1afdbaf1 [junit4] 2> 1960511 INFO (coreLoadExecutor-13612-thread-1) [ x:collection1] o.a.s.c.SolrResourceLoader [null] Added 2 libs to classloader, from paths: [/home/jenkins/workspace/Lucene-Solr-8.1-Linux/solr/core/src/test-files/solr/collection1/lib, /home/jenkins/workspace/Lucene-Solr-8.1-Linux/solr/core/src/test-files/solr/collection1/lib/classes] [junit4] 2> 1960521 INFO (coreLoadExecutor-13612-thread-1) [ x:collect
[jira] [Commented] (LUCENE-8808) Introduce Optional Cap on Number Of Threads Per Query
[ https://issues.apache.org/jira/browse/LUCENE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847715#comment-16847715 ] Adrien Grand commented on LUCENE-8808: -- Sorry I don't. This is a hard problem. Your approach makes the assumption that it's ok to make slow queries slower if that helps fast queries remain fast, which I don't think would be the right assumption for most users? > Introduce Optional Cap on Number Of Threads Per Query > - > > Key: LUCENE-8808 > URL: https://issues.apache.org/jira/browse/LUCENE-8808 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Atri Sharma >Priority: Major > > With the presence of https://issues.apache.org/jira/browse/LUCENE-8757 , a > natural progression is to allow advanced users to specify a cap on the number > of threads a query can use. This is especially useful for long polled > IndexSearcher instances, where the same instance is used to fire queries for > multiple runs and there are multiple concurrent IndexSearcher instances on > the same node. > > This will be an optional parameter and local only to the IndexSearcher > instance being configured during construction. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8784) Nori(Korean) tokenizer removes the decimal point.
[ https://issues.apache.org/jira/browse/LUCENE-8784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847706#comment-16847706 ] Namgyu Kim commented on LUCENE-8784: Thanks, [~jim.ferenczi]! :D If there is something wrong, I would appreciate it if you let me know. > Nori(Korean) tokenizer removes the decimal point. > --- > > Key: LUCENE-8784 > URL: https://issues.apache.org/jira/browse/LUCENE-8784 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Munkyu Im >Priority: Major > Attachments: LUCENE-8784.patch, LUCENE-8784.patch, LUCENE-8784.patch, > LUCENE-8784.patch > > > This is the same issue that I mentioned to > [https://github.com/elastic/elasticsearch/issues/41401#event-2293189367] > unlike standard analyzer, nori analyzer removes the decimal point. > nori tokenizer removes "." character by default. > In this case, it is difficult to index the keywords including the decimal > point. > It would be nice if there had the option whether add a decimal point or not. > Like Japanese tokenizer does, Nori need an option to preserve decimal point. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8784) Nori(Korean) tokenizer removes the decimal point.
[ https://issues.apache.org/jira/browse/LUCENE-8784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847695#comment-16847695 ] Jim Ferenczi commented on LUCENE-8784: -- The last patch for this issue looks good to me. I'll test locally and merge if all tests pass. Thanks for opening LUCENE-8812, I'll take a look when this issue gets merged. > Nori(Korean) tokenizer removes the decimal point. > --- > > Key: LUCENE-8784 > URL: https://issues.apache.org/jira/browse/LUCENE-8784 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Munkyu Im >Priority: Major > Attachments: LUCENE-8784.patch, LUCENE-8784.patch, LUCENE-8784.patch, > LUCENE-8784.patch > > > This is the same issue that I mentioned to > [https://github.com/elastic/elasticsearch/issues/41401#event-2293189367] > unlike standard analyzer, nori analyzer removes the decimal point. > nori tokenizer removes "." character by default. > In this case, it is difficult to index the keywords including the decimal > point. > It would be nice if there had the option whether add a decimal point or not. > Like Japanese tokenizer does, Nori need an option to preserve decimal point. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-8.1 - Build # 36 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.1/36/
1 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest.testSimple
Error Message:
Waiting for collection testSimple2 Timeout waiting to see state for
collection=testSimple2
:DocCollection(testSimple2//collections/testSimple2/state.json/26)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{ "shard1":{
"range":"8000-", "state":"active", "replicas":{
"core_node2":{
"dataDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node2/data/",
"base_url":"http://127.0.0.1:39351/solr";,
"node_name":"127.0.0.1:39351_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node2/data/tlog",
"core":"testSimple2_shard1_replica_n1",
"shared_storage":"true", "state":"down"}, "core_node5":{
"dataDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node5/data/",
"base_url":"http://127.0.0.1:36805/solr";,
"node_name":"127.0.0.1:36805_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node5/data/tlog",
"core":"testSimple2_shard1_replica_n3",
"shared_storage":"true", "state":"active",
"leader":"true"}}}, "shard2":{ "range":"0-7fff",
"state":"active", "replicas":{ "core_node6":{
"dataDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node6/data/",
"base_url":"http://127.0.0.1:39351/solr";,
"node_name":"127.0.0.1:39351_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node6/data/tlog",
"core":"testSimple2_shard2_replica_n4",
"shared_storage":"true", "state":"down"}, "core_node8":{
"dataDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node8/data/",
"base_url":"http://127.0.0.1:36805/solr";,
"node_name":"127.0.0.1:36805_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node8/data/tlog",
"core":"testSimple2_shard2_replica_n7",
"shared_storage":"true", "state":"active",
"leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"2", "autoAddReplicas":"true", "nrtReplicas":"2",
"tlogReplicas":"0"} Live Nodes: [127.0.0.1:36805_solr, 127.0.0.1:39964_solr]
Last available state:
DocCollection(testSimple2//collections/testSimple2/state.json/26)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{ "shard1":{
"range":"8000-", "state":"active", "replicas":{
"core_node2":{
"dataDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node2/data/",
"base_url":"http://127.0.0.1:39351/solr";,
"node_name":"127.0.0.1:39351_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node2/data/tlog",
"core":"testSimple2_shard1_replica_n1",
"shared_storage":"true", "state":"down"}, "core_node5":{
"dataDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node5/data/",
"base_url":"http://127.0.0.1:36805/solr";,
"node_name":"127.0.0.1:36805_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node5/data/tlog",
"core":"testSimple2_shard1_replica_n3",
"shared_storage":"true", "state":"active",
"leader":"true"}}}, "shard2":{ "range":"0-7fff",
"state":"active", "replicas":{ "core_node6":{
"dataDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node6/data/",
"base_url":"http://127.0.0.1:39351/solr";,
"node_name":"127.0.0.1:39351_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node6/data/tlog",
"core":"testSimple2_shard2_replica_n4",
"shared_storage":"true", "state":"down"}, "core_node8":{
"dataDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node8/data/",
"base_url":"http://127.0.0.1:36805/solr";,
"node_name":"127.0.0.1:36805_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:44808/solr_hdfs_home/testSimple2/core_node8/data/tlo
[jira] [Commented] (LUCENE-8784) Nori(Korean) tokenizer removes the decimal point.
[ https://issues.apache.org/jira/browse/LUCENE-8784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847659#comment-16847659 ] Namgyu Kim commented on LUCENE-8784: It's a good idea :D I linked LUCENE-8784(discardPunctuation) with LUCENE-8812(KoreanNumberFilter). (Apply LUCENE-8784 *first* and then LUCENE-8812) Your suggestion made this issue cleaner. In LUCENE-8784, I did not change the existing TCs and just added new TCs for discardPunctuation. (remain the current constructor to provide an existing API) > Nori(Korean) tokenizer removes the decimal point. > --- > > Key: LUCENE-8784 > URL: https://issues.apache.org/jira/browse/LUCENE-8784 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Munkyu Im >Priority: Major > Attachments: LUCENE-8784.patch, LUCENE-8784.patch, LUCENE-8784.patch, > LUCENE-8784.patch > > > This is the same issue that I mentioned to > [https://github.com/elastic/elasticsearch/issues/41401#event-2293189367] > unlike standard analyzer, nori analyzer removes the decimal point. > nori tokenizer removes "." character by default. > In this case, it is difficult to index the keywords including the decimal > point. > It would be nice if there had the option whether add a decimal point or not. > Like Japanese tokenizer does, Nori need an option to preserve decimal point. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta edited a comment on issue #654: LUCENE-8778: Define analyzer SPI names as static final fields and document the names
mocobeta edited a comment on issue #654: LUCENE-8778: Define analyzer SPI names as static final fields and document the names URL: https://github.com/apache/lucene-solr/pull/654#issuecomment-495680743 It is not related to this issue, but I'd like to add this line to the gitignore file. I occasionally see the python bytecode cache directory is created under `dev-tools/scripts`, though I've not figured out which ant task generates this... ``` diff --git a/.gitignore b/.gitignore index 4b947436dc..674ddd198f 100644 --- a/.gitignore +++ b/.gitignore @@ -26,3 +26,4 @@ pom.xml /nbproject /nb-build .pydevproject +__pycache__ ``` The entry above works for python3 only, because python3 creates the `__pycache__` directory and writes all bytecode files to there. Or, I usually add those lines to .gitignore of my python projects (this works for both of python2 and python3). ``` *.pyc *.pyo ``` Alternatively, I think we can completely disable the cache (don't write .pyc or .pyo files) by `-B` option. https://stackoverflow.com/questions/16869024/what-is-pycache This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta edited a comment on issue #654: LUCENE-8778: Define analyzer SPI names as static final fields and document the names
mocobeta edited a comment on issue #654: LUCENE-8778: Define analyzer SPI names as static final fields and document the names URL: https://github.com/apache/lucene-solr/pull/654#issuecomment-495680743 It is not related to this issue, but I'd like to add this line to the gitignore file. I occasionally see the python bytecode cache directory is created under `dev-tools/scripts`, though I've not figured out which ant task generates this... ``` diff --git a/.gitignore b/.gitignore index 4b947436dc..674ddd198f 100644 --- a/.gitignore +++ b/.gitignore @@ -26,3 +26,4 @@ pom.xml /nbproject /nb-build .pydevproject +__pycache__ ``` The entry above works for python3 only, because python3 creates the `__pycache__` directory and writes all bytecode files to there. Or, I usually add those lines to my python projects (this works for both of python2 and python3). ``` *.pyc *.pyo ``` Alternatively, I think we can completely disable the cache (don't write .pyc or .pyo files) by `-B` option. https://stackoverflow.com/questions/16869024/what-is-pycache This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta edited a comment on issue #654: LUCENE-8778: Define analyzer SPI names as static final fields and document the names
mocobeta edited a comment on issue #654: LUCENE-8778: Define analyzer SPI names as static final fields and document the names URL: https://github.com/apache/lucene-solr/pull/654#issuecomment-495680743 It is not related to this issue, but I'd like to add this line to the gitignore file. I occasionally see the python bytecode cache directory is created under `dev-tools/scripts`, though I've not figured out which ant task generates this... ``` diff --git a/.gitignore b/.gitignore index 4b947436dc..674ddd198f 100644 --- a/.gitignore +++ b/.gitignore @@ -26,3 +26,4 @@ pom.xml /nbproject /nb-build .pydevproject +__pycache__ ``` Or, I usually add those lines to my python projects (this works for both of python2 and python3) ``` *.pyc *.pyo ``` Alternatively, I think we can completely disable the cache (don't write .pyc or .pyo files) by `-B` option. https://stackoverflow.com/questions/16869024/what-is-pycache This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8812) add KoreanNumberFilter to Nori(Korean) Analyzer
[ https://issues.apache.org/jira/browse/LUCENE-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Namgyu Kim updated LUCENE-8812: --- Attachment: LUCENE-8812.patch > add KoreanNumberFilter to Nori(Korean) Analyzer > --- > > Key: LUCENE-8812 > URL: https://issues.apache.org/jira/browse/LUCENE-8812 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Namgyu Kim >Priority: Major > Attachments: LUCENE-8812.patch > > > This is a follow-up issue to LUCENE-8784. > The KoreanNumberFilter is a TokenFilter that normalizes Korean numbers to > regular Arabic decimal numbers in half-width characters. > Logic is similar to JapaneseNumberFilter. > It should be able to cover the following test cases. > 1) Korean Word to Number > 십만이천오백 => 102500 > 2) 1 character conversion > 일영영영 => 1000 > 3) Decimal Point Calculation > 3.2천 => 3200 > 4) Comma between three digits > 4,647.0010 => 4647.001 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta commented on issue #654: LUCENE-8778: Define analyzer SPI names as static final fields and document the names
mocobeta commented on issue #654: LUCENE-8778: Define analyzer SPI names as static final fields and document the names URL: https://github.com/apache/lucene-solr/pull/654#issuecomment-495680743 It is not related to this issue, but I'd like to add this line to the gitignore file. I occasionally see the python bytecode cache directory is created under `dev-tools/scripts`, though I've not figured out which ant task generates this... ``` diff --git a/.gitignore b/.gitignore index 4b947436dc..674ddd198f 100644 --- a/.gitignore +++ b/.gitignore @@ -26,3 +26,4 @@ pom.xml /nbproject /nb-build .pydevproject +__pycache__ ``` Alternatively, I think we can completely disable the cache (don't write .pyc or .pyo files) by `-B` option. https://stackoverflow.com/questions/16869024/what-is-pycache This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8784) Nori(Korean) tokenizer removes the decimal point.
[ https://issues.apache.org/jira/browse/LUCENE-8784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Namgyu Kim updated LUCENE-8784: --- Attachment: LUCENE-8784.patch > Nori(Korean) tokenizer removes the decimal point. > --- > > Key: LUCENE-8784 > URL: https://issues.apache.org/jira/browse/LUCENE-8784 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Munkyu Im >Priority: Major > Attachments: LUCENE-8784.patch, LUCENE-8784.patch, LUCENE-8784.patch, > LUCENE-8784.patch > > > This is the same issue that I mentioned to > [https://github.com/elastic/elasticsearch/issues/41401#event-2293189367] > unlike standard analyzer, nori analyzer removes the decimal point. > nori tokenizer removes "." character by default. > In this case, it is difficult to index the keywords including the decimal > point. > It would be nice if there had the option whether add a decimal point or not. > Like Japanese tokenizer does, Nori need an option to preserve decimal point. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8812) add KoreanNumberFilter to Nori(Korean) Analyzer
Namgyu Kim created LUCENE-8812: -- Summary: add KoreanNumberFilter to Nori(Korean) Analyzer Key: LUCENE-8812 URL: https://issues.apache.org/jira/browse/LUCENE-8812 Project: Lucene - Core Issue Type: New Feature Reporter: Namgyu Kim This is a follow-up issue to LUCENE-8784. The KoreanNumberFilter is a TokenFilter that normalizes Korean numbers to regular Arabic decimal numbers in half-width characters. Logic is similar to JapaneseNumberFilter. It should be able to cover the following test cases. 1) Korean Word to Number 십만이천오백 => 102500 2) 1 character conversion 일영영영 => 1000 3) Decimal Point Calculation 3.2천 => 3200 4) Comma between three digits 4,647.0010 => 4647.001 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 3298 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3298/ [...truncated 29 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.1/35/consoleText [repro] Revision: fcbe46c28cef11bc058779afba09521de1b19bef [repro] Ant options: -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.1/test-data/enwiki.random.lines.txt [repro] Repro line: ant test -Dtestcase=HdfsAutoAddReplicasIntegrationTest -Dtests.method=testSimple -Dtests.seed=E3F9F0F1B9F1A8E0 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.1/test-data/enwiki.random.lines.txt -Dtests.locale=sr-ME -Dtests.timezone=Asia/Istanbul -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 46060d88a2a80794a95e6899e532c7a7da9c4dfb [repro] git fetch [repro] git checkout fcbe46c28cef11bc058779afba09521de1b19bef [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] HdfsAutoAddReplicasIntegrationTest [repro] ant compile-test [...truncated 3576 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.HdfsAutoAddReplicasIntegrationTest" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.1/test-data/enwiki.random.lines.txt -Dtests.seed=E3F9F0F1B9F1A8E0 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.1/test-data/enwiki.random.lines.txt -Dtests.locale=sr-ME -Dtests.timezone=Asia/Istanbul -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 2686 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 1/5 failed: org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest [repro] git checkout 46060d88a2a80794a95e6899e532c7a7da9c4dfb [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 5 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 3349 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3349/
1 tests failed.
FAILED: org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI
Error Message:
{} expected:<2> but was:<0>
Stack Trace:
java.lang.AssertionError: {} expected:<2> but was:<0>
at
__randomizedtesting.SeedInfo.seed([C8BA959A61CAA7BA:D76D09B612C15EF1]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at
org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:293)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)
Build Log:
[...truncated 14045 lines...]
[junit4] Suite: org.apache.solr.cloud.AliasIntegrationTest
[junit4] 2> Creating dataDir:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build/solr-core/test/J0/temp/solr.cloud.AliasIntegrationTest_C8BA959A61CAA7BA-001/init-core-data-0
[jira] [Commented] (LUCENE-8778) Define analyzer SPI names as static final fields and document the names in Javadocs
[
https://issues.apache.org/jira/browse/LUCENE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847486#comment-16847486
]
Tomoko Uchida commented on LUCENE-8778:
---
Hi [~thetaphi],
I did a regression test and fixed incorrect SPI names (they had been mistakenly
copypateted in previous commits).
# List SPI names and their class names of all analysis components with master
branch. ([^ListAnalysisComponents.java])
# Make sure that all components can be looked up by (old) SPI names with my
branch (pull request). ([^TestSPINames.java])
Also I modified {{AnalysisSPILoader}} to preserve service names' letter casing.
Now documented SPI names are camel cased, so it would be better that we
preserve original names as is. Instead of lowercasing when registering the
names, we can perform case-insensitive lookup. Because the service map is
small, I guess the performance degredation will not matter much in this case
(I'm not quite sure, but there might be better ways?).
([diff|https://github.com/apache/lucene-solr/pull/654/commits/fc903379b0a53b690adf1c1ca5843b92444895ec])
This branch passed ant test & precommit.
> Define analyzer SPI names as static final fields and document the names in
> Javadocs
> ---
>
> Key: LUCENE-8778
> URL: https://issues.apache.org/jira/browse/LUCENE-8778
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Priority: Minor
> Attachments: ListAnalysisComponents.java, SPINamesGenerator.java,
> Screenshot from 2019-04-26 02-17-48.png, TestSPINames.java
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Each built-in analysis component (factory of tokenizer / char filter / token
> filter) has a SPI name but currently this is not documented anywhere.
> The goals of this issue:
> * Define SPI names as static final field for each analysis component so that
> users can get the component by name (via {{NAME}} static field.) This also
> provides compile time safety.
> * Officially document the SPI names in Javadocs.
> * Add proper source validation rules to ant {{validate-source-patterns}}
> target so that we can make sure that all analysis components have correct
> field definitions and documentation
> and,
> * Lookup SPI names on the new {{NAME}} fields. Instead deriving those from
> class names.
> (Just for quick reference) we now have:
> * *19* Tokenizers ({{TokenizerFactory.availableTokenizers()}})
> * *6* CharFilters ({{CharFilterFactory.availableCharFilters()}})
> * *118* TokenFilters ({{TokenFilterFactory.availableTokenFilters()}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8778) Define analyzer SPI names as static final fields and document the names in Javadocs
[
https://issues.apache.org/jira/browse/LUCENE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-8778:
--
Attachment: TestSPINames.java
> Define analyzer SPI names as static final fields and document the names in
> Javadocs
> ---
>
> Key: LUCENE-8778
> URL: https://issues.apache.org/jira/browse/LUCENE-8778
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Priority: Minor
> Attachments: ListAnalysisComponents.java, SPINamesGenerator.java,
> Screenshot from 2019-04-26 02-17-48.png, TestSPINames.java
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Each built-in analysis component (factory of tokenizer / char filter / token
> filter) has a SPI name but currently this is not documented anywhere.
> The goals of this issue:
> * Define SPI names as static final field for each analysis component so that
> users can get the component by name (via {{NAME}} static field.) This also
> provides compile time safety.
> * Officially document the SPI names in Javadocs.
> * Add proper source validation rules to ant {{validate-source-patterns}}
> target so that we can make sure that all analysis components have correct
> field definitions and documentation
> and,
> * Lookup SPI names on the new {{NAME}} fields. Instead deriving those from
> class names.
> (Just for quick reference) we now have:
> * *19* Tokenizers ({{TokenizerFactory.availableTokenizers()}})
> * *6* CharFilters ({{CharFilterFactory.availableCharFilters()}})
> * *118* TokenFilters ({{TokenFilterFactory.availableTokenFilters()}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 141 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/141/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.lucene.analysis.cjk.TestCJKAnalyzer.testSingleChar2 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([41B8021CE9DDF045]:0) FAILED: junit.framework.TestSuite.org.apache.lucene.analysis.cjk.TestCJKAnalyzer Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([41B8021CE9DDF045]:0) Build Log: [...truncated 4243 lines...] [junit4] Suite: org.apache.lucene.analysis.cjk.TestCJKAnalyzer [junit4] 2> ??? 23, 2019 9:17:53 ? com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate [junit4] 2> WARNING: Suite execution timed out: org.apache.lucene.analysis.cjk.TestCJKAnalyzer [junit4] 2>1) Thread[id=1, name=main, state=WAITING, group=main] [junit4] 2> at java.lang.Object.wait(Native Method) [junit4] 2> at java.lang.Thread.join(Thread.java:1252) [junit4] 2> at java.lang.Thread.join(Thread.java:1326) [junit4] 2> at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:639) [junit4] 2> at com.carrotsearch.randomizedtesting.RandomizedRunner.run(RandomizedRunner.java:496) [junit4] 2> at com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:269) [junit4] 2> at com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:394) [junit4] 2> at com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13) [junit4] 2>2) Thread[id=286, name=TEST-TestCJKAnalyzer.testSingleChar2-seed#[41B8021CE9DDF045], state=BLOCKED, group=TGRP-TestCJKAnalyzer] [junit4] 2> at com.carrotsearch.randomizedtesting.ThreadLeakControl$SubNotifier.fireTestFinished(ThreadLeakControl.java:200) [junit4] 2> at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:956) [junit4] 2> at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) [junit4] 2> at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) [junit4] 2> at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) [junit4] 2> at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) [junit4] 2> at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) [junit4] 2> at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) [junit4] 2> at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) [junit4] 2> at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) [junit4] 2> at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) [junit4] 2> at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) [junit4] 2> at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) [junit4] 2> at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) [junit4] 2> at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) [junit4] 2> at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) [junit4] 2> at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) [junit4] 2> at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) [junit4] 2> at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) [junit4] 2> at java.lang.Thread.run(Thread.java:748) [junit4] 2>3) Thread[id=285, name=SUITE-TestCJKAnalyzer-seed#[41B8021CE9DDF045], state=RUNNABLE, group=TGRP-TestCJKAnalyzer] [junit4] 2> at java.lang.Thread.getStackTrace(Thread.java:1559) [junit4] 2> at com.carrotsearch.randomizedtesting.ThreadLeakControl$4.run(ThreadLeakControl.java:696) [junit4] 2> at com.carrotsearch.randomizedtesting.ThreadLeakControl$4.run(ThreadLeakControl.java:693) [junit4] 2> at java.security.AccessController.
[GitHub] [lucene-solr] CaoManhDat commented on a change in pull request #685: SOLR-13434: OpenTracing support for Solr
CaoManhDat commented on a change in pull request #685: SOLR-13434: OpenTracing support for Solr URL: https://github.com/apache/lucene-solr/pull/685#discussion_r287306201 ## File path: solr/contrib/jaegertracer-configurator/src/java/org/apache/solr/JaegerTracerConfigurator.java ## @@ -0,0 +1,91 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.solr; Review comment: thank guys, fixed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8788) Order LeafReaderContexts by Estimated Number Of Hits
[
https://issues.apache.org/jira/browse/LUCENE-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847455#comment-16847455
]
Jim Ferenczi commented on LUCENE-8788:
--
{quote}
I like the idea [~jim.ferenczi] proposed. I can open a Jira for that and work
on a patch for it as well, unless Jim wants to do it himself?
{quote}
Something is needed for the search side and this issue is the right place to
add such functionalities. I wonder if we need an issue for the merge side
though since it's already possible to change the order of segments in a custom
FilterMergePolicy. I tried to do it in a POC and the change is trivial so I am
not sure that we need to do anything in core.
> Order LeafReaderContexts by Estimated Number Of Hits
>
>
> Key: LUCENE-8788
> URL: https://issues.apache.org/jira/browse/LUCENE-8788
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> We offer no guarantee on the order in which an IndexSearcher will look at
> segments during a search operation. This can be improved for use cases where
> an engine using Lucene invokes early termination and uses the partially
> collected hits. A better model would be if we sorted segments by the
> estimated number of hits, thus increasing the probability of the overall
> relevance of the returned partial results.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-8.x-Linux (64bit/jdk-13-ea+18) - Build # 614 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/614/
Java: 64bit/jdk-13-ea+18 -XX:-UseCompressedOops -XX:+UseG1GC
1 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple
Error Message:
Waiting for collection testSimple2 Timeout waiting to see state for
collection=testSimple2
:DocCollection(testSimple2//collections/testSimple2/state.json/28)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{ "shard1":{
"range":"8000-", "state":"active", "replicas":{
"core_node3":{ "core":"testSimple2_shard1_replica_n1",
"base_url":"http://127.0.0.1:37865/solr";,
"node_name":"127.0.0.1:37865_solr", "state":"active",
"type":"NRT", "force_set_state":"false", "leader":"true"},
"core_node5":{ "core":"testSimple2_shard1_replica_n2",
"base_url":"http://127.0.0.1:36247/solr";,
"node_name":"127.0.0.1:36247_solr", "state":"down",
"type":"NRT", "force_set_state":"false"}, "core_node12":{
"core":"testSimple2_shard1_replica_n11",
"base_url":"http://127.0.0.1:37865/solr";, "state":"down",
"node_name":"127.0.0.1:37865_solr", "type":"NRT"}}}, "shard2":{
"range":"0-7fff", "state":"active", "replicas":{
"core_node7":{ "core":"testSimple2_shard2_replica_n4",
"base_url":"http://127.0.0.1:37865/solr";,
"node_name":"127.0.0.1:37865_solr", "state":"active",
"type":"NRT", "force_set_state":"false", "leader":"true"},
"core_node10":{ "core":"testSimple2_shard2_replica_n9",
"base_url":"http://127.0.0.1:37865/solr";,
"node_name":"127.0.0.1:37865_solr", "state":"active",
"type":"NRT", "force_set_state":"false",
"router":{"name":"compositeId"}, "maxShardsPerNode":"2",
"autoAddReplicas":"true", "nrtReplicas":"2", "tlogReplicas":"0"} Live
Nodes: [127.0.0.1:32905_solr, 127.0.0.1:37865_solr] Last available state:
DocCollection(testSimple2//collections/testSimple2/state.json/28)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{ "shard1":{
"range":"8000-", "state":"active", "replicas":{
"core_node3":{ "core":"testSimple2_shard1_replica_n1",
"base_url":"http://127.0.0.1:37865/solr";,
"node_name":"127.0.0.1:37865_solr", "state":"active",
"type":"NRT", "force_set_state":"false", "leader":"true"},
"core_node5":{ "core":"testSimple2_shard1_replica_n2",
"base_url":"http://127.0.0.1:36247/solr";,
"node_name":"127.0.0.1:36247_solr", "state":"down",
"type":"NRT", "force_set_state":"false"}, "core_node12":{
"core":"testSimple2_shard1_replica_n11",
"base_url":"http://127.0.0.1:37865/solr";, "state":"down",
"node_name":"127.0.0.1:37865_solr", "type":"NRT"}}}, "shard2":{
"range":"0-7fff", "state":"active", "replicas":{
"core_node7":{ "core":"testSimple2_shard2_replica_n4",
"base_url":"http://127.0.0.1:37865/solr";,
"node_name":"127.0.0.1:37865_solr", "state":"active",
"type":"NRT", "force_set_state":"false", "leader":"true"},
"core_node10":{ "core":"testSimple2_shard2_replica_n9",
"base_url":"http://127.0.0.1:37865/solr";,
"node_name":"127.0.0.1:37865_solr", "state":"active",
"type":"NRT", "force_set_state":"false",
"router":{"name":"compositeId"}, "maxShardsPerNode":"2",
"autoAddReplicas":"true", "nrtReplicas":"2", "tlogReplicas":"0"}
Stack Trace:
java.lang.AssertionError: Waiting for collection testSimple2
Timeout waiting to see state for collection=testSimple2
:DocCollection(testSimple2//collections/testSimple2/state.json/28)={
"pullReplicas":"0",
"replicationFactor":"2",
"shards":{
"shard1":{
"range":"8000-",
"state":"active",
"replicas":{
"core_node3":{
"core":"testSimple2_shard1_replica_n1",
"base_url":"http://127.0.0.1:37865/solr";,
"node_name":"127.0.0.1:37865_solr",
"state":"active",
"type":"NRT",
"force_set_state":"false",
"leader":"true"},
"core_node5":{
"core":"testSimple2_shard1_replica_n2",
"base_url":"http://127.0.0.1:36247/solr";,
"node_name":"127.0.0.1:36247_solr",
"state":"down",
"type":"NRT",
"force_set_state":"false"},
"core_node12":{
"core":"testSimple2_shard1_replica_n11",
[jira] [Updated] (SOLR-12562) Clean up RealTimeGetComponent.toSolrDoc
[ https://issues.apache.org/jira/browse/SOLR-12562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-12562: -- Summary: Clean up RealTimeGetComponent.toSolrDoc (was: Remove redundant RealTimeGetCompnent.toSolrDoc and use DocStreamer.convertLuceneDocToSolrDoc) > Clean up RealTimeGetComponent.toSolrDoc > --- > > Key: SOLR-12562 > URL: https://issues.apache.org/jira/browse/SOLR-12562 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-12562.patch > > > This code looks really redundant so we should remove one. The one in > RealTimeGet is the only used locally so my vote is to remove that one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 3297 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3297/ [...truncated 57 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-Tests-7.7/25/consoleText [repro] Revision: fced8ab89e98c565166059e5052d3bc700468199 [repro] Repro line: ant test -Dtestcase=TestSQLHandler -Dtests.method=doTest -Dtests.seed=4B2D624438FFAB12 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=fr -Dtests.timezone=America/Guatemala -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 46060d88a2a80794a95e6899e532c7a7da9c4dfb [repro] git fetch [repro] git checkout fced8ab89e98c565166059e5052d3bc700468199 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestSQLHandler [repro] ant compile-test [...truncated 3585 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestSQLHandler" -Dtests.showOutput=onerror -Dtests.seed=4B2D624438FFAB12 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=fr -Dtests.timezone=America/Guatemala -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 2008 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 2/5 failed: org.apache.solr.handler.TestSQLHandler [repro] git checkout 46060d88a2a80794a95e6899e532c7a7da9c4dfb [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8778) Define analyzer SPI names as static final fields and document the names in Javadocs
[
https://issues.apache.org/jira/browse/LUCENE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-8778:
--
Attachment: ListAnalysisComponents.java
> Define analyzer SPI names as static final fields and document the names in
> Javadocs
> ---
>
> Key: LUCENE-8778
> URL: https://issues.apache.org/jira/browse/LUCENE-8778
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Priority: Minor
> Attachments: ListAnalysisComponents.java, SPINamesGenerator.java,
> Screenshot from 2019-04-26 02-17-48.png
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Each built-in analysis component (factory of tokenizer / char filter / token
> filter) has a SPI name but currently this is not documented anywhere.
> The goals of this issue:
> * Define SPI names as static final field for each analysis component so that
> users can get the component by name (via {{NAME}} static field.) This also
> provides compile time safety.
> * Officially document the SPI names in Javadocs.
> * Add proper source validation rules to ant {{validate-source-patterns}}
> target so that we can make sure that all analysis components have correct
> field definitions and documentation
> and,
> * Lookup SPI names on the new {{NAME}} fields. Instead deriving those from
> class names.
> (Just for quick reference) we now have:
> * *19* Tokenizers ({{TokenizerFactory.availableTokenizers()}})
> * *6* CharFilters ({{CharFilterFactory.availableCharFilters()}})
> * *118* TokenFilters ({{TokenFilterFactory.availableTokenFilters()}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 109 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/109/
1 tests failed.
FAILED: org.apache.solr.security.JWTAuthPluginIntegrationTest.testMetrics
Error Message:
Expected metric minimums for prefix SECURITY./authentication.:
{failMissingCredentials=1, authenticated=4, passThrough=4,
failWrongCredentials=0, requests=9, errors=0}, but got:
{failMissingCredentials=1, authenticated=3, passThrough=4, totalTime=2154859,
failWrongCredentials=0, requestTimes=871, requests=8, errors=0}
Stack Trace:
java.lang.AssertionError: Expected metric minimums for prefix
SECURITY./authentication.: {failMissingCredentials=1, authenticated=4,
passThrough=4, failWrongCredentials=0, requests=9, errors=0}, but got:
{failMissingCredentials=1, authenticated=3, passThrough=4, totalTime=2154859,
failWrongCredentials=0, requestTimes=871, requests=8, errors=0}
at
__randomizedtesting.SeedInfo.seed([4EC301F6BBCFEE74:B0D1D354A7C599C7]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:129)
at
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:83)
at
org.apache.solr.security.JWTAuthPluginIntegrationTest.testMetrics(JWTAuthPluginIntegrationTest.java:153)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
[jira] [Commented] (LUCENE-8808) Introduce Optional Cap on Number Of Threads Per Query
[ https://issues.apache.org/jira/browse/LUCENE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847430#comment-16847430 ] Atri Sharma commented on LUCENE-8808: - Sure. Do you have any ideas of how could we control that large queries do not go out of hand in terms of resource consumption? Happy to discuss them > Introduce Optional Cap on Number Of Threads Per Query > - > > Key: LUCENE-8808 > URL: https://issues.apache.org/jira/browse/LUCENE-8808 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Atri Sharma >Priority: Major > > With the presence of https://issues.apache.org/jira/browse/LUCENE-8757 , a > natural progression is to allow advanced users to specify a cap on the number > of threads a query can use. This is especially useful for long polled > IndexSearcher instances, where the same instance is used to fire queries for > multiple runs and there are multiple concurrent IndexSearcher instances on > the same node. > > This will be an optional parameter and local only to the IndexSearcher > instance being configured during construction. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847409#comment-16847409 ] ASF subversion and git services commented on SOLR-13434: Commit a341ee35ff6a5122059f5251d6af5f6a3a53fd8b in lucene-solr's branch refs/heads/jira/SOLR-13434 from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a341ee3 ] SOLR-13434: Remove unnecessary file > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 1.5h > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847410#comment-16847410 ] ASF subversion and git services commented on SOLR-13434: Commit ff59746decd9a0f03763b438a460198847759c86 in lucene-solr's branch refs/heads/jira/SOLR-13434 from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ff59746 ] SOLR-13434: Upgrade README for Jaeger contrib module > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 1.5h > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847408#comment-16847408 ] ASF subversion and git services commented on SOLR-13434: Commit b90883e58860c903bdbd43c18fecef9da96fe467 in lucene-solr's branch refs/heads/jira/SOLR-13434 from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b90883e ] SOLR-13434: Initial commit > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 1.5h > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847413#comment-16847413 ] ASF subversion and git services commented on SOLR-13434: Commit 7f38ca08b460917a2019b8efcd325631a7bca0c7 in lucene-solr's branch refs/heads/jira/SOLR-13434 from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7f38ca0 ] SOLR-13434: Revert back un-related changes to TestCloudRecovery > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 1.5h > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847412#comment-16847412 ] ASF subversion and git services commented on SOLR-13434: Commit 7e981464efd0bf9884681d63eea58cb296986047 in lucene-solr's branch refs/heads/jira/SOLR-13434 from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7e98146 ] SOLR-13434: Remove .DS_Store > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 1.5h > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847414#comment-16847414 ] ASF subversion and git services commented on SOLR-13434: Commit 4fc0e4f8f6d18092fbbb983dba7287e8777b0b45 in lucene-solr's branch refs/heads/jira/SOLR-13434 from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4fc0e4f ] SOLR-13434: Move Jaeger-contrib to correct package > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 1.5h > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847411#comment-16847411 ] ASF subversion and git services commented on SOLR-13434: Commit 67d587e7f673f7212ff81d1d0b9007b44eebdfd4 in lucene-solr's branch refs/heads/jira/SOLR-13434 from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=67d587e ] SOLR-13434: Add back JavaagentTracerConfigurator > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 1.5h > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8808) Introduce Optional Cap on Number Of Threads Per Query
[ https://issues.apache.org/jira/browse/LUCENE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847400#comment-16847400 ] Adrien Grand commented on LUCENE-8808: -- In general I'm reluctant to adding more configuration options. It increases the API surface area, which in turn makes Lucene harder to use. My gut feeling right now is that this new setting would not help enough to warrant the introduction of a new option? > Introduce Optional Cap on Number Of Threads Per Query > - > > Key: LUCENE-8808 > URL: https://issues.apache.org/jira/browse/LUCENE-8808 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Atri Sharma >Priority: Major > > With the presence of https://issues.apache.org/jira/browse/LUCENE-8757 , a > natural progression is to allow advanced users to specify a cap on the number > of threads a query can use. This is especially useful for long polled > IndexSearcher instances, where the same instance is used to fire queries for > multiple runs and there are multiple concurrent IndexSearcher instances on > the same node. > > This will be an optional parameter and local only to the IndexSearcher > instance being configured during construction. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8784) Nori(Korean) tokenizer removes the decimal point.
[
https://issues.apache.org/jira/browse/LUCENE-8784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847381#comment-16847381
]
Jim Ferenczi commented on LUCENE-8784:
--
{quote}
By the way, would not it be better to leave the constructors that do not use
discardPunctuation parameters?
(Existing Nori users have to modify the code after uploading)
{quote}
Yes we should do that, otherwise it's a breaking change and we cannot push to
8x.
{quote}
I also added Javadoc for discardPunctuation in your patch. (KoreanAnalyzer,
KoreanTokenizerFactory)
{quote}
thanks!
{quote}
I developed KoreanNumberFilter by referring to JapaneseNumberFilter.
Please check my patch :D
{quote}
The patch looks good but we should iterate on this in a new issue. We try to do
one feature at a time in a single issue so let's add discardPunctuation in this
one and we can open a new one as a follow up to add the KoreanNumberFilter ?
> Nori(Korean) tokenizer removes the decimal point.
> ---
>
> Key: LUCENE-8784
> URL: https://issues.apache.org/jira/browse/LUCENE-8784
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Munkyu Im
>Priority: Major
> Attachments: LUCENE-8784.patch, LUCENE-8784.patch, LUCENE-8784.patch
>
>
> This is the same issue that I mentioned to
> [https://github.com/elastic/elasticsearch/issues/41401#event-2293189367]
> unlike standard analyzer, nori analyzer removes the decimal point.
> nori tokenizer removes "." character by default.
> In this case, it is difficult to index the keywords including the decimal
> point.
> It would be nice if there had the option whether add a decimal point or not.
> Like Japanese tokenizer does, Nori need an option to preserve decimal point.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8808) Introduce Optional Cap on Number Of Threads Per Query
[ https://issues.apache.org/jira/browse/LUCENE-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847377#comment-16847377 ] Atri Sharma commented on LUCENE-8808: - [~jpountz] I further tested this by trying out a 900 GB dataset with a large query (around 6 billion hits) on a 32 vCPU machine. With 8 concurrent clients doing the same query and sharing the same threadpool, the backlog of threads on the threadpool was 3-5X larger than the case when there was a capping of 16 threads per query. Overall, the P50 improved with the cap since the extra dequeuing and thread context switching costs were saved. However, P99.9 worsened due to lesser concurrency. Since this is an optional parameter, users will have a choice, so is configurable per workload. WDYT? > Introduce Optional Cap on Number Of Threads Per Query > - > > Key: LUCENE-8808 > URL: https://issues.apache.org/jira/browse/LUCENE-8808 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Atri Sharma >Priority: Major > > With the presence of https://issues.apache.org/jira/browse/LUCENE-8757 , a > natural progression is to allow advanced users to specify a cap on the number > of threads a query can use. This is especially useful for long polled > IndexSearcher instances, where the same instance is used to fire queries for > multiple runs and there are multiple concurrent IndexSearcher instances on > the same node. > > This will be an optional parameter and local only to the IndexSearcher > instance being configured during construction. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7386) Flatten nested disjunctions
[ https://issues.apache.org/jira/browse/LUCENE-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-7386. -- Resolution: Fixed Fix Version/s: master (9.0) 8.1 > Flatten nested disjunctions > --- > > Key: LUCENE-7386 > URL: https://issues.apache.org/jira/browse/LUCENE-7386 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-7386.patch, LUCENE-7386.patch, LUCENE-7386.patch > > > Now that coords are gone it became easier to flatten nested disjunctions. It > might sound weird to write nested disjunctions in the first place, but > disjunctions can be created implicitly by other queries such as > more-like-this, LatLonPoint.newBoxQuery, non-scoring synonym queries, etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8810) Flattening of nested disjunctions does not take into account number of clause limitation of builder
[
https://issues.apache.org/jira/browse/LUCENE-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847352#comment-16847352
]
Atri Sharma commented on LUCENE-8810:
-
++ agreed. Will post a patch on
https://issues.apache.org/jira/browse/LUCENE-8811 with the IndexSeacher approach
> Flattening of nested disjunctions does not take into account number of clause
> limitation of builder
> ---
>
> Key: LUCENE-8810
> URL: https://issues.apache.org/jira/browse/LUCENE-8810
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 8.0
>Reporter: Mickaël Sauvée
>Priority: Minor
> Fix For: 8.1.1
>
> Attachments: LUCENE-8810.patch
>
>
> In org.apache.lucene.search.BooleanQuery, at the end of the function
> rewrite(IndexReader reader), the query is rewritten to flatten nested
> disjunctions.
> This does not take into account the limitation on the number of clauses in a
> builder (1024).
> In some circumstances, this limite can be reached, hence an exception is
> thrown.
> Here is a unit test that highlight this.
> {code:java}
> public void testFlattenInnerDisjunctionsWithMoreThan1024Terms() throws
> IOException {
> IndexSearcher searcher = newSearcher(new MultiReader());
> BooleanQuery.Builder builder1024 = new BooleanQuery.Builder();
> for(int i = 0; i < 1024; i++) {
> builder1024.add(new TermQuery(new Term("foo", "bar-" + i)),
> Occur.SHOULD);
> }
> Query inner = builder1024.build();
> Query query = new BooleanQuery.Builder()
> .add(inner, Occur.SHOULD)
> .add(new TermQuery(new Term("foo", "baz")), Occur.SHOULD)
> .build();
> searcher.rewrite(query);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8810) Flattening of nested disjunctions does not take into account number of clause limitation of builder
[
https://issues.apache.org/jira/browse/LUCENE-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847343#comment-16847343
]
Adrien Grand commented on LUCENE-8810:
--
Doing instanceof checks feels too fragile to me, this won't work if the
BooleanQuery is wrapped under a ConstantScoreQuery or a BoostQuery. We could
consider using the visitor API instead, but this would make BooleanQuery
construction run in quadratic time of the depth of the query (if you have a
boolean query BQ1 that wraps BQ2, which itself wraps BQ3, the clause count of
BQ2 will be checked by BQ1 and BQ2 and the clause count of BQ3 will be checked
by BQ1, BQ2 and BQ3, etc.), which is why I thought of IndexSearcher, which is
the place where we would have access to the top-level query.
> Flattening of nested disjunctions does not take into account number of clause
> limitation of builder
> ---
>
> Key: LUCENE-8810
> URL: https://issues.apache.org/jira/browse/LUCENE-8810
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 8.0
>Reporter: Mickaël Sauvée
>Priority: Minor
> Fix For: 8.1.1
>
> Attachments: LUCENE-8810.patch
>
>
> In org.apache.lucene.search.BooleanQuery, at the end of the function
> rewrite(IndexReader reader), the query is rewritten to flatten nested
> disjunctions.
> This does not take into account the limitation on the number of clauses in a
> builder (1024).
> In some circumstances, this limite can be reached, hence an exception is
> thrown.
> Here is a unit test that highlight this.
> {code:java}
> public void testFlattenInnerDisjunctionsWithMoreThan1024Terms() throws
> IOException {
> IndexSearcher searcher = newSearcher(new MultiReader());
> BooleanQuery.Builder builder1024 = new BooleanQuery.Builder();
> for(int i = 0; i < 1024; i++) {
> builder1024.add(new TermQuery(new Term("foo", "bar-" + i)),
> Occur.SHOULD);
> }
> Query inner = builder1024.build();
> Query query = new BooleanQuery.Builder()
> .add(inner, Occur.SHOULD)
> .add(new TermQuery(new Term("foo", "baz")), Occur.SHOULD)
> .build();
> searcher.rewrite(query);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8811) Add maximum clause count check to IndexSearcher rather than BooleanQuery
[ https://issues.apache.org/jira/browse/LUCENE-8811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847334#comment-16847334 ] Atri Sharma commented on LUCENE-8811: - [~jpountz] Thanks for opening this. I posted a patch in LUCENE-8810 which handles the boolean query case. I think this problem would be most prevalent for boolean queries, but if you believe a more general check is valuable, I am happy to put up a patch for checking through IndexSearcher. > Add maximum clause count check to IndexSearcher rather than BooleanQuery > > > Key: LUCENE-8811 > URL: https://issues.apache.org/jira/browse/LUCENE-8811 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > > Currently we only check whether boolean queries have too many clauses. > However there are other ways that queries may have too many clauses, for > instance if you have boolean queries that have themselves inner boolean > queries. > Could we use the new Query visitor API to move this check from BooleanQuery > to IndexSearcher in order to make this check more consistent across queries? > See for instance LUCENE-8810 where a rewrite rule caused the maximum clause > count to be hit even though the total number of leaf queries remained the > same. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8810) Flattening of nested disjunctions does not take into account number of clause limitation of builder
[
https://issues.apache.org/jira/browse/LUCENE-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847332#comment-16847332
]
Atri Sharma commented on LUCENE-8810:
-
[~msauvee] I understand the confusion. Ideally, we should be raising the
exception at the same place as would happen if you built a single Builder (no
nested clauses) and put >1024 clauses.
I put in a WIP patch to handle this more gracefully. [~jpountz] would this
suffice?
[^LUCENE-8810.patch]
> Flattening of nested disjunctions does not take into account number of clause
> limitation of builder
> ---
>
> Key: LUCENE-8810
> URL: https://issues.apache.org/jira/browse/LUCENE-8810
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 8.0
>Reporter: Mickaël Sauvée
>Priority: Minor
> Fix For: 8.1.1
>
> Attachments: LUCENE-8810.patch
>
>
> In org.apache.lucene.search.BooleanQuery, at the end of the function
> rewrite(IndexReader reader), the query is rewritten to flatten nested
> disjunctions.
> This does not take into account the limitation on the number of clauses in a
> builder (1024).
> In some circumstances, this limite can be reached, hence an exception is
> thrown.
> Here is a unit test that highlight this.
> {code:java}
> public void testFlattenInnerDisjunctionsWithMoreThan1024Terms() throws
> IOException {
> IndexSearcher searcher = newSearcher(new MultiReader());
> BooleanQuery.Builder builder1024 = new BooleanQuery.Builder();
> for(int i = 0; i < 1024; i++) {
> builder1024.add(new TermQuery(new Term("foo", "bar-" + i)),
> Occur.SHOULD);
> }
> Query inner = builder1024.build();
> Query query = new BooleanQuery.Builder()
> .add(inner, Occur.SHOULD)
> .add(new TermQuery(new Term("foo", "baz")), Occur.SHOULD)
> .build();
> searcher.rewrite(query);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8810) Flattening of nested disjunctions does not take into account number of clause limitation of builder
[
https://issues.apache.org/jira/browse/LUCENE-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Atri Sharma updated LUCENE-8810:
Attachment: LUCENE-8810.patch
> Flattening of nested disjunctions does not take into account number of clause
> limitation of builder
> ---
>
> Key: LUCENE-8810
> URL: https://issues.apache.org/jira/browse/LUCENE-8810
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 8.0
>Reporter: Mickaël Sauvée
>Priority: Minor
> Fix For: 8.1.1
>
> Attachments: LUCENE-8810.patch
>
>
> In org.apache.lucene.search.BooleanQuery, at the end of the function
> rewrite(IndexReader reader), the query is rewritten to flatten nested
> disjunctions.
> This does not take into account the limitation on the number of clauses in a
> builder (1024).
> In some circumstances, this limite can be reached, hence an exception is
> thrown.
> Here is a unit test that highlight this.
> {code:java}
> public void testFlattenInnerDisjunctionsWithMoreThan1024Terms() throws
> IOException {
> IndexSearcher searcher = newSearcher(new MultiReader());
> BooleanQuery.Builder builder1024 = new BooleanQuery.Builder();
> for(int i = 0; i < 1024; i++) {
> builder1024.add(new TermQuery(new Term("foo", "bar-" + i)),
> Occur.SHOULD);
> }
> Query inner = builder1024.build();
> Query query = new BooleanQuery.Builder()
> .add(inner, Occur.SHOULD)
> .add(new TermQuery(new Term("foo", "baz")), Occur.SHOULD)
> .build();
> searcher.rewrite(query);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8803) Provide a FieldComparator to allow sorting by a feature from a FeatureField
[ https://issues.apache.org/jira/browse/LUCENE-8803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847328#comment-16847328 ] ASF subversion and git services commented on LUCENE-8803: - Commit 39c8cca17775076a69465f1c18df418f4490097e in lucene-solr's branch refs/heads/branch_8x from Colin Goodheart-Smithe [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=39c8cca ] LUCENE-8803: Provide a FieldComparator to allow sorting by a feature from a FeatureField (#680) This change adds a SortField which allows a convenient way to sort search hits using a feature from a FeatureField. > Provide a FieldComparator to allow sorting by a feature from a FeatureField > --- > > Key: LUCENE-8803 > URL: https://issues.apache.org/jira/browse/LUCENE-8803 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Colin Goodheart-Smithe >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > > It would be useful to be able to sort search hits by the value of a feature > from a feature field (e.g. pagerank). A FieldComparatorSource implementation > that enables this would create a convenient generic way to sort using values > from feature fields. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8810) Flattening of nested disjunctions does not take into account number of clause limitation of builder
[
https://issues.apache.org/jira/browse/LUCENE-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847320#comment-16847320
]
Adrien Grand commented on LUCENE-8810:
--
I'm expecting that this would mostly be an issue for users who use inner
boolean queries as a way to work around the maximum clause count. That said I
understand how this change can be surprising, and it should be easy enough to
check the clause count in the rewrite rule so I'd be ok with doing this. Would
you like to work on a patch?
I opened LUCENE-8811 to maybe re-think the way that we check the number of
clauses of queries in a more consistent way.
bq. I do not know what is "block-max WAND" (line 479 of BooleanQuery).
It is an optimized way to retrieve top hits of disjunctions (boolean queries
with only SHOULD clauses) by decreasing score. It works by ignoring low-scoring
clauses, and works better when disjunctions are inlined since this gives more
information to the algorithm.
> Flattening of nested disjunctions does not take into account number of clause
> limitation of builder
> ---
>
> Key: LUCENE-8810
> URL: https://issues.apache.org/jira/browse/LUCENE-8810
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 8.0
>Reporter: Mickaël Sauvée
>Priority: Minor
> Fix For: 8.1.1
>
>
> In org.apache.lucene.search.BooleanQuery, at the end of the function
> rewrite(IndexReader reader), the query is rewritten to flatten nested
> disjunctions.
> This does not take into account the limitation on the number of clauses in a
> builder (1024).
> In some circumstances, this limite can be reached, hence an exception is
> thrown.
> Here is a unit test that highlight this.
> {code:java}
> public void testFlattenInnerDisjunctionsWithMoreThan1024Terms() throws
> IOException {
> IndexSearcher searcher = newSearcher(new MultiReader());
> BooleanQuery.Builder builder1024 = new BooleanQuery.Builder();
> for(int i = 0; i < 1024; i++) {
> builder1024.add(new TermQuery(new Term("foo", "bar-" + i)),
> Occur.SHOULD);
> }
> Query inner = builder1024.build();
> Query query = new BooleanQuery.Builder()
> .add(inner, Occur.SHOULD)
> .add(new TermQuery(new Term("foo", "baz")), Occur.SHOULD)
> .build();
> searcher.rewrite(query);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+18) - Build # 24136 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24136/ Java: 64bit/jdk-13-ea+18 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenRenew Error Message: expected:<200> but was:<403> Stack Trace: java.lang.AssertionError: expected:<200> but was:<403> at __randomizedtesting.SeedInfo.seed([5F278A58C598260E:68BC7E46FD54FBAA]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:631) at org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.renewDelegationToken(TestDelegationWithHadoopAuth.java:120) at org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.verifyDelegationTokenRenew(TestDelegationWithHadoopAuth.java:303) at org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenRenew(TestDelegationWithHadoopAuth.java:321) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedt
[jira] [Created] (LUCENE-8811) Add maximum clause count check to IndexSearcher rather than BooleanQuery
Adrien Grand created LUCENE-8811: Summary: Add maximum clause count check to IndexSearcher rather than BooleanQuery Key: LUCENE-8811 URL: https://issues.apache.org/jira/browse/LUCENE-8811 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Currently we only check whether boolean queries have too many clauses. However there are other ways that queries may have too many clauses, for instance if you have boolean queries that have themselves inner boolean queries. Could we use the new Query visitor API to move this check from BooleanQuery to IndexSearcher in order to make this check more consistent across queries? See for instance LUCENE-8810 where a rewrite rule caused the maximum clause count to be hit even though the total number of leaf queries remained the same. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8810) Flattening of nested disjunctions does not take into account number of clause limitation of builder
[
https://issues.apache.org/jira/browse/LUCENE-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847303#comment-16847303
]
Mickaël Sauvée commented on LUCENE-8810:
[~atris] In my test, the inner builder is not erroing (if I interpret well your
comment): this is the rewrite that raise an exception. The rewrite will flatten
the 1025 clauses.
Maybe this is the expected behavior, but in 7.5 the rewrite was ok (without
flattening of course). So this is a change in behavior.
What I would have expected, is flattening to a max of 1024 clauses or do not
flatten if not possible, but not an exception raised. I may be wrong as I do
not know what is "block-max WAND" (line 479 of BooleanQuery).
> Flattening of nested disjunctions does not take into account number of clause
> limitation of builder
> ---
>
> Key: LUCENE-8810
> URL: https://issues.apache.org/jira/browse/LUCENE-8810
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 8.0
>Reporter: Mickaël Sauvée
>Priority: Minor
> Fix For: 8.1.1
>
>
> In org.apache.lucene.search.BooleanQuery, at the end of the function
> rewrite(IndexReader reader), the query is rewritten to flatten nested
> disjunctions.
> This does not take into account the limitation on the number of clauses in a
> builder (1024).
> In some circumstances, this limite can be reached, hence an exception is
> thrown.
> Here is a unit test that highlight this.
> {code:java}
> public void testFlattenInnerDisjunctionsWithMoreThan1024Terms() throws
> IOException {
> IndexSearcher searcher = newSearcher(new MultiReader());
> BooleanQuery.Builder builder1024 = new BooleanQuery.Builder();
> for(int i = 0; i < 1024; i++) {
> builder1024.add(new TermQuery(new Term("foo", "bar-" + i)),
> Occur.SHOULD);
> }
> Query inner = builder1024.build();
> Query query = new BooleanQuery.Builder()
> .add(inner, Occur.SHOULD)
> .add(new TermQuery(new Term("foo", "baz")), Occur.SHOULD)
> .build();
> searcher.rewrite(query);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-NightlyTests-7.7 - Build # 18 - Still Unstable
Well, I kind of think anything related to indexing/ merging would be qualified as "serious" or at least "serious-ish". ;) I know there's been a few changes to the IndexWriter lately, so I thought it might have been a consequence of that -- if you think it's not new then it's probably something else. I did not investigate; I just look at jenkins logs from time to time to see if there's anything important in there. Dawid On Thu, May 23, 2019 at 10:24 PM Jan Høydahl wrote: > > I see this test failing now and then for the last year. > I have not studied the stack traces, can you say a few more words about what > you found and why it may be serious? > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 23. mai 2019 kl. 12:29 skrev Dawid Weiss : > > Hmm... this looks serious, no? > D. > > On Thu, May 23, 2019 at 2:27 AM Apache Jenkins Server > wrote: > > > Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.7/18/ > > 1 tests failed. > FAILED: > org.apache.lucene.index.TestConcurrentMergeScheduler.testFlushExceptions > > Error Message: > > > Stack Trace: > java.lang.AssertionError >at > __randomizedtesting.SeedInfo.seed([730AC7E1D88016C6:C760943BD16080F2]:0) >at org.junit.Assert.fail(Assert.java:86) >at org.junit.Assert.assertTrue(Assert.java:41) >at org.junit.Assert.assertTrue(Assert.java:52) >at > org.apache.lucene.index.TestConcurrentMergeScheduler.testFlushExceptions(TestConcurrentMergeScheduler.java:128) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >at java.lang.reflect.Method.invoke(Method.java:498) >at > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) >at > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) >at > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) >at > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) >at > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) >at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) >at > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) >at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) >at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) >at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) >at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) >at > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) >at > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) >at > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) >at > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) >at > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) >at > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) >at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) >at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) >at > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) >at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) >at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) >at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) >at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) >at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) >at > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) >at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) >at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) >at > org.apache.lucene.util.TestRuleI
