[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 2044 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/2044/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteShard

Error Message:
expected:<6> but was:<4>

Stack Trace:
java.lang.AssertionError: expected:<6> but was:<4>
at 
__randomizedtesting.SeedInfo.seed([9CE1B6AEEC5AED4A:59BF02B26AAF27B7]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteShard(CollectionsAPISolrJTest.java:217)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.testSearchRate

[jira] [Commented] (SOLR-12593) Remove date parsing functionality from extraction contrib

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602589#comment-16602589
 ] 

David Smiley commented on SOLR-12593:
-

For example follow the tutorial/example in the ref guide on the feature in 
which you post a PDF doc that will undoubtedly contain at least one data 
metadata attribute.  Any way, nevermind as I've been trying this out.  I 
rescind my proposal to change the config of /extract to explicitly add 
processor=parse-date.  Dates are just one data type; conceptually there's the 
same issue with numbers and yet this content handler doesn't have special 
considerations for them.  I think a tip in the ref guide would be enough to 
suggest using the parse\- related URPs to ensure dates and numbers are handled 
properly.

I think the ref guide tutorial on this feature should be migrated from using 
the "techproducts" example config to the "schemaless" example config (which is 
really the default config).  The techproducts config doesn't even have this URP 
set up and I don't think it makes sense at all to use that config for this 
feature.  I'll post an update.

> Remove date parsing functionality from extraction contrib
> -
>
> Key: SOLR-12593
> URL: https://issues.apache.org/jira/browse/SOLR-12593
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: master (8.0)
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> The date parsing functionality in the extraction contrib is obsoleted by 
> equivalent functionality in ParseDateFieldUpdateProcessorFactory.  It should 
> be removed.  We should add documentation within this part of the ref guide on 
> how to accomplish the same (and test it).



--
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-12357) TRA: Pre-emptively create next collection

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602585#comment-16602585
 ] 

David Smiley commented on SOLR-12357:
-

The patch looks good.  As discussed in chat:  I beasted the individual test and 
it passed (yay).  But there appears to now be a regression with 
org.apache.solr.update.processor.TimeRoutedAliasUpdateProcessorTest#testSliceRouting
 :-(  Any idea yet why?  7.5 is expected later this week; it'd be great to 
finish in time.

> TRA: Pre-emptively create next collection 
> --
>
> Key: SOLR-12357
> URL: https://issues.apache.org/jira/browse/SOLR-12357
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Priority: Major
>  Time Spent: 9h 20m
>  Remaining Estimate: 0h
>
> When adding data to a Time Routed Alias (TRA), we sometimes need to create 
> new collections.  Today we only do this synchronously – on-demand when a 
> document is coming in.  But this can add delays as the documents inbound are 
> held up for a collection to be created.  And, there may be a problem like a 
> lack of resources (e.g. ample SolrCloud nodes with space) that the policy 
> framework defines.  Such problems could be rectified sooner rather than later 
> assume there is log alerting in place (definitely out of scope here).
> Pre-emptive TRA collection needs a time window configuration parameter, 
> perhaps named something like "preemptiveCreateWindowMs".  If a document's 
> timestamp is within this time window _from the end time of the head/lead 
> collection_ then the collection can be created pre-eptively.  If no data is 
> being sent to the TRA, no collections will be auto created, nor will it 
> happen if older data is being added.  It may be convenient to effectively 
> limit this time setting to the _smaller_ of this value and the TRA interval 
> window, which I think is a fine limitation.



--
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-12685) RTG should return the whole block if schema is nested

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602580#comment-16602580
 ] 

David Smiley commented on SOLR-12685:
-

bq. I was thinking RTG should not return the whole block when queried directly 
by the RTG handler ...

I thought that's what you set out to do in this issue, which subsumes 
SOLR-9006; right?  Are you changing your mind?

bq. ...  but rather should explicitly perform these checks when running 
RealTimeGetComponent#getInputDocument, which is used by 
AtomicUpdateDocumentMerger

If you want to work on that, then wouldn't that be SOLR-12638?

> RTG should return the whole block if schema is nested
> -
>
> Key: SOLR-12685
> URL: https://issues.apache.org/jira/browse/SOLR-12685
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
> Attachments: SOLR-12638-no-commit.patch
>
>
> Currently Solr's RealTimeGet component return the document if provided a 
> docId when consulting the index. For AtomicUpdates for child documents, RTG 
> should return the whole block when dealing with a nested schema.



--
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-7.x-Linux (64bit/jdk-10.0.1) - Build # 2684 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2684/
Java: 64bit/jdk-10.0.1 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaFromClusterState

Error Message:
Collection not found: deleteFromClusterState_false

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: 
deleteFromClusterState_false
at 
__randomizedtesting.SeedInfo.seed([D0546DB50E7F9FF8:3ECDC6D83141E44F]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:853)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:173)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138)
at 
org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaFromClusterState(DeleteReplicaTest.java:188)
at 
org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaFromClusterState(DeleteReplicaTest.java:179)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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 

Re: Lucene/Solr 7.5

[Varun Thacker]

+1

Erick - ZK 3.4.13 looks like a BugFix release and was released on July
15th. So based on those facts +1 to upgrade if you plan on tackling this.


On Mon, Sep 3, 2018 at 2:43 AM jim ferenczi  wrote:

> Hi all,
>
> 7.4 has been released two months ago on June 29th and we have new
> features, enhancements and fixes that are not released yet so I'd like to
> start working on releasing Lucene/Solr 7.5.0.
> There's also a bad bug with index sorting that deletes the wrong documents
> when delete by query is used:
> https://issues.apache.org/jira/browse/LUCENE-8466
>
> I can create the 7.5 branch later this week and build the first RC early
> next week if that works for everyone. Please let me know if there are bug
> fixes that needs to be fixed in 7.5 and might not be ready by then.
>
> Cheers,
> Jim
>

[jira] [Updated] (SOLR-10697) Improve defaults for maxConnectionsPerHost

[Varun Thacker (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Varun Thacker updated SOLR-10697:
-
Fix Version/s: 7.5
   master (8.0)

> Improve defaults for maxConnectionsPerHost
> --
>
> Key: SOLR-10697
> URL: https://issues.apache.org/jira/browse/SOLR-10697
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-10697.patch, SOLR-10697.patch, SOLR-10697.patch
>
>
> Twice recently I've increased 
> {{HttpShardHandlerFactory#maxConnectionsPerHost}} at a client and it helped 
> improve query latencies a lot.
> Should we increase the default to say 100 ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #443: SOLR-12722: add fl param to ChildDocTransform...

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/443#discussion_r214773746
  
--- Diff: 
solr/core/src/java/org/apache/solr/response/transform/ChildDocTransformer.java 
---
@@ -132,6 +134,12 @@ public void transform(SolrDocument rootDoc, int 
rootDocId) {
 
   // load the doc
   SolrDocument doc = searcher.getDocFetcher().solrDoc(docId, 
childReturnFields);
+  if(childReturnFields.getTransformer() != null) {
+if(childReturnFields.getTransformer().context != this.context) 
{
--- End diff --

maybe this line should only check if context is null?  By checking if the 
context is different, it's suggestive there may already be a context but if 
that were true then we ought to reinstate the former context when done.  I 
suspect it's always going to be null.  Can you look?


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #443: SOLR-12722: add fl param to ChildDocTransform...

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/443#discussion_r214773781
  
--- Diff: 
solr/core/src/java/org/apache/solr/response/transform/ChildDocTransformerFactory.java
 ---
@@ -106,9 +123,20 @@ public DocTransformer create(String field, SolrParams 
params, SolrQueryRequest r
   }
 }
 
+String childReturnFields = params.get("fl");
+SolrReturnFields childSolrReturnFields;
+if(childReturnFields != null) {
+  childSolrReturnFields = new SolrReturnFields(childReturnFields, req);
+} else if(req.getSchema().getDefaultLuceneMatchVersion().major < 8) {
--- End diff --

Nice


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

BadApple for the week

[Erick Erickson]

I didn't get to it last week, so this week will be a two-fer. I'm
still working out what to do with suites.

But, I'm un-annotating 33 tests and annotating 17 so it's better ;)

  **Annotations will be removed from the following tests because they
haven't failed in the last 4 rollups.

  **Methods: 33
   CdcrBootstrapTest.testConvertClusterToCdcrAndBootstrap
   CloudSolrClientTest.preferLocalShardsTest
   CollectionsAPIAsyncDistributedZkTest.testAsyncIdRaceCondition
   ComputePlanActionTest.testNodeLost
   DeleteShardTest.testDirectoryCleanupAfterDeleteShard
   DistributedMLTComponentTest.test
   GraphExpressionTest.testShortestPathStream
   GraphTest.testShortestPathStream
   HttpSolrCallGetCoreTest
   LargeVolumeJettyTest
   LeaderElectionIntegrationTest.testSimpleSliceLeaderElection
   MetricTriggerIntegrationTest.testMetricTrigger
   MoveReplicaHDFSTest.testNormalFailedMove
   SchemaApiFailureTest.testAddTheSameFieldTwice
   SearchRateTriggerTest.testTrigger
   SolrCloudReportersTest.testDefaultPlugins
   SolrCloudReportersTest.testExplicitConfiguration
   StreamExpressionTest.testParallelTopicStream
   TestCloudRecovery.leaderRecoverFromLogOnStartupTest
   TestDelegationWithHadoopAuth.testDelegationTokenRenew
   TestDistribIDF.testMultiCollectionQuery
   TestDocTermOrdsUninvertLimit.testTriggerUnInvertLimit
   TestInPlaceUpdatesDistrib.test
   TestLTROnSolrCloud.testSimpleQuery
   TestManagedResourceStorage
   TestSimGenericDistributedQueue
   TestSimGenericDistributedQueue.testDistributedQueue
   TestSimLargeCluster.testNodeLost
   TestSimTriggerIntegration.testEventFromRestoredState
   TestSimTriggerIntegration.testEventQueue
   TestSimTriggerIntegration.testNodeAddedTriggerRestoreState
   TestSimTriggerIntegration.testNodeLostTrigger
   TestStressCloudBlindAtomicUpdates.test_dv_idx


Will BadApple these
   Report   Pct runsfails   test
 0123   0.7 1818 10  AssignBackwardCompatibilityTest.test
 0123   0.5 1792  8
CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster
 0123   2.0 1869 37  LeaderVoteWaitTimeoutTest.basicTest
 0123   2.0 1869 39
LeaderVoteWaitTimeoutTest.testMostInSyncReplicasCanWinElection
 0123   3.0 1012 46  MoveReplicaHDFSTest.testFailedMove
 0123   0.2 1789  4  OverseerRolesTest.testOverseerRole
 0123   1.6 1146 18  SolrRrdBackendFactoryTest.testBasic
 0123   0.5 1811 10  StreamingTest.testParallelMergeStream
 0123   0.2 1811  4  StreamingTest.testZeroParallelReducerStream
 0123   4.7 1044 44  StressHdfsTest(suite)
 0123   0.2 1793  4
TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader
 0123   0.2 1823  4  TestLatLonPolygonShapeQueries(suite)
 0123  11.5  113  9  TestLatLonPolygonShapeQueries.testRandomBig
 0123   2.3 1698 12  TestStressRecovery(suite)
 0123   2.2 1703 12  TestStressRecovery.testStressRecovery
 0123   0.2 1777  4  TestTlogReplica(suite)
 0123   1.6 1647 34  ZookeeperStatusHandlerTest(suite)
 0123   1.6 1650 32  ZookeeperStatusHandlerTest.monitorZookeeper
DO NOT ENABLE LIST:
'TestControlledRealTimeReopenThread.testCRTReopen'
'TestICUNormalizer2CharFilter.testRandomStrings'
'TestICUTokenizerCJK'
'TestImpersonationWithHadoopAuth.testForwarding'
'TestLTRReRankingPipeline.testDifferentTopN'
'TestRandomChains'


DO NOT ANNOTATE LIST
CdcrBidirectionalTest.testBiDir
IndexSizeTriggerTest.testMergeIntegration
IndexSizeTriggerTest.testMixedBounds
IndexSizeTriggerTest.testSplitIntegration
IndexSizeTriggerTest.testTrigger
InfixSuggestersTest.testShutdownDuringBuild
MaxSizeAutoCommitTest
ShardSplitTest.test
ShardSplitTest.testSplitMixedReplicaTypes
ShardSplitTest.testSplitWithChaosMonkey
TestLatLonShapeQueries.testRandomBig
TestRandomChains.testRandomChainsWithLargeStrings
TestTriggerIntegration.testSearchRate
TestWithCollection

Processing file (History bit 3): HOSS-2018-09-03.csv
Processing file (History bit 2): HOSS-2018-08-27.csv
Processing file (History bit 1): HOSS-2018-08-20.csv
Processing file (History bit 0): HOSS-2018-08-13.csv


**Annotated tests/suites that didn't fail in the last 4 weeks.

  **Tests and suites removed from the next two lists because they were 
specified in 'doNotEnable' in the properties file
 no tests removed

  **Annotations will be removed from the following tests because they haven't 
failed in the last 4 rollups.

  **Methods: 33
   CdcrBootstrapTest.testConvertClusterToCdcrAndBootstrap
   CloudSolrClientTest.preferLocalShardsTest
   CollectionsAPIAsyncDistributedZkTest.testAsyncIdRaceCondition
   ComputePlanActionTest.testNodeLost
   DeleteShardTest.testDirectoryCleanupAfterDeleteShard
   DistributedMLTComponentTest.test
   

[ANNOUNCE] Apache PyLucene 7.4.0

[Andi Vajda]

I am pleased to announce the availability of Apache PyLucene 7.4.0.

New in this release: Lucene 7 support.

Apache PyLucene, a subproject of Apache Lucene, is a Python extension for
accessing Apache Lucene Core. Its goal is to allow you to use Lucene's text
indexing and searching capabilities from Python. It is API compatible with
the latest version of Lucene 7.x Core, 7.4.0.

For changes in this release, please review:
http://svn.apache.org/repos/asf/lucene/pylucene/tags/pylucene_7_4_0/CHANGES
http://svn.apache.org/repos/asf/lucene/pylucene/tags/pylucene_7_4_0/jcc/CHANGES
http://lucene.apache.org/core/7_4_0/changes/Changes.html

Apache PyLucene is available from the following download page:
http://www.apache.org/dyn/closer.cgi/lucene/pylucene/pylucene-7.4.0-src.tar.gz

When downloading from a mirror site, please remember to verify the downloads
using signatures found on the Apache site:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS

For more information on Apache PyLucene, visit the project home page:
  http://lucene.apache.org/pylucene

Andi..

Re: [VOTE] Release PyLucene 7.4.0 (rc1)

[Andi Vajda]

This vote has passed !
Thank you all who voted and made this release possible.

Andi..

On Tue, 28 Aug 2018, Andi Vajda wrote:



The PyLucene 7.4.0 (rc1) release tracking the recent release of
Apache Lucene 7.4.0 is ready.

A release candidate is available from:
 https://dist.apache.org/repos/dist/dev/lucene/pylucene/7.4.0-rc1/

PyLucene 7.4.0 is built with JCC 3.2 included in these release artifacts.

JCC 3.2 supports Python 3.3+ (in addition to Python 2.3+).
PyLucene may be built with Python 2 or Python 3.

Please vote to release these artifacts as PyLucene 7.4.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[jira] [Resolved] (SOLR-12195) Remove deprecated SolrRequest#setBasicAuthCredentials methods

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SOLR-12195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl resolved SOLR-12195.

   Resolution: Invalid
Fix Version/s: (was: master (8.0))

Won't remove these

> Remove deprecated SolrRequest#setBasicAuthCredentials methods
> -
>
> Key: SOLR-12195
> URL: https://issues.apache.org/jira/browse/SOLR-12195
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
>
> Followup for SOLR-12194. This will remove the deprecated SolrJ code from v8.0.
> This should also provide better refguide docs on the topic.



--
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-8476) Bug fix and optimizations in UserDictionary(KoreanAnalyzer)

[Jim Ferenczi (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602459#comment-16602459
 ] 

Jim Ferenczi commented on LUCENE-8476:
--

The reader is directly passed to the create method so it is the responsibility 
of the caller to properly close it after the build (see 
KoreanTokenizerFactory#inform). A comment should probably solve the confusion ?
+1 for the other changes, I'll push shortly. Thanks [~danmuzi]

>  Bug fix and optimizations in UserDictionary(KoreanAnalyzer)
> 
>
> Key: LUCENE-8476
> URL: https://issues.apache.org/jira/browse/LUCENE-8476
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Reporter: Namgyu Kim
>Priority: Major
>  Labels: bugfix, memory-leak, optimization, patch-available
> Attachments: LUCENE-8476.patch
>
>
> ■ Bug fix
> 1) BufferedReader's close method is not called.
> {code:java}
> // Line 57 method
> public static UserDictionary open(Reader reader) throws IOException {
>   BufferedReader br = new BufferedReader(reader);
>   String line = null;
>   List entries = new ArrayList<>();
>   // text + optional segmentations
>   while ((line = br.readLine()) != null) {
> ...
>   }
>   if (entries.isEmpty()) {
> return null;
>   } else {
> return new UserDictionary(entries);
>   }
> }{code}
> If you look at the code above, there is no close() method for the "br" 
> variable.
>  As I know, BufferedReader can cause a +memory leak+ if the close method is 
> not called.
>  So I changed the code below.
> {code:java}
> // Line 57 method
> public static UserDictionary open(Reader reader) throws IOException {
>   String line = null;
>   List entries = new ArrayList<>();
>   // text + optional segmentations
>   try (BufferedReader br = new BufferedReader(reader)) {
> while ((line = br.readLine()) != null) {
>   ...
> }
>   }
>   if (entries.isEmpty()) {
> return null;
>   } else {
> return new UserDictionary(entries);
>   }
> }
> {code}
> I solved this problem with 
> "[try-with-resources|https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html];
>  method available since Java 7.
>  
> ■ Optimizations
> 1) Change from Collections.sort to List.sort (UserDictionary constructor)
> {code:java}
> // Line 82 method
> private UserDictionary(List entries) throws IOException {
>   final CharacterDefinition charDef = CharacterDefinition.getInstance();
>   Collections.sort(entries,
>   Comparator.comparing(e -> e.split("\\s+")[0]));
>   PositiveIntOutputs fstOutput = PositiveIntOutputs.getSingleton();
>   ...
> }{code}
> List.sort in Java 8 is known to be faster than existing Collections.sort. 
> ([http://ankitsambyal.blogspot.com/2014/03/difference-between-listsort-and.html])
>  So I changed the code below.
> {code:java}
> // Line 82 method
> private UserDictionary(List entries) throws IOException {
>   final CharacterDefinition charDef = CharacterDefinition.getInstance();
>   entries.sort(Comparator.comparing(e -> e.split("\\s+")[0]));
>   PositiveIntOutputs fstOutput = PositiveIntOutputs.getSingleton();
>   ...
> }{code}
>  
> 2) Remove unnecessary null check (UserDictionary constructor)
> {code:java}
> // Line 82 method
> private UserDictionary(List entries) throws IOException {
>   ...
>   String lastToken = null;
>   ...
>   for (String entry : entries) {
> String[] splits = entry.split("\\s+");
> String token = splits[0];
> if (lastToken != null && token.equals(lastToken)) {
>   continue;
> }
> char lastChar = entry.charAt(entry.length()-1);
>   ...
> }{code}
> Looking at this part of the code,
> {code:java}
> if (lastToken != null && token.equals(lastToken)) {
>   continue;
> }{code}
> A null check for lastToken is unnecessary.
>  Because the equals method of the String class internally performs a null 
> check.
>  So I changed the code as below.
> {code:java}
> // Line 82 method
> private UserDictionary(List entries) throws IOException {
>   ...
>   String lastToken = null;
>   ...
>   for (String entry : entries) {
> String[] splits = entry.split("\\s+");
> String token = splits[0];
> if (token.equals(lastToken)) {
>   continue;
> }
> char lastChar = entry.charAt(entry.length()-1);
>   ...
> }{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: Lucene/Solr 8.0

[Adrien Grand]

For the record here is the JIRA query for blockers that Erick referred to:
https://issues.apache.org/jira/browse/SOLR-12720?jql=(project%3D%22Lucene%20-%20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocker%20and%20resolution%20%3D%20Unresolved%20

Le lun. 3 sept. 2018 à 10:36, jim ferenczi  a
écrit :

> Ok thanks Đạt and Erick. I'll follow the blockers on Jira.  Đạt do you
> have an issue opened for the HTTP/2 support ?
>
> Le ven. 31 août 2018 à 16:40, Erick Erickson  a
> écrit :
>
>> There's also the issue of what to do as far as removing Trie* support.
>> I think there's a blocker JIRA.
>>
>> project = SOLR AND priority = Blocker AND resolution = Unresolved
>>
>> Shows 6 blockers
>> On Fri, Aug 31, 2018 at 4:12 AM Đạt Cao Mạnh 
>> wrote:
>> >
>> > Hi Jim,
>> >
>> > I really want to introduce the support of HTTP/2 into Solr 8.0
>> (currently cooked in jira/http2 branch). The changes of that branch are
>> less than Star Burst effort and closer to be merged into master branch.
>> >
>> > Thanks!
>> >
>> > On Fri, Aug 31, 2018 at 3:55 PM jim ferenczi 
>> wrote:
>> >>
>> >> Hi all,
>> >> I'd like to get some feedback regarding the upcoming Lucene/Solr 8
>> release. There are still some cleanups and docs to add on the Lucene side
>> but it seems that all blockers are resolved.
>> >> From a Solr perspective are there any important changes that need to
>> be done or are we still good with the October target for the release ?
>> Adrien mentioned the Star Burst effort some time ago, is it something that
>> is planned for 8 ?
>> >>
>> >> Cheers,
>> >> Jim
>> >>
>> >> Le mer. 1 août 2018 à 19:02, David Smiley 
>> a écrit :
>> >>>
>> >>> Yes, that new BKD/Points based code is definitely something we want
>> in 8 or 7.5 -- it's a big deal.  I think it would also be awesome if we had
>> highlighter that could use the Weight.matches() API -- again for either 7.5
>> or 8.  I'm working on this on the UnifiedHighlighter front and Alan from
>> other aspects.
>> >>> ~ David
>> >>>
>> >>> On Wed, Aug 1, 2018 at 12:51 PM Adrien Grand 
>> wrote:
>> 
>>  I was hoping that we would release some bits of this new support for
>> geo shapes in 7.5 already. We are already very close to being able to index
>> points, lines and polygons and query for intersection with an envelope. It
>> would be nice to add support for other relations (eg. disjoint) and queries
>> (eg. polygon) but the current work looks already useful to me.
>> 
>>  Le mer. 1 août 2018 à 17:00, Robert Muir  a écrit
>> :
>> >
>> > My only other suggestion is we may want to get Nick's shape stuff
>> into
>> > the sandbox module at least for 8.0 so that it can be tested out. I
>> > think it looks like that wouldn't delay any October target though?
>> >
>> > On Wed, Aug 1, 2018 at 9:51 AM, Adrien Grand 
>> wrote:
>> > > I'd like to revive this thread now that these new optimizations
>> for
>> > > collection of top docs are more usable and enabled by default in
>> > > IndexSearcher (https://issues.apache.org/jira/browse/LUCENE-8060).
>> Any
>> > > feedback about starting to work towards releasing 8.0 and
>> targeting October
>> > > 2018?
>> > >
>> > >
>> > > Le jeu. 21 juin 2018 à 09:31, Adrien Grand  a
>> écrit :
>> > >>
>> > >> Hi Robert,
>> > >>
>> > >> I agree we need to make it more usable before 8.0. I would also
>> like to
>> > >> improve ReqOptSumScorer (
>> https://issues.apache.org/jira/browse/LUCENE-8204)
>> > >> to leverage impacts so that queries that incorporate queries on
>> feature
>> > >> fields (https://issues.apache.org/jira/browse/LUCENE-8197) in
>> an optional
>> > >> clause are also fast.
>> > >>
>> > >> Le jeu. 21 juin 2018 à 03:06, Robert Muir  a
>> écrit :
>> > >>>
>> > >>> How can the end user actually use the biggest new feature:
>> impacts and
>> > >>> BMW? As far as I can tell, the issue to actually implement the
>> > >>> necessary API changes (IndexSearcher/TopDocs/etc) is still open
>> and
>> > >>> unresolved, although there are some interesting ideas on it.
>> This
>> > >>> seems like a really big missing piece, without a proper API,
>> the stuff
>> > >>> is not really usable. I also can't imagine a situation where
>> the API
>> > >>> could be introduced in a followup minor release because it
>> would be
>> > >>> too invasive.
>> > >>>
>> > >>> On Mon, Jun 18, 2018 at 1:19 PM, Adrien Grand <
>> jpou...@gmail.com> wrote:
>> > >>> > Hi all,
>> > >>> >
>> > >>> > I would like to start discussing releasing Lucene/Solr 8.0.
>> Lucene 8
>> > >>> > already
>> > >>> > has some good changes around scoring, notably cleanups to
>> > >>> > similarities[1][2][3], indexing of impacts[4], and an
>> implementation of
>> > >>> > Block-Max WAND[5] which, once combined, allow to run queries
>> faster
>> > >>> > when
>> > >>> > total hit counts are not requested.

[jira] [Commented] (SOLR-12074) Add numeric typed equivalents to StrField

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602451#comment-16602451
 ] 

Adrien Grand commented on SOLR-12074:
-

bq. I think Lucene allows one field to have a Terms index & Points index

This is correct.

> Add numeric typed equivalents to StrField
> -
>
> Key: SOLR-12074
> URL: https://issues.apache.org/jira/browse/SOLR-12074
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: David Smiley
>Priority: Major
>  Labels: newdev, numeric-tries-to-points
>
> There ought to be numeric typed equivalents to StrField in the schema.  The 
> TrieField types can be configured to do this with precisionStep=0, but the 
> TrieFields are deprecated and slated for removal in 8.0.  PointFields may be 
> adequate for some use cases but, unlike TrieField, it's not as efficient for 
> simple field:value lookup queries.  They probably should use the same 
> internal sortable full-precision term format that TrieField uses (details 
> currently in {{LegacyNumericUtils}} (which are used by the deprecated Trie 
> 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] [Created] (LUCENE-8481) Javadocs should no longer reference RAMDirectory

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-8481:


 Summary: Javadocs should no longer reference RAMDirectory
 Key: LUCENE-8481
 URL: https://issues.apache.org/jira/browse/LUCENE-8481
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand


Since RAMDirectory is deprecated, we shouldn't show examples using it anymore. 
See eg. 
https://github.com/apache/lucene-solr/blob/a1ec716e107807f1dc24923cc7a91d0c5e64a7e1/lucene/core/src/java/overview.html#L36.
 cc [~dweiss]



--
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-8476) Bug fix and optimizations in UserDictionary(KoreanAnalyzer)

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602449#comment-16602449
 ] 

Adrien Grand commented on LUCENE-8476:
--

The problem with calling BufferedReader#close is that it will also close the 
underlying stream, which is unexpected? Other points make sense to me.

>  Bug fix and optimizations in UserDictionary(KoreanAnalyzer)
> 
>
> Key: LUCENE-8476
> URL: https://issues.apache.org/jira/browse/LUCENE-8476
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Reporter: Namgyu Kim
>Priority: Major
>  Labels: bugfix, memory-leak, optimization, patch-available
> Attachments: LUCENE-8476.patch
>
>
> ■ Bug fix
> 1) BufferedReader's close method is not called.
> {code:java}
> // Line 57 method
> public static UserDictionary open(Reader reader) throws IOException {
>   BufferedReader br = new BufferedReader(reader);
>   String line = null;
>   List entries = new ArrayList<>();
>   // text + optional segmentations
>   while ((line = br.readLine()) != null) {
> ...
>   }
>   if (entries.isEmpty()) {
> return null;
>   } else {
> return new UserDictionary(entries);
>   }
> }{code}
> If you look at the code above, there is no close() method for the "br" 
> variable.
>  As I know, BufferedReader can cause a +memory leak+ if the close method is 
> not called.
>  So I changed the code below.
> {code:java}
> // Line 57 method
> public static UserDictionary open(Reader reader) throws IOException {
>   String line = null;
>   List entries = new ArrayList<>();
>   // text + optional segmentations
>   try (BufferedReader br = new BufferedReader(reader)) {
> while ((line = br.readLine()) != null) {
>   ...
> }
>   }
>   if (entries.isEmpty()) {
> return null;
>   } else {
> return new UserDictionary(entries);
>   }
> }
> {code}
> I solved this problem with 
> "[try-with-resources|https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html];
>  method available since Java 7.
>  
> ■ Optimizations
> 1) Change from Collections.sort to List.sort (UserDictionary constructor)
> {code:java}
> // Line 82 method
> private UserDictionary(List entries) throws IOException {
>   final CharacterDefinition charDef = CharacterDefinition.getInstance();
>   Collections.sort(entries,
>   Comparator.comparing(e -> e.split("\\s+")[0]));
>   PositiveIntOutputs fstOutput = PositiveIntOutputs.getSingleton();
>   ...
> }{code}
> List.sort in Java 8 is known to be faster than existing Collections.sort. 
> ([http://ankitsambyal.blogspot.com/2014/03/difference-between-listsort-and.html])
>  So I changed the code below.
> {code:java}
> // Line 82 method
> private UserDictionary(List entries) throws IOException {
>   final CharacterDefinition charDef = CharacterDefinition.getInstance();
>   entries.sort(Comparator.comparing(e -> e.split("\\s+")[0]));
>   PositiveIntOutputs fstOutput = PositiveIntOutputs.getSingleton();
>   ...
> }{code}
>  
> 2) Remove unnecessary null check (UserDictionary constructor)
> {code:java}
> // Line 82 method
> private UserDictionary(List entries) throws IOException {
>   ...
>   String lastToken = null;
>   ...
>   for (String entry : entries) {
> String[] splits = entry.split("\\s+");
> String token = splits[0];
> if (lastToken != null && token.equals(lastToken)) {
>   continue;
> }
> char lastChar = entry.charAt(entry.length()-1);
>   ...
> }{code}
> Looking at this part of the code,
> {code:java}
> if (lastToken != null && token.equals(lastToken)) {
>   continue;
> }{code}
> A null check for lastToken is unnecessary.
>  Because the equals method of the String class internally performs a null 
> check.
>  So I changed the code as below.
> {code:java}
> // Line 82 method
> private UserDictionary(List entries) throws IOException {
>   ...
>   String lastToken = null;
>   ...
>   for (String entry : entries) {
> String[] splits = entry.split("\\s+");
> String token = splits[0];
> if (token.equals(lastToken)) {
>   continue;
> }
> char lastChar = entry.charAt(entry.length()-1);
>   ...
> }{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-8340) Efficient boosting by recency

[Adrien Grand (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adrien Grand updated LUCENE-8340:
-
Summary: Efficient boosting by recency  (was: Allow to boost by recency)

> Efficient boosting by recency
> -
>
> Key: LUCENE-8340
> URL: https://issues.apache.org/jira/browse/LUCENE-8340
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8340.patch
>
>
> I would like that we support something like 
> \{{FeatureField.newSaturationQuery}} but that works with features that are 
> computed dynamically like recency or geo-distance, and is still optimized for 
> top-hits collection. I'm starting with recency because it makes things a bit 
> easier even though I suspect that geo-distance might be a more common need.



--
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-8478) combine TermScorer constructors' implementation

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602446#comment-16602446
 ] 

Adrien Grand commented on LUCENE-8478:
--

I'm not sure this is a net win since it requires the addition of a 3rd 
constructor, which has a bizarre API since you need to pass null as the 
iterator to use the ImpactsDisi while it would be more natural to expect 
callers to pass the ImpactsDisi instead, even though I understand why it is not 
possible here. Maybe we could clarify with comments instead?

> combine TermScorer constructors' implementation
> ---
>
> Key: LUCENE-8478
> URL: https://issues.apache.org/jira/browse/LUCENE-8478
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: master (8.0)
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-8478.patch
>
>
> We currently have two {{TermScorer}} constructor variants and it's not 
> immediately obvious how and why their implementations are the way they are as 
> far as initialisations and initialisation order is concerned. Combination of 
> the logic could make the commonalities and differences clearer.



--
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-8479) QueryBuilder#analyzeGraphPhrase should respect max boolean clause

[Lucene/Solr QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602444#comment-16602444
 ] 

Lucene/Solr QA commented on LUCENE-8479:


| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
21s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 18s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 11m 
26s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 13m 34s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8479 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12938163/LUCENE-8479.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.4.0-130-generic #156~14.04.1-Ubuntu SMP Thu 
Jun 14 13:51:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 1acfca5 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_172 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/83/testReport/ |
| modules | C: lucene/core U: lucene/core |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/83/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> QueryBuilder#analyzeGraphPhrase should respect max boolean clause
> -
>
> Key: LUCENE-8479
> URL: https://issues.apache.org/jira/browse/LUCENE-8479
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8479.patch
>
>
> Currently there is no limit in the number of span queries that can be mixed 
> by QueryBuilder#analyzeGraphPhrase even if the input graph contains thousands 
> of paths. We should apply the same limit than analyzeGraphBoolean which 
> throws TooManyClauses exception when the number of expanded paths is greater 
> than BooleanQuery#MAX_CLAUSE_COUNT.



--
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-8480) Completion regex query uses UTF32 automaton

[Jim Ferenczi (JIRA)]

Jim Ferenczi created LUCENE-8480:


 Summary: Completion regex query uses UTF32 automaton
 Key: LUCENE-8480
 URL: https://issues.apache.org/jira/browse/LUCENE-8480
 Project: Lucene - Core
  Issue Type: Test
Reporter: Jim Ferenczi


The completion regex query builds an UTF-32 automaton but the completion FST 
uses UTF-8 internally. This makes the matching of any non basic latin character 
impossible in a regex completion query. 



--
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-8422) Add Matches iteration to interval queries

[Alan Woodward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Woodward resolved LUCENE-8422.
---
   Resolution: Fixed
Fix Version/s: 7.5

> Add Matches iteration to interval queries
> -
>
> Key: LUCENE-8422
> URL: https://issues.apache.org/jira/browse/LUCENE-8422
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.5
>
> Attachments: LUCENE-8422.patch, LUCENE-8422.patch, LUCENE-8422.patch
>
>
> Follow up to LUCENE-8404, we can now add Matches iteration to interval 
> queries in the sandbox.



--
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-8422) Add Matches iteration to interval queries

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602433#comment-16602433
 ] 

ASF subversion and git services commented on LUCENE-8422:
-

Commit 1acfca5ebcc4eb8600fe0fc0def160f610866f72 in lucene-solr's branch 
refs/heads/master from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1acfca5 ]

LUCENE-8422: Add matches to IntervalQuery


> Add Matches iteration to interval queries
> -
>
> Key: LUCENE-8422
> URL: https://issues.apache.org/jira/browse/LUCENE-8422
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.5
>
> Attachments: LUCENE-8422.patch, LUCENE-8422.patch, LUCENE-8422.patch
>
>
> Follow up to LUCENE-8404, we can now add Matches iteration to interval 
> queries in the sandbox.



--
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-8422) Add Matches iteration to interval queries

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602432#comment-16602432
 ] 

ASF subversion and git services commented on LUCENE-8422:
-

Commit 9c0075be562b323942c52026bf89265e6ba2543e in lucene-solr's branch 
refs/heads/branch_7x from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9c0075b ]

LUCENE-8422: Add matches to IntervalQuery


> Add Matches iteration to interval queries
> -
>
> Key: LUCENE-8422
> URL: https://issues.apache.org/jira/browse/LUCENE-8422
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.5
>
> Attachments: LUCENE-8422.patch, LUCENE-8422.patch, LUCENE-8422.patch
>
>
> Follow up to LUCENE-8404, we can now add Matches iteration to interval 
> queries in the sandbox.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-12699) make LTRScoringModel immutable (to allow hashCode caching)

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602383#comment-16602383
 ] 

Edward Ribeiro edited comment on SOLR-12699 at 9/3/18 6:26 PM:
---

Hi [~cpoerschke] and [~slivotov],

Just a nitpick: wrapping a collection in a Collections.unmodifiable* doesn't 
make the collection strictly immutable. See, we are receiving `features` as a 
parameter. Therefore, some code that still has a reference to that object can 
change it underneath. Example:
{code:java}
List mutableList = new ArrayList<>();
mutableList.add("Hello");
mutableList.add("World");

List immutableList = Collections.unmodifiableList(mutableList);

System.out.println("immutableList = " + immutableList);

mutableList.add("!");

System.out.println("list2 = " + immutableList);{code}
 

As collections is a wrapper I could change it by modifying the `mutableList`. 
AFAIK, to make it a real immutable collection it would be required to create a 
defensive copy of the collection like below:
{code:java}
List immutableList = Collections.unmodifiableList(new 
ArrayList<>(mutableList));{code}
 

Now the elements of mutableList are copied to a new ArrayList that we don't 
have reference. Therefore we cannot change its elements even tough as you 
pointed out, we could change fields of the objects in the collection. *The 
problem with this approach is that if `features` is a large collection this 
could impact the performance, so be cautions when using it.*

Finally, this line
{code:java}
this.features = features != null ? Collections.unmodifiableList(features) : 
features;{code}
 

`this.features` receives `null` if `features` is `null`. Is that the intended 
behaviour? Wouldn't be better to make it be `Lists.emptyList()` if `features` 
is null? Excuse me if I am missing something, but it's usually an anti-pattern 
to return null, but I am very well aware that the codebases in the wild usually 
don't follow this advice.

 

Finally, the hashCode can be written as:
{code:java}
result = (prime * result) + Objects.hashCode(features){code}
 

It will automatically return 0 (zero) if features is null or the hash code of 
the collection otherwise. 


was (Author: eribeiro):
Hi [~cpoerschke] and [~slivotov],

Just a nitpick: wrapping a collection in a Collections.unmodifiable* doesn't 
make the collection strictly immutable. See, we are receiving `features` as a 
parameter. Therefore, some code that still has a reference to that object can 
change it underneath. Example:
{code:java}
List mutableList = new ArrayList<>();
mutableList.add("Hello");
mutableList.add("World");

List immutableList = Collections.unmodifiableList(mutableList);

System.out.println("immutableList = " + immutableList);

mutableList.add("!");

System.out.println("list2 = " + immutableList);{code}
 

As collections is a wrapper I could change it by modifying the `mutableList`. 
AFAIK, to make it a real immutable collection it would be required to create a 
defensive copy of the collection like below:
{code:java}
List immutableList = Collections.unmodifiableList(new 
ArrayList<>(mutableList));{code}
 

Now the elements of mutableList are copied to a new ArrayList that we don't 
have reference. Therefore we cannot change its elements even tough as you 
pointed out, we could change fields of the objects in the collection. *The 
problem with this approach is that if `features` is a large collection this 
could impact the performance, so be cautions when using it.*

Finally, this line
{code:java}
this.features = features != null ? Collections.unmodifiableList(features) : 
features;{code}
 

`this.features` receives `null` if `features` is `null`. Is that the intended 
behaviour? Wouldn't be better to make it be `Lists.emptyList()` if `features` 
is null? Excuse me if I am missing something, but it's usually an anti-pattern 
to return null, but I am very well aware that the codebases in the wild usually 
don't follow this advice.

 

> make LTRScoringModel immutable (to allow hashCode caching)
> --
>
> Key: SOLR-12699
> URL: https://issues.apache.org/jira/browse/SOLR-12699
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Stanislav Livotov
>Priority: Major
> Attachments: SOLR-12699.patch, SOLR-12699.patch, SOLR-12699.patch
>
>
> [~slivotov] wrote in SOLR-12688:
> bq. ... LTRScoringModel was a mutable object. It was leading to the 
> calculation of hashcode on each query, which in turn can consume a lot of 
> time ... So I decided to make LTRScoringModel immutable and cache hashCode 
> calculation. ...
> (Please see SOLR-12688 description for overall context and analysis results.)



--
This message was sent by 

[jira] [Commented] (SOLR-12699) make LTRScoringModel immutable (to allow hashCode caching)

[Edward Ribeiro (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602383#comment-16602383
 ] 

Edward Ribeiro commented on SOLR-12699:
---

Hi [~cpoerschke] and [~slivotov],

Just a nitpick: wrapping a collection in a Collections.unmodifiable* doesn't 
make the collection strictly immutable. See, we are receiving `features` as a 
parameter. Therefore, some code that still has a reference to that object can 
change it underneath. Example:
{code:java}
List mutableList = new ArrayList<>();
mutableList.add("Hello");
mutableList.add("World");

List immutableList = Collections.unmodifiableList(mutableList);

System.out.println("immutableList = " + immutableList);

mutableList.add("!");

System.out.println("list2 = " + immutableList);{code}
 

As collections is a wrapper I could change it by modifying the `mutableList`. 
AFAIK, to make it a real immutable collection it would be required to create a 
defensive copy of the collection like below:
{code:java}
List immutableList = Collections.unmodifiableList(new 
ArrayList<>(mutableList));{code}
 

Now the elements of mutableList are copied to a new ArrayList that we don't 
have reference. Therefore we cannot change its elements even tough as you 
pointed out, we could change fields of the objects in the collection. *The 
problem with this approach is that if `features` is a large collection this 
could impact the performance, so be cautions when using it.*

Finally, this line
{code:java}
this.features = features != null ? Collections.unmodifiableList(features) : 
features;{code}
 

`this.features` receives `null` if `features` is `null`. Is that the intended 
behaviour? Wouldn't be better to make it be `Lists.emptyList()` if `features` 
is null? Excuse me if I am missing something, but it's usually an anti-pattern 
to return null, but I am very well aware that the codebases in the wild usually 
don't follow this advice.

 

> make LTRScoringModel immutable (to allow hashCode caching)
> --
>
> Key: SOLR-12699
> URL: https://issues.apache.org/jira/browse/SOLR-12699
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Stanislav Livotov
>Priority: Major
> Attachments: SOLR-12699.patch, SOLR-12699.patch, SOLR-12699.patch
>
>
> [~slivotov] wrote in SOLR-12688:
> bq. ... LTRScoringModel was a mutable object. It was leading to the 
> calculation of hashcode on each query, which in turn can consume a lot of 
> time ... So I decided to make LTRScoringModel immutable and cache hashCode 
> calculation. ...
> (Please see SOLR-12688 description for overall context and analysis 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

[jira] [Resolved] (SOLR-12726) [Ref-Guide] Wrong documentation for solrcloud-autoscaling-overview.doc

[Mikhail Khludnev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev resolved SOLR-12726.
-
   Resolution: Fixed
Fix Version/s: 7.5
   master (8.0)

>  [Ref-Guide] Wrong documentation for solrcloud-autoscaling-overview.doc
> ---
>
> Key: SOLR-12726
> URL: https://issues.apache.org/jira/browse/SOLR-12726
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.1, 7.2, 7.3, 7.4
>Reporter: Zouheir CADI
>Assignee: Mikhail Khludnev
>Priority: Minor
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12726.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In my understanding, since version 7.1 and the creation of Triggers and 
> TriggerActions, the bold text below in not necessary since management 
> operations will be invoked automatically. There is no patch to submit. The 
> text has just to be removed.
> *Cluster management operations are currently invoked manually. In the future, 
> these cluster management operations may be invoked automatically in response 
> to cluster events such as a node being added or lost 
> ([link|https://lucene.apache.org/solr/guide/7_4/solrcloud-autoscaling-overview.html]).*
>  
>  



--
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-12726) [Ref-Guide] Wrong documentation for solrcloud-autoscaling-overview.doc

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602376#comment-16602376
 ] 

Mikhail Khludnev commented on SOLR-12726:
-

Thanks, everybody. 

>  [Ref-Guide] Wrong documentation for solrcloud-autoscaling-overview.doc
> ---
>
> Key: SOLR-12726
> URL: https://issues.apache.org/jira/browse/SOLR-12726
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.1, 7.2, 7.3, 7.4
>Reporter: Zouheir CADI
>Assignee: Mikhail Khludnev
>Priority: Minor
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12726.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In my understanding, since version 7.1 and the creation of Triggers and 
> TriggerActions, the bold text below in not necessary since management 
> operations will be invoked automatically. There is no patch to submit. The 
> text has just to be removed.
> *Cluster management operations are currently invoked manually. In the future, 
> these cluster management operations may be invoked automatically in response 
> to cluster events such as a node being added or lost 
> ([link|https://lucene.apache.org/solr/guide/7_4/solrcloud-autoscaling-overview.html]).*
>  
>  



--
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-8479) QueryBuilder#analyzeGraphPhrase should respect max boolean clause

[Jim Ferenczi (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602369#comment-16602369
 ] 

Jim Ferenczi commented on LUCENE-8479:
--

Here is a patch that applies BooleanQuery#MAX_CLAUSE_COUNT limit to the SpanOr 
queries that analyzeGraphPhrase creates.

> QueryBuilder#analyzeGraphPhrase should respect max boolean clause
> -
>
> Key: LUCENE-8479
> URL: https://issues.apache.org/jira/browse/LUCENE-8479
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8479.patch
>
>
> Currently there is no limit in the number of span queries that can be mixed 
> by QueryBuilder#analyzeGraphPhrase even if the input graph contains thousands 
> of paths. We should apply the same limit than analyzeGraphBoolean which 
> throws TooManyClauses exception when the number of expanded paths is greater 
> than BooleanQuery#MAX_CLAUSE_COUNT.



--
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-8479) QueryBuilder#analyzeGraphPhrase should respect max boolean clause

[Jim Ferenczi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jim Ferenczi updated LUCENE-8479:
-
Lucene Fields: New,Patch Available  (was: New)

> QueryBuilder#analyzeGraphPhrase should respect max boolean clause
> -
>
> Key: LUCENE-8479
> URL: https://issues.apache.org/jira/browse/LUCENE-8479
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8479.patch
>
>
> Currently there is no limit in the number of span queries that can be mixed 
> by QueryBuilder#analyzeGraphPhrase even if the input graph contains thousands 
> of paths. We should apply the same limit than analyzeGraphBoolean which 
> throws TooManyClauses exception when the number of expanded paths is greater 
> than BooleanQuery#MAX_CLAUSE_COUNT.



--
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-8479) QueryBuilder#analyzeGraphPhrase should respect max boolean clause

[Jim Ferenczi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jim Ferenczi updated LUCENE-8479:
-
Attachment: LUCENE-8479.patch

> QueryBuilder#analyzeGraphPhrase should respect max boolean clause
> -
>
> Key: LUCENE-8479
> URL: https://issues.apache.org/jira/browse/LUCENE-8479
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8479.patch
>
>
> Currently there is no limit in the number of span queries that can be mixed 
> by QueryBuilder#analyzeGraphPhrase even if the input graph contains thousands 
> of paths. We should apply the same limit than analyzeGraphBoolean which 
> throws TooManyClauses exception when the number of expanded paths is greater 
> than BooleanQuery#MAX_CLAUSE_COUNT.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-12728) RequestLoggingTest fails on occasion, not reproducible

[Erick Erickson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson resolved SOLR-12728.
---
   Resolution: Fixed
Fix Version/s: 7.5
   master (8.0)

Beasted 1,000 times again on the machine where it failed the first time, no 
failures.

Anybody see errors in other tests related to not finding the expected logging 
message, please let me know as they probably related to SOLR-12055.

> RequestLoggingTest fails on occasion, not reproducible
> --
>
> Key: SOLR-12728
> URL: https://issues.apache.org/jira/browse/SOLR-12728
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12728.patch, SOLR-12728.patch
>
>
> I'm getting about a 1.5% failure rate in RequestLoggingTest, I strongly 
> suspect it's a result of the async logging changed from SOLR-12055, digging...
> I suspect this is largely a test artifact, and it doesn't reproduce reliably.



--
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-8479) QueryBuilder#analyzeGraphPhrase should respect max boolean clause

[Jim Ferenczi (JIRA)]

Jim Ferenczi created LUCENE-8479:


 Summary: QueryBuilder#analyzeGraphPhrase should respect max 
boolean clause
 Key: LUCENE-8479
 URL: https://issues.apache.org/jira/browse/LUCENE-8479
 Project: Lucene - Core
  Issue Type: Test
Reporter: Jim Ferenczi


Currently there is no limit in the number of span queries that can be mixed by 
QueryBuilder#analyzeGraphPhrase even if the input graph contains thousands of 
paths. We should apply the same limit than analyzeGraphBoolean which throws 
TooManyClauses exception when the number of expanded paths is greater than 
BooleanQuery#MAX_CLAUSE_COUNT.



--
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-12728) RequestLoggingTest fails on occasion, not reproducible

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602367#comment-16602367
 ] 

ASF subversion and git services commented on SOLR-12728:


Commit d3e6fb5bff5affab449b4be347e587d02134a9d5 in lucene-solr's branch 
refs/heads/branch_7x from [~cp.erick...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d3e6fb5 ]

SOLR-12728: RequestLoggingTest fails on occasion, not reproducible

(cherry picked from commit 74b53b1a6756f106ec281dc6ef9bc52f7d989384)


> RequestLoggingTest fails on occasion, not reproducible
> --
>
> Key: SOLR-12728
> URL: https://issues.apache.org/jira/browse/SOLR-12728
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-12728.patch, SOLR-12728.patch
>
>
> I'm getting about a 1.5% failure rate in RequestLoggingTest, I strongly 
> suspect it's a result of the async logging changed from SOLR-12055, digging...
> I suspect this is largely a test artifact, and it doesn't reproduce reliably.



--
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-12728) RequestLoggingTest fails on occasion, not reproducible

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602363#comment-16602363
 ] 

ASF subversion and git services commented on SOLR-12728:


Commit 74b53b1a6756f106ec281dc6ef9bc52f7d989384 in lucene-solr's branch 
refs/heads/master from [~cp.erick...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=74b53b1 ]

SOLR-12728: RequestLoggingTest fails on occasion, not reproducible


> RequestLoggingTest fails on occasion, not reproducible
> --
>
> Key: SOLR-12728
> URL: https://issues.apache.org/jira/browse/SOLR-12728
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-12728.patch, SOLR-12728.patch
>
>
> I'm getting about a 1.5% failure rate in RequestLoggingTest, I strongly 
> suspect it's a result of the async logging changed from SOLR-12055, digging...
> I suspect this is largely a test artifact, and it doesn't reproduce reliably.



--
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-12728) RequestLoggingTest fails on occasion, not reproducible

[Erick Erickson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-12728:
--
Attachment: SOLR-12728.patch

> RequestLoggingTest fails on occasion, not reproducible
> --
>
> Key: SOLR-12728
> URL: https://issues.apache.org/jira/browse/SOLR-12728
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-12728.patch, SOLR-12728.patch
>
>
> I'm getting about a 1.5% failure rate in RequestLoggingTest, I strongly 
> suspect it's a result of the async logging changed from SOLR-12055, digging...
> I suspect this is largely a test artifact, and it doesn't reproduce reliably.



--
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-12699) make LTRScoringModel immutable (to allow hashCode caching)

[Stanislav Livotov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stanislav Livotov updated SOLR-12699:
-
Attachment: (was: SOLR_12699.patch)

> make LTRScoringModel immutable (to allow hashCode caching)
> --
>
> Key: SOLR-12699
> URL: https://issues.apache.org/jira/browse/SOLR-12699
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Stanislav Livotov
>Priority: Major
> Attachments: SOLR-12699.patch, SOLR-12699.patch, SOLR-12699.patch
>
>
> [~slivotov] wrote in SOLR-12688:
> bq. ... LTRScoringModel was a mutable object. It was leading to the 
> calculation of hashcode on each query, which in turn can consume a lot of 
> time ... So I decided to make LTRScoringModel immutable and cache hashCode 
> calculation. ...
> (Please see SOLR-12688 description for overall context and analysis 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

[jira] [Updated] (SOLR-12699) make LTRScoringModel immutable (to allow hashCode caching)

[Stanislav Livotov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stanislav Livotov updated SOLR-12699:
-
Attachment: SOLR-12699.patch

> make LTRScoringModel immutable (to allow hashCode caching)
> --
>
> Key: SOLR-12699
> URL: https://issues.apache.org/jira/browse/SOLR-12699
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Stanislav Livotov
>Priority: Major
> Attachments: SOLR-12699.patch, SOLR-12699.patch, SOLR-12699.patch
>
>
> [~slivotov] wrote in SOLR-12688:
> bq. ... LTRScoringModel was a mutable object. It was leading to the 
> calculation of hashcode on each query, which in turn can consume a lot of 
> time ... So I decided to make LTRScoringModel immutable and cache hashCode 
> calculation. ...
> (Please see SOLR-12688 description for overall context and analysis 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

[jira] [Updated] (SOLR-12699) make LTRScoringModel immutable (to allow hashCode caching)

[Stanislav Livotov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stanislav Livotov updated SOLR-12699:
-
Attachment: SOLR_12699.patch

> make LTRScoringModel immutable (to allow hashCode caching)
> --
>
> Key: SOLR-12699
> URL: https://issues.apache.org/jira/browse/SOLR-12699
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Stanislav Livotov
>Priority: Major
> Attachments: SOLR-12699.patch, SOLR-12699.patch, SOLR-12699.patch
>
>
> [~slivotov] wrote in SOLR-12688:
> bq. ... LTRScoringModel was a mutable object. It was leading to the 
> calculation of hashcode on each query, which in turn can consume a lot of 
> time ... So I decided to make LTRScoringModel immutable and cache hashCode 
> calculation. ...
> (Please see SOLR-12688 description for overall context and analysis 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

Re: Lucene/Solr 7.5

[Erick Erickson]

I'm working on "SOLR-12727: Upgrade ZooKeeper dependency to 3.4.13...
will make the ZK client re-resolve the server hostnames when a
connection fails. This will fix issues where a failed ZK container is
replaced with a new one that has a different IP address and DNS gets
updated with the new address."

I've already done the upgrade locally, but got distracted when one of
the test failures turned out to be related to async logging
(SOLR-12728)...

I guess my question is whether to try to get this in 7.5 in the next
day or two or wait until 7.6. We've lived with this issue since the
first release of SolrCloud, so it's not pressing

WDYT?
On Mon, Sep 3, 2018 at 5:53 AM Adrien Grand  wrote:
>
> +1 too
>
> Alan, I just left comments on LUCENE-8422.
>
> Le lun. 3 sept. 2018 à 10:50, Alan Woodward  a écrit :
>>
>> +1
>>
>> I’d like to get Matches added to intervals, if anybody feels like reviewing 
>> https://issues.apache.org/jira/browse/LUCENE-8422 before the branch is cut.
>>
>>
>> On 3 Sep 2018, at 09:42, jim ferenczi  wrote:
>>
>> Hi all,
>>
>> 7.4 has been released two months ago on June 29th and we have new features, 
>> enhancements and fixes that are not released yet so I'd like to start 
>> working on releasing Lucene/Solr 7.5.0.
>> There's also a bad bug with index sorting that deletes the wrong documents 
>> when delete by query is used:
>> https://issues.apache.org/jira/browse/LUCENE-8466
>>
>> I can create the 7.5 branch later this week and build the first RC early 
>> next week if that works for everyone. Please let me know if there are bug 
>> fixes that needs to be fixed in 7.5 and might not be ready by then.
>>
>> Cheers,
>> Jim
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12726) [Ref-Guide] Wrong documentation for solrcloud-autoscaling-overview.doc

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602355#comment-16602355
 ] 

ASF subversion and git services commented on SOLR-12726:


Commit 1ff9cbf4dbcaf0b0f3d9ec26a4e6ef5f37e1b414 in lucene-solr's branch 
refs/heads/branch_7x from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1ff9cbf ]

SOLR-12726: Removing obsolete sentences from SolrCloud Auto Scaling Ref Guide.


>  [Ref-Guide] Wrong documentation for solrcloud-autoscaling-overview.doc
> ---
>
> Key: SOLR-12726
> URL: https://issues.apache.org/jira/browse/SOLR-12726
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.1, 7.2, 7.3, 7.4
>Reporter: Zouheir CADI
>Assignee: Mikhail Khludnev
>Priority: Minor
> Attachments: SOLR-12726.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In my understanding, since version 7.1 and the creation of Triggers and 
> TriggerActions, the bold text below in not necessary since management 
> operations will be invoked automatically. There is no patch to submit. The 
> text has just to be removed.
> *Cluster management operations are currently invoked manually. In the future, 
> these cluster management operations may be invoked automatically in response 
> to cluster events such as a node being added or lost 
> ([link|https://lucene.apache.org/solr/guide/7_4/solrcloud-autoscaling-overview.html]).*
>  
>  



--
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-11834) [Ref-Guide] Wrong documentation for subquery transformer

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602354#comment-16602354
 ] 

ASF subversion and git services commented on SOLR-11834:


Commit f1182269f6caca4f6800aa123f8b405c21aabce0 in lucene-solr's branch 
refs/heads/branch_7x from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f118226 ]

SOLR-11834: rollback [subquery] fields documentation


> [Ref-Guide] Wrong documentation for subquery transformer
> 
>
> Key: SOLR-11834
> URL: https://issues.apache.org/jira/browse/SOLR-11834
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-11834.patch, SOLR-11834.patch, SOLR-11834.png
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Documentation for subquery transformation mentioned that to retrieve the 
> field, it should be specified in both fl parameter
> https://lucene.apache.org/solr/guide/7_2/transforming-result-documents.html#subquery-result-fields
> But there is no such restriction in 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-6228) Do not expose full-fledged scorers in LeafCollector.setScorer

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602352#comment-16602352
 ] 

Alan Woodward commented on LUCENE-6228:
---

Patch updated to latest master.

As a follow-up, we can remove FakeScorer and enforce Scorer.getWeight() to 
never be null, but this patch is big enough already.

> Do not expose full-fledged scorers in LeafCollector.setScorer
> -
>
> Key: LUCENE-6228
> URL: https://issues.apache.org/jira/browse/LUCENE-6228
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Major
> Fix For: 5.2, 6.0
>
> Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch, 
> LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch
>
>
> Currently LeafCollector.setScorer takes a Scorer, which I don't like because 
> several methods should never be called in the context of a Collector (like 
> nextDoc or advance).
> I think it's even more trappy for methods that might seem to work in some 
> particular cases but will not work in the general case, like getChildren 
> which will not work if you have a specialized BulkScorer or iterating over 
> positions which will not work if you are in a MultiCollector and another leaf 
> collector consumes positions too.
> So I think we should restrict what can be seen from a collector to avoid such 
> traps.



--
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-6228) Do not expose full-fledged scorers in LeafCollector.setScorer

[Alan Woodward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Woodward updated LUCENE-6228:
--
Attachment: LUCENE-6228.patch

> Do not expose full-fledged scorers in LeafCollector.setScorer
> -
>
> Key: LUCENE-6228
> URL: https://issues.apache.org/jira/browse/LUCENE-6228
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Major
> Fix For: 5.2, 6.0
>
> Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch, 
> LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch
>
>
> Currently LeafCollector.setScorer takes a Scorer, which I don't like because 
> several methods should never be called in the context of a Collector (like 
> nextDoc or advance).
> I think it's even more trappy for methods that might seem to work in some 
> particular cases but will not work in the general case, like getChildren 
> which will not work if you have a specialized BulkScorer or iterating over 
> positions which will not work if you are in a MultiCollector and another leaf 
> collector consumes positions too.
> So I think we should restrict what can be seen from a collector to avoid such 
> traps.



--
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-12726) [Ref-Guide] Wrong documentation for solrcloud-autoscaling-overview.doc

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602349#comment-16602349
 ] 

ASF subversion and git services commented on SOLR-12726:


Commit b4f9042a4347affc853f59e408422bcba45aad38 in lucene-solr's branch 
refs/heads/master from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b4f9042 ]

SOLR-12726: Removing obsolete sentences from SolrCloud Auto Scaling Ref Guide.


>  [Ref-Guide] Wrong documentation for solrcloud-autoscaling-overview.doc
> ---
>
> Key: SOLR-12726
> URL: https://issues.apache.org/jira/browse/SOLR-12726
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.1, 7.2, 7.3, 7.4
>Reporter: Zouheir CADI
>Assignee: Mikhail Khludnev
>Priority: Minor
> Attachments: SOLR-12726.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In my understanding, since version 7.1 and the creation of Triggers and 
> TriggerActions, the bold text below in not necessary since management 
> operations will be invoked automatically. There is no patch to submit. The 
> text has just to be removed.
> *Cluster management operations are currently invoked manually. In the future, 
> these cluster management operations may be invoked automatically in response 
> to cluster events such as a node being added or lost 
> ([link|https://lucene.apache.org/solr/guide/7_4/solrcloud-autoscaling-overview.html]).*
>  
>  



--
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

Test logging errors

[Erick Erickson]

SOLR-12728 started this chain of thought. The change to async logging
is going to mess with tests that assume they can change the logging
and immediately see the effects, RequestLoggingTest is the latest
example.

I'll be looking more closely at test failures to see if any mention
logging, but if anyone notices test failures due to the expected
logging message not being present, please ping me whether or not it's
reliably reproducible.

In fact I expect these will tend _not_ to reproduce reliably 'cause
it'll depend on how fast the async message actually gets to its
destination, but I can always hammer tests with Mark's beasting
script.

Erick

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12726) [Ref-Guide] Wrong documentation for solrcloud-autoscaling-overview.doc

[Shalin Shekhar Mangar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602316#comment-16602316
 ] 

Shalin Shekhar Mangar commented on SOLR-12726:
--

That comment is out of date. +1 to nuke it.

>  [Ref-Guide] Wrong documentation for solrcloud-autoscaling-overview.doc
> ---
>
> Key: SOLR-12726
> URL: https://issues.apache.org/jira/browse/SOLR-12726
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.1, 7.2, 7.3, 7.4
>Reporter: Zouheir CADI
>Assignee: Mikhail Khludnev
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In my understanding, since version 7.1 and the creation of Triggers and 
> TriggerActions, the bold text below in not necessary since management 
> operations will be invoked automatically. There is no patch to submit. The 
> text has just to be removed.
> *Cluster management operations are currently invoked manually. In the future, 
> these cluster management operations may be invoked automatically in response 
> to cluster events such as a node being added or lost 
> ([link|https://lucene.apache.org/solr/guide/7_4/solrcloud-autoscaling-overview.html]).*
>  
>  



--
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-8478) combine TermScorer constructors' implementation

[Christine Poerschke (JIRA)]

Christine Poerschke created LUCENE-8478:
---

 Summary: combine TermScorer constructors' implementation
 Key: LUCENE-8478
 URL: https://issues.apache.org/jira/browse/LUCENE-8478
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: master (8.0)
Reporter: Christine Poerschke
 Attachments: LUCENE-8478.patch

We currently have two {{TermScorer}} constructor variants and it's not 
immediately obvious how and why their implementations are the way they are as 
far as initialisations and initialisation order is concerned. Combination of 
the logic could make the commonalities and differences clearer.




--
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-8478) combine TermScorer constructors' implementation

[Christine Poerschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Poerschke updated LUCENE-8478:

Attachment: LUCENE-8478.patch

> combine TermScorer constructors' implementation
> ---
>
> Key: LUCENE-8478
> URL: https://issues.apache.org/jira/browse/LUCENE-8478
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: master (8.0)
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-8478.patch
>
>
> We currently have two {{TermScorer}} constructor variants and it's not 
> immediately obvious how and why their implementations are the way they are as 
> far as initialisations and initialisation order is concerned. Combination of 
> the logic could make the commonalities and differences clearer.



--
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-8340) Allow to boost by recency

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602299#comment-16602299
 ] 

Adrien Grand commented on LUCENE-8340:
--

So I went back to this patch and did some testing. I played with the 
wikimedium10m dataset and the following query (note that I had to do a hack to 
also index "lastModNDV" with a LongPoint):
{code:java}
Query boostedQ = new BooleanQuery.Builder()
.add(new TermQuery(new Term("body", "ref")), Occur.MUST)
.add(LongPoint.newDistanceFeatureQuery("lastModNDV", 1f, 
1335997132000L, 24 * 3600 * 1000), Occur.SHOULD) // within 1 day
.build();
{code}
The maximum score of the term query is 2.07. The maximum score of the distance 
query is 1, and there are 582,764 documents whose timestamp is in 
[1335997132000L - 24 * 3600 * 1000, 1335997132000L + 24 * 3600 * 1000], meaning 
their score is in [0.5, 1].

When computing the top 10 matches and counting hits, all 3793973 hits must be 
visited and points are never read. This takes about 99ms.
When computing the top 10 matches but not counting hits (totalHitsThreshold=1), 
only 264802 hits are collected (7% of matches) and the query runs in 29ms.

If I switch to more costly queries that have fewer hits then the speed up 
decreases, or even becomes a slowdown unfortunately. That said I don't think it 
should prevent us from adding something like that, which is a useful addition 
to the scoring toolbox.

> Allow to boost by recency
> -
>
> Key: LUCENE-8340
> URL: https://issues.apache.org/jira/browse/LUCENE-8340
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8340.patch
>
>
> I would like that we support something like 
> \{{FeatureField.newSaturationQuery}} but that works with features that are 
> computed dynamically like recency or geo-distance, and is still optimized for 
> top-hits collection. I'm starting with recency because it makes things a bit 
> easier even though I suspect that geo-distance might be a more common need.



--
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-8472) Soft-deletes merge retention query should be rewritten

[Nhat Nguyen (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602294#comment-16602294
 ] 

Nhat Nguyen commented on LUCENE-8472:
-

Thanks [~jpountz].

> Soft-deletes merge retention query should be rewritten
> --
>
> Key: LUCENE-8472
> URL: https://issues.apache.org/jira/browse/LUCENE-8472
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.4.1, 7.5, master (8.0)
>Reporter: Nhat Nguyen
>Priority: Minor
> Fix For: 7.4.1, 7.5, master (8.0)
>
> Attachments: LUCENE-8472.patch, LUCENE-8472.patch
>
>
> We should rewrite the retention query before passing it into createWeight in 
> SoftDeletesRetentionMergePolicy#getScorer method.



--
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-8472) Soft-deletes merge retention query should be rewritten

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602291#comment-16602291
 ] 

ASF subversion and git services commented on LUCENE-8472:
-

Commit c1259f8274ddfc4e138fb6b7de4f0f15872cff51 in lucene-solr's branch 
refs/heads/branch_7_4 from [~dnhatn]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c1259f8 ]

LUCENE-8472: Always rewrite soft-deletes retention query

This change ensures that we always rewrite the soft-deletes merge
retention policy before passing it into `createWeight` as some Query
does not support `createWeight` directly.


> Soft-deletes merge retention query should be rewritten
> --
>
> Key: LUCENE-8472
> URL: https://issues.apache.org/jira/browse/LUCENE-8472
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.4.1, 7.5, master (8.0)
>Reporter: Nhat Nguyen
>Priority: Minor
> Attachments: LUCENE-8472.patch, LUCENE-8472.patch
>
>
> We should rewrite the retention query before passing it into createWeight in 
> SoftDeletesRetentionMergePolicy#getScorer method.



--
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-8472) Soft-deletes merge retention query should be rewritten

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602278#comment-16602278
 ] 

ASF subversion and git services commented on LUCENE-8472:
-

Commit 39b1d5968029d010a39fd3d43a307745e3a2f3a3 in lucene-solr's branch 
refs/heads/branch_7x from [~dnhatn]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=39b1d59 ]

LUCENE-8472: Always rewrite soft-deletes retention query

This change ensures that we always rewrite the soft-deletes merge
retention policy before passing it into `createWeight` as some Query
does not support `createWeight` directly.


> Soft-deletes merge retention query should be rewritten
> --
>
> Key: LUCENE-8472
> URL: https://issues.apache.org/jira/browse/LUCENE-8472
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.4.1, 7.5, master (8.0)
>Reporter: Nhat Nguyen
>Priority: Minor
> Attachments: LUCENE-8472.patch, LUCENE-8472.patch
>
>
> We should rewrite the retention query before passing it into createWeight in 
> SoftDeletesRetentionMergePolicy#getScorer method.



--
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-8472) Soft-deletes merge retention query should be rewritten

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602275#comment-16602275
 ] 

ASF subversion and git services commented on LUCENE-8472:
-

Commit b8dfb7e911e68dd89741675c70e0f7b6745b4502 in lucene-solr's branch 
refs/heads/master from [~dnhatn]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b8dfb7e ]

LUCENE-8472: Always rewrite soft-deletes retention query

This change ensures that we always rewrite the soft-deletes merge
retention policy before passing it into `createWeight` as some Query
does not support `createWeight` directly.


> Soft-deletes merge retention query should be rewritten
> --
>
> Key: LUCENE-8472
> URL: https://issues.apache.org/jira/browse/LUCENE-8472
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.4.1, 7.5, master (8.0)
>Reporter: Nhat Nguyen
>Priority: Minor
> Attachments: LUCENE-8472.patch, LUCENE-8472.patch
>
>
> We should rewrite the retention query before passing it into createWeight in 
> SoftDeletesRetentionMergePolicy#getScorer method.



--
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-8422) Add Matches iteration to interval queries

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602273#comment-16602273
 ] 

Adrien Grand commented on LUCENE-8422:
--

+1

> Add Matches iteration to interval queries
> -
>
> Key: LUCENE-8422
> URL: https://issues.apache.org/jira/browse/LUCENE-8422
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8422.patch, LUCENE-8422.patch, LUCENE-8422.patch
>
>
> Follow up to LUCENE-8404, we can now add Matches iteration to interval 
> queries in the sandbox.



--
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-7.x-MacOSX (64bit/jdk1.8.0) - Build # 819 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/819/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecuteWithCoreLogger

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([E32154050AAF1011:2FA7548BF4667B87]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecute(RequestLoggingTest.java:88)
at 
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecuteWithCoreLogger(RequestLoggingTest.java:65)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 13531 lines...]
   [junit4] Suite: org.apache.solr.handler.RequestLoggingTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (LUCENE-8422) Add Matches iteration to interval queries

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602241#comment-16602241
 ] 

Alan Woodward commented on LUCENE-8422:
---

Updated patch, moving the various helper functions to MatchesUtils (in core) 
and IntervalMatches (in intervals).  I added a note to CHANGES about the 
Matches helper functions moving, but I think we're fine doing this in a point 
release given that the API is marked as experimental.

> Add Matches iteration to interval queries
> -
>
> Key: LUCENE-8422
> URL: https://issues.apache.org/jira/browse/LUCENE-8422
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8422.patch, LUCENE-8422.patch, LUCENE-8422.patch
>
>
> Follow up to LUCENE-8404, we can now add Matches iteration to interval 
> queries in the sandbox.



--
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-8422) Add Matches iteration to interval queries

[Alan Woodward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Woodward updated LUCENE-8422:
--
Attachment: LUCENE-8422.patch

> Add Matches iteration to interval queries
> -
>
> Key: LUCENE-8422
> URL: https://issues.apache.org/jira/browse/LUCENE-8422
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8422.patch, LUCENE-8422.patch, LUCENE-8422.patch
>
>
> Follow up to LUCENE-8404, we can now add Matches iteration to interval 
> queries in the sandbox.



--
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-8422) Add Matches iteration to interval queries

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602199#comment-16602199
 ] 

Alan Woodward commented on LUCENE-8422:
---

+1 to MatchesUtils, there are a couple of static functions on Matches itself 
that could move there as well and tidy up the API surface.

> Add Matches iteration to interval queries
> -
>
> Key: LUCENE-8422
> URL: https://issues.apache.org/jira/browse/LUCENE-8422
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8422.patch, LUCENE-8422.patch
>
>
> Follow up to LUCENE-8404, we can now add Matches iteration to interval 
> queries in the sandbox.



--
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-8477) Improve handling of inner disjunctions in intervals

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602195#comment-16602195
 ] 

Adrien Grand commented on LUCENE-8477:
--

I'd be tempted to just document this behavior for now. I'm afraid that 
introducing non-minimized intervals will introduce similar corner-cases to what 
we have with spans and sloppy phrase queries?

Rewriting automatically feels a bit wrong given that we would be replacing an 
IntervalsSource with another IntervalsSource that has different matches. 
However this is something that could be implemented on top of intervals in 
query parsers by having an intermediate representation of IntervalsSources and 
push disjunctions to the top?

> Improve handling of inner disjunctions in intervals
> ---
>
> Key: LUCENE-8477
> URL: https://issues.apache.org/jira/browse/LUCENE-8477
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
>
> The current implementation of the disjunction interval produced by 
> {{Intervals.or}} is a direct implementation of the OR operator from the Vigna 
> paper.  This produces minimal intervals, meaning that (a) is preferred over 
> (a b), and (b) also over (a b).  This has advantages when it comes to 
> counting intervals for scoring, but also has drawbacks when it comes to 
> matching.  For example, a phrase query for ((a OR (a b)) BLOCK (c)) will not 
> match the document (a b c), because (a) will be preferred over (a b), and (a 
> c) does not match.
> This ticket is to discuss the best way of dealing with disjunctions.



--
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-8422) Add Matches iteration to interval queries

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602180#comment-16602180
 ] 

Adrien Grand commented on LUCENE-8422:
--

I was thinking of something like having a MatchesUtils class with javadocs that 
are explicit about the fact that these methods are only useful to implement 
Matches (as opposed to consuming them). Keeping it in core is ok with me, the 
goal would be for the APIs on Matches/MatchesIterator (and similarly for 
IntervalsSource/IntervalsIterator) to be minimal and not confuse users with 
functions that are implementation helpers.

> Add Matches iteration to interval queries
> -
>
> Key: LUCENE-8422
> URL: https://issues.apache.org/jira/browse/LUCENE-8422
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8422.patch, LUCENE-8422.patch
>
>
> Follow up to LUCENE-8404, we can now add Matches iteration to interval 
> queries in the sandbox.



--
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-8422) Add Matches iteration to interval queries

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602173#comment-16602173
 ] 

Alan Woodward commented on LUCENE-8422:
---

MatchesIterator#disjunction could move to Matches, maybe?  It needs to stay in 
core.search as DisjunctionMatchesIterator is package-private.  
IntervalIterator#wrapMatches can definitely move.

> Add Matches iteration to interval queries
> -
>
> Key: LUCENE-8422
> URL: https://issues.apache.org/jira/browse/LUCENE-8422
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8422.patch, LUCENE-8422.patch
>
>
> Follow up to LUCENE-8404, we can now add Matches iteration to interval 
> queries in the sandbox.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-9) - Build # 4811 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4811/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecuteWithCoreLogger

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([45FBB5EF6BEC0895:897DB56195256303]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecute(RequestLoggingTest.java:88)
at 
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecuteWithCoreLogger(RequestLoggingTest.java:65)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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)


FAILED:  
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecuteWithRequestLogger

Error Message:


Stack Trace:
java.lang.AssertionError
at 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.4) - Build # 22794 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22794/
Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecuteWithCoreLogger

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([DC7D7E5F20D34432:10FB7ED1DE1A2FA4]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecute(RequestLoggingTest.java:88)
at 
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecuteWithCoreLogger(RequestLoggingTest.java:65)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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)


FAILED:  
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecuteWithRequestLogger

Error Message:


Stack Trace:
java.lang.AssertionError
at 

[jira] [Commented] (SOLR-12726) [Ref-Guide] Wrong documentation for solrcloud-autoscaling-overview.doc

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602144#comment-16602144
 ] 

Mikhail Khludnev commented on SOLR-12726:
-

Beside of that procedural note, what's the feedback on the proposal? If it make 
sense, I can nuke those two sentences on my own. 

>  [Ref-Guide] Wrong documentation for solrcloud-autoscaling-overview.doc
> ---
>
> Key: SOLR-12726
> URL: https://issues.apache.org/jira/browse/SOLR-12726
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.1, 7.2, 7.3, 7.4
>Reporter: Zouheir CADI
>Assignee: Mikhail Khludnev
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In my understanding, since version 7.1 and the creation of Triggers and 
> TriggerActions, the bold text below in not necessary since management 
> operations will be invoked automatically. There is no patch to submit. The 
> text has just to be removed.
> *Cluster management operations are currently invoked manually. In the future, 
> these cluster management operations may be invoked automatically in response 
> to cluster events such as a node being added or lost 
> ([link|https://lucene.apache.org/solr/guide/7_4/solrcloud-autoscaling-overview.html]).*
>  
>  



--
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-8477) Improve handling of inner disjunctions in intervals

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602124#comment-16602124
 ] 

Alan Woodward commented on LUCENE-8477:
---

I can see a couple of options here:

1) Add a new operator, OR_MAX, which doesn't try to minimize its internals, and 
sorts prefixes last.  This deals with ((a OR (a b)) BLOCK c) mentioned in the 
description, but it still fails to match in other situations, such as (b OR (b 
c)) BLOCK c - in this case because (b c) will sort before (b), so the interval 
will try to match (b c c).  It also makes it less easy to use, as consumers now 
need to understand the semantics of two separate OR operators

2) Allow IntervalsSource to rewrite itself, so that ((a OR (a b)) BLOCK c) 
becomes (a BLOCK c) OR ((a b) BLOCK c).  This would be a lot easier on the 
user, but I'm not sure how easy it would be from an implementation point of 
view - it may end up adding lots of extra methods to IntervalsSource.

> Improve handling of inner disjunctions in intervals
> ---
>
> Key: LUCENE-8477
> URL: https://issues.apache.org/jira/browse/LUCENE-8477
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
>
> The current implementation of the disjunction interval produced by 
> {{Intervals.or}} is a direct implementation of the OR operator from the Vigna 
> paper.  This produces minimal intervals, meaning that (a) is preferred over 
> (a b), and (b) also over (a b).  This has advantages when it comes to 
> counting intervals for scoring, but also has drawbacks when it comes to 
> matching.  For example, a phrase query for ((a OR (a b)) BLOCK (c)) will not 
> match the document (a b c), because (a) will be preferred over (a b), and (a 
> c) does not match.
> This ticket is to discuss the best way of dealing with disjunctions.



--
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: Lucene/Solr 7.5

[Adrien Grand]

+1 too

Alan, I just left comments on LUCENE-8422.

Le lun. 3 sept. 2018 à 10:50, Alan Woodward  a écrit :

> +1
>
> I’d like to get Matches added to intervals, if anybody feels like
> reviewing https://issues.apache.org/jira/browse/LUCENE-8422 before the
> branch is cut.
>
>
> On 3 Sep 2018, at 09:42, jim ferenczi  wrote:
>
> Hi all,
>
> 7.4 has been released two months ago on June 29th and we have new
> features, enhancements and fixes that are not released yet so I'd like to
> start working on releasing Lucene/Solr 7.5.0.
> There's also a bad bug with index sorting that deletes the wrong documents
> when delete by query is used:
> https://issues.apache.org/jira/browse/LUCENE-8466
>
> I can create the 7.5 branch later this week and build the first RC early
> next week if that works for everyone. Please let me know if there are bug
> fixes that needs to be fixed in 7.5 and might not be ready by then.
>
> Cheers,
> Jim
>
>
>

[jira] [Commented] (LUCENE-8422) Add Matches iteration to interval queries

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602123#comment-16602123
 ] 

Adrien Grand commented on LUCENE-8422:
--

bq. All sources return null from MatchesIterator#getQuery()

Should we throw an UnsupportedOperation instead? The assumption seems to be 
that it should never get called?

> Add Matches iteration to interval queries
> -
>
> Key: LUCENE-8422
> URL: https://issues.apache.org/jira/browse/LUCENE-8422
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8422.patch, LUCENE-8422.patch
>
>
> Follow up to LUCENE-8404, we can now add Matches iteration to interval 
> queries in the sandbox.



--
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-8422) Add Matches iteration to interval queries

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602118#comment-16602118
 ] 

Adrien Grand commented on LUCENE-8422:
--

+1 to the patch in general, only two minor comments:
 - Maybe we should put some of the helpers that you are adding like 
IntervalIterator#wrapMatches or MatchesIterator#disjunction to separate classes 
to keep IntervalIterator and MatchesIterator only about consuming 
iterators/matches? I think that would make the API easier to digest.
 - Should IntervalIterator#wrapMatches return an iterator whose doc ID is 
initially -1? Also #docID() should return NO_MORE_DOCS after nextDoc/advance 
returned NO_MORE_DOCS.

FYI precommit complains about unused imports.

> Add Matches iteration to interval queries
> -
>
> Key: LUCENE-8422
> URL: https://issues.apache.org/jira/browse/LUCENE-8422
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8422.patch, LUCENE-8422.patch
>
>
> Follow up to LUCENE-8404, we can now add Matches iteration to interval 
> queries in the sandbox.



--
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-8477) Improve handling of inner disjunctions in intervals

[Alan Woodward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Woodward updated LUCENE-8477:
--
Description: 
The current implementation of the disjunction interval produced by 
{{Intervals.or}} is a direct implementation of the OR operator from the Vigna 
paper.  This produces minimal intervals, meaning that (a) is preferred over (a 
b), and (b) also over (a b).  This has advantages when it comes to counting 
intervals for scoring, but also has drawbacks when it comes to matching.  For 
example, a phrase query for ((a OR (a b)) BLOCK (c)) will not match the 
document (a b c), because (a) will be preferred over (a b), and (a c) does not 
match.

This ticket is to discuss the best way of dealing with disjunctions.

  was:
The current implementation of the disjunction interval produced by 
{{Intervals.or}} is a direct implementation of the OR operator from the Vigna 
paper.  This produces minimal intervals, meaning that (a) is preferred over (a 
b), and (b) also over (a b).  This has advantages when it comes to counting 
intervals for scoring, but also has drawbacks when it comes to matching.  For 
example, a phrase query for ((a OR (a b)) NEAR (c)) will not match the document 
(a b c), because (a) will be preferred over (a b), and (a c) does not match.

This ticket is to discuss the best way of dealing with disjunctions.


> Improve handling of inner disjunctions in intervals
> ---
>
> Key: LUCENE-8477
> URL: https://issues.apache.org/jira/browse/LUCENE-8477
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
>
> The current implementation of the disjunction interval produced by 
> {{Intervals.or}} is a direct implementation of the OR operator from the Vigna 
> paper.  This produces minimal intervals, meaning that (a) is preferred over 
> (a b), and (b) also over (a b).  This has advantages when it comes to 
> counting intervals for scoring, but also has drawbacks when it comes to 
> matching.  For example, a phrase query for ((a OR (a b)) BLOCK (c)) will not 
> match the document (a b c), because (a) will be preferred over (a b), and (a 
> c) does not match.
> This ticket is to discuss the best way of dealing with disjunctions.



--
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-8196) Add IntervalQuery and IntervalsSource to expose minimum interval semantics across term fields

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602117#comment-16602117
 ] 

Alan Woodward commented on LUCENE-8196:
---

[~Martin Hermann] seeing as this ticket is closed, I opened LUCENE-8477 to 
continue discussion.

> Add IntervalQuery and IntervalsSource to expose minimum interval semantics 
> across term fields
> -
>
> Key: LUCENE-8196
> URL: https://issues.apache.org/jira/browse/LUCENE-8196
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.4
>
> Attachments: LUCENE-8196-debug.patch, LUCENE-8196.patch, 
> LUCENE-8196.patch, LUCENE-8196.patch, LUCENE-8196.patch, LUCENE-8196.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This ticket proposes an alternative implementation of the SpanQuery family 
> that uses minimum-interval semantics from 
> [http://vigna.di.unimi.it/ftp/papers/EfficientAlgorithmsMinimalIntervalSemantics.pdf]
>  to implement positional queries across term-based fields.  Rather than using 
> TermQueries to construct the interval operators, as in LUCENE-2878 or the 
> current Spans implementation, we instead use a new IntervalsSource object, 
> which will produce IntervalIterators over a particular segment and field.  
> These are constructed using various static helper methods, and can then be 
> passed to a new IntervalQuery which will return documents that contain one or 
> more intervals so defined.



--
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-8477) Improve handling of inner disjunctions in intervals

[Alan Woodward (JIRA)]

Alan Woodward created LUCENE-8477:
-

 Summary: Improve handling of inner disjunctions in intervals
 Key: LUCENE-8477
 URL: https://issues.apache.org/jira/browse/LUCENE-8477
 Project: Lucene - Core
  Issue Type: New Feature
Reporter: Alan Woodward


The current implementation of the disjunction interval produced by 
{{Intervals.or}} is a direct implementation of the OR operator from the Vigna 
paper.  This produces minimal intervals, meaning that (a) is preferred over (a 
b), and (b) also over (a b).  This has advantages when it comes to counting 
intervals for scoring, but also has drawbacks when it comes to matching.  For 
example, a phrase query for ((a OR (a b)) NEAR (c)) will not match the document 
(a b c), because (a) will be preferred over (a b), and (a c) does not match.

This ticket is to discuss the best way of dealing with disjunctions.



--
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-6228) Do not expose full-fledged scorers in LeafCollector.setScorer

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602097#comment-16602097
 ] 

Adrien Grand commented on LUCENE-6228:
--

+1 to this patch, let's also make sure we add a note about this to the 
MIGRATE.txt? It would be a nice addition to Lucene 8 since we added more 
methods that shouldn't get called from a collector, like advanceShallow and 
getMaxScore. However we'd need to put setMinCompetitiveScore on Scorable.

> Do not expose full-fledged scorers in LeafCollector.setScorer
> -
>
> Key: LUCENE-6228
> URL: https://issues.apache.org/jira/browse/LUCENE-6228
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Major
> Fix For: 5.2, 6.0
>
> Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch, 
> LUCENE-6228.patch, LUCENE-6228.patch
>
>
> Currently LeafCollector.setScorer takes a Scorer, which I don't like because 
> several methods should never be called in the context of a Collector (like 
> nextDoc or advance).
> I think it's even more trappy for methods that might seem to work in some 
> particular cases but will not work in the general case, like getChildren 
> which will not work if you have a specialized BulkScorer or iterating over 
> positions which will not work if you are in a MultiCollector and another leaf 
> collector consumes positions too.
> So I think we should restrict what can be seen from a collector to avoid such 
> traps.



--
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-12729) SplitShardCmd should lock the parent shard to prevent parallel splitting requests

[Andrzej Bialecki (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602080#comment-16602080
 ] 

Andrzej Bialecki  commented on SOLR-12729:
--

Shalin suggested that we could use an ephemeral znode to signal that a shard is 
in the process of being split. This way the lock would be automatically 
released on Overseer crash.

We should also check for stale locks, if eg. a sub-shard is permanently stuck 
in RECOVERY. This can be implemented in {{InactiveShardPlanAction}}, which is 
periodically invoked from the maintenance trigger.

> SplitShardCmd should lock the parent shard to prevent parallel splitting 
> requests
> -
>
> Key: SOLR-12729
> URL: https://issues.apache.org/jira/browse/SOLR-12729
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.5
>
>
> This scenario was discovered by the simulation framework, but it exists also 
> in the non-simulated code.
> When {{IndexSizeTrigger}} requests SPLITSHARD, which is then successfully 
> started and “completed” from the point of view of {{ExecutePlanAction}}, the 
> reality is that it still can take significant amount of time until the moment 
> when the new replicas fully recover and cause the switch of shard states 
> (parent to INACTIVE, child from RECOVERY to ACTIVE).
> If this time is longer than the trigger's {{waitFor}} the trigger will issue 
> the same SPLITSHARD request again. {{SplitShardCmd}} doesn't prevent this new 
> request from being processed because the parent shard is still ACTIVE. 
> However, a section of the code in {{SplitShardCmd}} will realize that 
> sub-slices with the target names already exist and they are not active, at 
> which point it will delete the new sub-slices ({{SplitShardCmd:182}}).
> The end result is an infinite loop, where {{IndexSizeTrigger}} will keep 
> generating SPLITSHARD, and {{SplitShardCmd}} will keep deleting the 
> recovering sub-slices created by the previous command.
> A simple solution is for the parent shard to be marked to indicate that it’s 
> in a process of splitting, so that no other split is attempted on the same 
> shard. Furthermore, {{IndexSizeTrigger}} could temporarily exclude such 
> shards from monitoring.



--
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-7.x-Windows (64bit/jdk1.8.0_172) - Build # 770 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/770/
Java: 64bit/jdk1.8.0_172 -XX:-UseCompressedOops -XX:+UseG1GC

4 tests failed.
FAILED:  
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecuteWithRequestLogger

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([1E1764FC1016248:B08856406CF7DA06]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecute(RequestLoggingTest.java:88)
at 
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecuteWithRequestLogger(RequestLoggingTest.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecuteWithRequestLogger

Error Message:


Stack Trace:
java.lang.AssertionError
at 

[jira] [Comment Edited] (SOLR-12641) Http2SolrClient should be able to connect to old Solr nodes.

[Cao Manh Dat (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602046#comment-16602046
 ] 

Cao Manh Dat edited comment on SOLR-12641 at 9/3/18 11:26 AM:
--

 The first solution is
 * Using HTTP/1.1 as default for {{Http2SolrClient}} in Solr 8.0, therefore 
nodes will communicate with others using HTTP/1.1 (note that servers still 
accept both HTTP/1.1 and HTTP/2 connections)
 * Do rolling updates 
 * When all nodes are in version 8.0, restart nodes with enabling HTTP/2 flag 
for {{Http2SolrClient}}, therefore nodes will communicate with others using 
HTTP/2 from thereafter.

The second solution can be adding a HTTP/2 flag support on {{clusterstate}} for 
every replica. Whenever a new connection is created we will base on that flag 
to create proper HTTP/2 or HTTP/1.1 connection. This can a little bit tricky 
and needs more tests to make sure everything works correctly.

What do you guys think [~elyograg], [~steve_rowe], [~shalinmangar]


was (Author: caomanhdat):
 The first solution is
 * Using HTTP/1.1 as default for {{Http2SolrClient}} in Solr 8.0, therefore 
nodes will communicate with others using HTTP/1.1 (note that servers still 
accept both HTTP/1.1 and HTTP/2 connections)
 * Do rolling updates 
 * When all nodes are in version 8.0, restart nodes with enabling HTTP/2 flag 
for {{Http2SolrClient}}, therefore nodes will communicate with others using 
HTTP/2 from thereafter.

What do you guys think [~elyograg], [~steve_rowe], [~shalinmangar]

> Http2SolrClient should be able to connect to old Solr nodes.
> 
>
> Key: SOLR-12641
> URL: https://issues.apache.org/jira/browse/SOLR-12641
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Priority: Major
>
> Right now, Http2SolrClient can't connect to old Solr nodes, this seems an 
> issue of Jetty HTTP client 
> (https://github.com/eclipse/jetty.project/issues/1308). To support rolling 
> updates, this problem must be solved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-12641) Http2SolrClient should be able to connect to old Solr nodes.

[Cao Manh Dat (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602046#comment-16602046
 ] 

Cao Manh Dat edited comment on SOLR-12641 at 9/3/18 11:23 AM:
--

 The first solution is
 * Using HTTP/1.1 as default for {{Http2SolrClient}} in Solr 8.0, therefore 
nodes will communicate with others using HTTP/1.1 (note that servers still 
accept both HTTP/1.1 and HTTP/2 connections)
 * Do rolling updates 
 * When all nodes are in version 8.0, restart nodes with enabling HTTP/2 flag 
for {{Http2SolrClient}}, therefore nodes will communicate with others using 
HTTP/2 from thereafter.

What do you guys think [~elyograg], [~steve_rowe], [~shalinmangar]


was (Author: caomanhdat):
 

One possible strategy here is
 * Using HTTP/1.1 as default for {{Http2SolrClient}} in Solr 8.0
 * Do rolling updates 
 * When all nodes are in version 8.0, restart nodes with enabling HTTP/2 flag 
for {{Http2SolrClient}}

What do you guys think [~elyograg], [~steve_rowe], [~shalinmangar]

> Http2SolrClient should be able to connect to old Solr nodes.
> 
>
> Key: SOLR-12641
> URL: https://issues.apache.org/jira/browse/SOLR-12641
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Priority: Major
>
> Right now, Http2SolrClient can't connect to old Solr nodes, this seems an 
> issue of Jetty HTTP client 
> (https://github.com/eclipse/jetty.project/issues/1308). To support rolling 
> updates, this problem must be solved.



--
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-7.x-Linux (64bit/jdk-11-ea+28) - Build # 2680 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2680/
Java: 64bit/jdk-11-ea+28 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

7 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamingTest.testZeroParallelReducerStream

Error Message:
java.util.concurrent.ExecutionException: java.io.IOException: --> 
https://127.0.0.1:33463/solr/streams_collection_shard2_replica_n2/:java.util.concurrent.ExecutionException:
 java.io.IOException: params 
q=blah=id,a_s,a_i,a_f=a_s+asc,a_f+asc=a_s=false

Stack Trace:
java.io.IOException: java.util.concurrent.ExecutionException: 
java.io.IOException: --> 
https://127.0.0.1:33463/solr/streams_collection_shard2_replica_n2/:java.util.concurrent.ExecutionException:
 java.io.IOException: params 
q=blah=id,a_s,a_i,a_f=a_s+asc,a_f+asc=a_s=false
at 
__randomizedtesting.SeedInfo.seed([2D7ED59F048B49FB:6383381D182D1C94]:0)
at 
org.apache.solr.client.solrj.io.stream.CloudSolrStream.openStreams(CloudSolrStream.java:400)
at 
org.apache.solr.client.solrj.io.stream.CloudSolrStream.open(CloudSolrStream.java:275)
at 
org.apache.solr.client.solrj.io.stream.StreamingTest.getTuples(StreamingTest.java:2417)
at 
org.apache.solr.client.solrj.io.stream.StreamingTest.testZeroParallelReducerStream(StreamingTest.java:1991)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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 

[jira] [Commented] (SOLR-12641) Http2SolrClient should be able to connect to old Solr nodes.

[Cao Manh Dat (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16602046#comment-16602046
 ] 

Cao Manh Dat commented on SOLR-12641:
-

 

One possible strategy here is
 * Using HTTP/1.1 as default for {{Http2SolrClient}} in Solr 8.0
 * Do rolling updates 
 * When all nodes are in version 8.0, restart nodes with enabling HTTP/2 flag 
for {{Http2SolrClient}}

What do you guys think [~elyograg], [~steve_rowe], [~shalinmangar]

> Http2SolrClient should be able to connect to old Solr nodes.
> 
>
> Key: SOLR-12641
> URL: https://issues.apache.org/jira/browse/SOLR-12641
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Priority: Major
>
> Right now, Http2SolrClient can't connect to old Solr nodes, this seems an 
> issue of Jetty HTTP client 
> (https://github.com/eclipse/jetty.project/issues/1308). To support rolling 
> updates, this problem must be solved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-12729) SplitShardCmd should lock the parent shard to prevent parallel splitting requests

[Andrzej Bialecki (JIRA)]

Andrzej Bialecki  created SOLR-12729:


 Summary: SplitShardCmd should lock the parent shard to prevent 
parallel splitting requests
 Key: SOLR-12729
 URL: https://issues.apache.org/jira/browse/SOLR-12729
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: AutoScaling
Reporter: Andrzej Bialecki 
Assignee: Andrzej Bialecki 
 Fix For: 7.5


This scenario was discovered by the simulation framework, but it exists also in 
the non-simulated code.

When {{IndexSizeTrigger}} requests SPLITSHARD, which is then successfully 
started and “completed” from the point of view of {{ExecutePlanAction}}, the 
reality is that it still can take significant amount of time until the moment 
when the new replicas fully recover and cause the switch of shard states 
(parent to INACTIVE, child from RECOVERY to ACTIVE).

If this time is longer than the trigger's {{waitFor}} the trigger will issue 
the same SPLITSHARD request again. {{SplitShardCmd}} doesn't prevent this new 
request from being processed because the parent shard is still ACTIVE. However, 
a section of the code in {{SplitShardCmd}} will realize that sub-slices with 
the target names already exist and they are not active, at which point it will 
delete the new sub-slices ({{SplitShardCmd:182}}).

The end result is an infinite loop, where {{IndexSizeTrigger}} will keep 
generating SPLITSHARD, and {{SplitShardCmd}} will keep deleting the recovering 
sub-slices created by the previous command.

A simple solution is for the parent shard to be marked to indicate that it’s in 
a process of splitting, so that no other split is attempted on the same shard. 
Furthermore, {{IndexSizeTrigger}} could temporarily exclude such shards from 
monitoring.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-10) - Build # 7502 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7502/
Java: 64bit/jdk-10 -XX:+UseCompressedOops -XX:+UseSerialGC

4 tests failed.
FAILED:  
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecuteWithRequestLogger

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([437D83C0F26C222A:F214A3CF5F9A9A64]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecute(RequestLoggingTest.java:88)
at 
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecuteWithRequestLogger(RequestLoggingTest.java:71)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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)


FAILED:  
org.apache.solr.handler.RequestLoggingTest.testLogBeforeExecuteWithRequestLogger

Error Message:


Stack Trace:
java.lang.AssertionError
at 

[jira] [Commented] (LUCENE-8476) Bug fix and optimizations in UserDictionary(KoreanAnalyzer)

[Lucene/Solr QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16601915#comment-16601915
 ] 

Lucene/Solr QA commented on LUCENE-8476:


| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
23s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 17s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m 
15s{color} | {color:green} nori in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}  2m 27s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8476 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12938050/LUCENE-8476.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.4.0-130-generic #156~14.04.1-Ubuntu SMP Thu 
Jun 14 13:51:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / d93c46e |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_172 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/82/testReport/ |
| modules | C: lucene/analysis/nori U: lucene/analysis/nori |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/82/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



>  Bug fix and optimizations in UserDictionary(KoreanAnalyzer)
> 
>
> Key: LUCENE-8476
> URL: https://issues.apache.org/jira/browse/LUCENE-8476
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Reporter: Namgyu Kim
>Priority: Major
>  Labels: bugfix, memory-leak, optimization, patch-available
> Attachments: LUCENE-8476.patch
>
>
> ■ Bug fix
> 1) BufferedReader's close method is not called.
> {code:java}
> // Line 57 method
> public static UserDictionary open(Reader reader) throws IOException {
>   BufferedReader br = new BufferedReader(reader);
>   String line = null;
>   List entries = new ArrayList<>();
>   // text + optional segmentations
>   while ((line = br.readLine()) != null) {
> ...
>   }
>   if (entries.isEmpty()) {
> return null;
>   } else {
> return new UserDictionary(entries);
>   }
> }{code}
> If you look at the code above, there is no close() method for the "br" 
> variable.
>  As I know, BufferedReader can cause a +memory leak+ if the close method is 
> not called.
>  So I changed the code below.
> {code:java}
> // Line 57 method
> public static UserDictionary open(Reader reader) throws IOException {
>   String line = null;
>   List entries = new ArrayList<>();
>   // text + optional segmentations
>   try (BufferedReader br = new BufferedReader(reader)) {
> while ((line = br.readLine()) != null) {
>   ...
> }
>   }
>   if (entries.isEmpty()) {
> return null;
>   } else {
> return new UserDictionary(entries);
>   }
> }
> {code}
> I solved this problem with 
> "[try-with-resources|https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html];
>  method available since Java 7.
>  
> ■ Optimizations
> 1) Change from Collections.sort to List.sort (UserDictionary constructor)
> {code:java}
> // Line 82 method
> private 

Re: Lucene/Solr 7.5

[Alan Woodward]

+1

I’d like to get Matches added to intervals, if anybody feels like reviewing 
https://issues.apache.org/jira/browse/LUCENE-8422 
 before the branch is cut.

> On 3 Sep 2018, at 09:42, jim ferenczi  > wrote:
> 
> Hi all,
> 
> 7.4 has been released two months ago on June 29th and we have new features, 
> enhancements and fixes that are not released yet so I'd like to start working 
> on releasing Lucene/Solr 7.5.0.
> There's also a bad bug with index sorting that deletes the wrong documents 
> when delete by query is used:
> https://issues.apache.org/jira/browse/LUCENE-8466 
> 
> 
> I can create the 7.5 branch later this week and build the first RC early next 
> week if that works for everyone. Please let me know if there are bug fixes 
> that needs to be fixed in 7.5 and might not be ready by then.
> 
> Cheers,
> Jim

Lucene/Solr 7.5

[jim ferenczi]

Hi all,

7.4 has been released two months ago on June 29th and we have new features,
enhancements and fixes that are not released yet so I'd like to start
working on releasing Lucene/Solr 7.5.0.
There's also a bad bug with index sorting that deletes the wrong documents
when delete by query is used:
https://issues.apache.org/jira/browse/LUCENE-8466

I can create the 7.5 branch later this week and build the first RC early
next week if that works for everyone. Please let me know if there are bug
fixes that needs to be fixed in 7.5 and might not be ready by then.

Cheers,
Jim

Re: Lucene/Solr 8.0

[jim ferenczi]

Ok thanks Đạt and Erick. I'll follow the blockers on Jira.  Đạt do you have
an issue opened for the HTTP/2 support ?

Le ven. 31 août 2018 à 16:40, Erick Erickson  a
écrit :

> There's also the issue of what to do as far as removing Trie* support.
> I think there's a blocker JIRA.
>
> project = SOLR AND priority = Blocker AND resolution = Unresolved
>
> Shows 6 blockers
> On Fri, Aug 31, 2018 at 4:12 AM Đạt Cao Mạnh 
> wrote:
> >
> > Hi Jim,
> >
> > I really want to introduce the support of HTTP/2 into Solr 8.0
> (currently cooked in jira/http2 branch). The changes of that branch are
> less than Star Burst effort and closer to be merged into master branch.
> >
> > Thanks!
> >
> > On Fri, Aug 31, 2018 at 3:55 PM jim ferenczi 
> wrote:
> >>
> >> Hi all,
> >> I'd like to get some feedback regarding the upcoming Lucene/Solr 8
> release. There are still some cleanups and docs to add on the Lucene side
> but it seems that all blockers are resolved.
> >> From a Solr perspective are there any important changes that need to be
> done or are we still good with the October target for the release ? Adrien
> mentioned the Star Burst effort some time ago, is it something that is
> planned for 8 ?
> >>
> >> Cheers,
> >> Jim
> >>
> >> Le mer. 1 août 2018 à 19:02, David Smiley  a
> écrit :
> >>>
> >>> Yes, that new BKD/Points based code is definitely something we want in
> 8 or 7.5 -- it's a big deal.  I think it would also be awesome if we had
> highlighter that could use the Weight.matches() API -- again for either 7.5
> or 8.  I'm working on this on the UnifiedHighlighter front and Alan from
> other aspects.
> >>> ~ David
> >>>
> >>> On Wed, Aug 1, 2018 at 12:51 PM Adrien Grand 
> wrote:
> 
>  I was hoping that we would release some bits of this new support for
> geo shapes in 7.5 already. We are already very close to being able to index
> points, lines and polygons and query for intersection with an envelope. It
> would be nice to add support for other relations (eg. disjoint) and queries
> (eg. polygon) but the current work looks already useful to me.
> 
>  Le mer. 1 août 2018 à 17:00, Robert Muir  a écrit :
> >
> > My only other suggestion is we may want to get Nick's shape stuff
> into
> > the sandbox module at least for 8.0 so that it can be tested out. I
> > think it looks like that wouldn't delay any October target though?
> >
> > On Wed, Aug 1, 2018 at 9:51 AM, Adrien Grand 
> wrote:
> > > I'd like to revive this thread now that these new optimizations for
> > > collection of top docs are more usable and enabled by default in
> > > IndexSearcher (https://issues.apache.org/jira/browse/LUCENE-8060).
> Any
> > > feedback about starting to work towards releasing 8.0 and
> targeting October
> > > 2018?
> > >
> > >
> > > Le jeu. 21 juin 2018 à 09:31, Adrien Grand  a
> écrit :
> > >>
> > >> Hi Robert,
> > >>
> > >> I agree we need to make it more usable before 8.0. I would also
> like to
> > >> improve ReqOptSumScorer (
> https://issues.apache.org/jira/browse/LUCENE-8204)
> > >> to leverage impacts so that queries that incorporate queries on
> feature
> > >> fields (https://issues.apache.org/jira/browse/LUCENE-8197) in an
> optional
> > >> clause are also fast.
> > >>
> > >> Le jeu. 21 juin 2018 à 03:06, Robert Muir  a
> écrit :
> > >>>
> > >>> How can the end user actually use the biggest new feature:
> impacts and
> > >>> BMW? As far as I can tell, the issue to actually implement the
> > >>> necessary API changes (IndexSearcher/TopDocs/etc) is still open
> and
> > >>> unresolved, although there are some interesting ideas on it. This
> > >>> seems like a really big missing piece, without a proper API, the
> stuff
> > >>> is not really usable. I also can't imagine a situation where the
> API
> > >>> could be introduced in a followup minor release because it would
> be
> > >>> too invasive.
> > >>>
> > >>> On Mon, Jun 18, 2018 at 1:19 PM, Adrien Grand 
> wrote:
> > >>> > Hi all,
> > >>> >
> > >>> > I would like to start discussing releasing Lucene/Solr 8.0.
> Lucene 8
> > >>> > already
> > >>> > has some good changes around scoring, notably cleanups to
> > >>> > similarities[1][2][3], indexing of impacts[4], and an
> implementation of
> > >>> > Block-Max WAND[5] which, once combined, allow to run queries
> faster
> > >>> > when
> > >>> > total hit counts are not requested.
> > >>> >
> > >>> > [1] https://issues.apache.org/jira/browse/LUCENE-8116
> > >>> > [2] https://issues.apache.org/jira/browse/LUCENE-8020
> > >>> > [3] https://issues.apache.org/jira/browse/LUCENE-8007
> > >>> > [4] https://issues.apache.org/jira/browse/LUCENE-4198
> > >>> > [5] https://issues.apache.org/jira/browse/LUCENE-8135
> > >>> >
> > >>> > In terms of bug fixes, there is also a bad relevancy bug[6]
> which is
> > >>> > 

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-11-ea+28) - Build # 2679 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2679/
Java: 64bit/jdk-11-ea+28 -XX:-UseCompressedOops -XX:+UseG1GC

22 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.TestCloudRecovery

Error Message:
Could not find collection:collection1

Stack Trace:
java.lang.AssertionError: Could not find collection:collection1
at __randomizedtesting.SeedInfo.seed([351F4CA6F12E29C9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.cloud.TestCloudRecovery.setupCluster(TestCloudRecovery.java:70)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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)


FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.TestCloudRecovery

Error Message:
Could not find collection:collection1

Stack Trace:
java.lang.AssertionError: Could not find collection:collection1
at __randomizedtesting.SeedInfo.seed([351F4CA6F12E29C9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.cloud.TestCloudRecovery.setupCluster(TestCloudRecovery.java:70)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 

[jira] [Commented] (SOLR-12685) RTG should return the whole block if schema is nested

[mosh (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16601844#comment-16601844
 ] 

mosh commented on SOLR-12685:
-

Please correct me if mistaken.
 I was thinking RTG should not return the whole block when queried directly by 
the RTG handler, but rather should explicitly perform these checks when running 
RealTimeGetComponent#getInputDocument, which is used by 
AtomicUpdateDocumentMerger.
{code:java}
SolrInputDocument oldDocument = RealTimeGetComponent.getInputDocument
  (cmd.getReq().getCore(), idBytes,
   null, // don't want the version to be returned
   true, // avoid stored fields from index
   updatedFields,
   true); // resolve the full document{code}
Unless, of course, RTG block lookup is needed by the replication process, 
which, unfortunately, I am unfamiliar with.
Running through the code it seems like the transaction log lookup is written in 
RealTimeGetComponent#getInputDocumentFromTlog and in process, twice.
We could leverage that to ensure AtomicUpdateDocumentMerger gets the block when 
needed, avoiding further collision and interference with the RealTimeGetHandler.

> RTG should return the whole block if schema is nested
> -
>
> Key: SOLR-12685
> URL: https://issues.apache.org/jira/browse/SOLR-12685
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
> Attachments: SOLR-12638-no-commit.patch
>
>
> Currently Solr's RealTimeGet component return the document if provided a 
> docId when consulting the index. For AtomicUpdates for child documents, RTG 
> should return the whole block when dealing with a nested schema.



--
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-7.x-Solaris (64bit/jdk1.8.0) - Build # 796 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/796/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.search.SignificantTermsQParserPluginTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.search.SignificantTermsQParserPluginTest: 1) Thread[id=13, 
name=Log4j2-TF-1-AsyncLoggerConfig--1, state=TIMED_WAITING, 
group=TGRP-SignificantTermsQParserPluginTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
 at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.search.SignificantTermsQParserPluginTest: 
   1) Thread[id=13, name=Log4j2-TF-1-AsyncLoggerConfig--1, state=TIMED_WAITING, 
group=TGRP-SignificantTermsQParserPluginTest]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at java.lang.Thread.run(Thread.java:748)
at __randomizedtesting.SeedInfo.seed([9D483F8C0B2F559C]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.search.SignificantTermsQParserPluginTest

Error Message:
There are still zombie threads that couldn't be terminated:1) Thread[id=13, 
name=Log4j2-TF-1-AsyncLoggerConfig--1, state=TIMED_WAITING, 
group=TGRP-SignificantTermsQParserPluginTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
 at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=13, name=Log4j2-TF-1-AsyncLoggerConfig--1, state=TIMED_WAITING, 
group=TGRP-SignificantTermsQParserPluginTest]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at java.lang.Thread.run(Thread.java:748)
at __randomizedtesting.SeedInfo.seed([9D483F8C0B2F559C]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.search.SignificantTermsQParserPluginTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.search.SignificantTermsQParserPluginTest: 1) Thread[id=13, 
name=Log4j2-TF-1-AsyncLoggerConfig--1, state=TIMED_WAITING, 
group=TGRP-SignificantTermsQParserPluginTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
 at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.search.SignificantTermsQParserPluginTest: 
   1) Thread[id=13,