[jira] [Commented] (SOLR-11376) ComputePlanAction should accept configuration to compute plans only for specific collections
[ https://issues.apache.org/jira/browse/SOLR-11376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343329#comment-16343329 ] ASF subversion and git services commented on SOLR-11376: Commit 8636223146f88a0cf3690abb337345631fce65ad in lucene-solr's branch refs/heads/branch_7x from [~ab] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8636223 ] SOLR-11376: Support computing plans for only specific collections. > ComputePlanAction should accept configuration to compute plans only for > specific collections > > > Key: SOLR-11376 > URL: https://issues.apache.org/jira/browse/SOLR-11376 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling >Reporter: Shalin Shekhar Mangar >Assignee: Andrzej Bialecki >Priority: Major > Fix For: master (8.0), 7.3 > > Attachments: SOLR-11376.patch > > > Today when we enable triggers, we compute a plan for all collections. It is > not possible to configure the action to only apply for specific collections. > I propose to add a parameter to ComputePlanAction called "collections" which > accepts a list of collection names for which to compute actions. -- 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-11376) ComputePlanAction should accept configuration to compute plans only for specific collections
[ https://issues.apache.org/jira/browse/SOLR-11376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki resolved SOLR-11376. -- Resolution: Fixed > ComputePlanAction should accept configuration to compute plans only for > specific collections > > > Key: SOLR-11376 > URL: https://issues.apache.org/jira/browse/SOLR-11376 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling >Reporter: Shalin Shekhar Mangar >Assignee: Andrzej Bialecki >Priority: Major > Fix For: master (8.0), 7.3 > > Attachments: SOLR-11376.patch > > > Today when we enable triggers, we compute a plan for all collections. It is > not possible to configure the action to only apply for specific collections. > I propose to add a parameter to ComputePlanAction called "collections" which > accepts a list of collection names for which to compute actions. -- 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
Migrating Solr from one server to another
Hi, I have a Solr instance running on AWS with close to 1000K documents. We've decided to stop using AWS and migrate to local clusters and hence I need to migrate the data from AWS to local. Can anyone help me out on how to go about the process? I came across methods that first migrate all the data in the collection to a single file but I'm not sure if that is such a good idea. It would be really great if some of you could point me to blogs/articles to help export solr data from AWS to local. Best Regards, Aditya
[jira] [Commented] (LUCENE-8140) Checks for coplanarity when creating polygons shows numerical issues
[ https://issues.apache.org/jira/browse/LUCENE-8140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343250#comment-16343250 ] Ignacio Vera commented on LUCENE-8140: -- This means the algorithm needs to change so SafePath nodes are created after checking for coplanirity. I have already a new version which is actually not a recursive method but does the job on a loop. It passes all tests but I would like to test it more so hopefully I will have a new version by tomorrow. > Checks for coplanarity when creating polygons shows numerical issues > > > Key: LUCENE-8140 > URL: https://issues.apache.org/jira/browse/LUCENE-8140 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: LUCENE-8140-fix.patch, LUCENE-8140.patch > > > Coplanarity checks in GeoPolygonFactory shows numerical errors when the > distance between two points is very small compared to the distance of the > other two points. The situation is as follows: > Having three points A, B, & C and the distance between A & B is very small > compared to the distance between A & C, then the plane AC contains all points > (co-planar) but the plane defined by AB does not contain C because of > numerical issues. This situation makes some polygons fail to build. -- 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-11376) ComputePlanAction should accept configuration to compute plans only for specific collections
[ https://issues.apache.org/jira/browse/SOLR-11376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343234#comment-16343234 ] ASF subversion and git services commented on SOLR-11376: Commit d3d7b0034d497acb7e1230322600a712e068c8d2 in lucene-solr's branch refs/heads/master from [~ab] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d3d7b00 ] SOLR-11376: Support computing plans for only specific collections. > ComputePlanAction should accept configuration to compute plans only for > specific collections > > > Key: SOLR-11376 > URL: https://issues.apache.org/jira/browse/SOLR-11376 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling >Reporter: Shalin Shekhar Mangar >Assignee: Andrzej Bialecki >Priority: Major > Fix For: master (8.0), 7.3 > > Attachments: SOLR-11376.patch > > > Today when we enable triggers, we compute a plan for all collections. It is > not possible to configure the action to only apply for specific collections. > I propose to add a parameter to ComputePlanAction called "collections" which > accepts a list of collection names for which to compute actions. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 134 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/134/ 8 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.analytics.OverallAnalyticsTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.analytics.OverallAnalyticsTest: 1) Thread[id=83, name=qtp2038752375-83, state=TIMED_WAITING, group=TGRP-OverallAnalyticsTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.reservedWait(ReservedThreadExecutor.java:308) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:373) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626) at java.lang.Thread.run(Thread.java:748) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.analytics.OverallAnalyticsTest: 1) Thread[id=83, name=qtp2038752375-83, state=TIMED_WAITING, group=TGRP-OverallAnalyticsTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.reservedWait(ReservedThreadExecutor.java:308) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:373) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([A523C701FE2DACD0]:0) FAILED: junit.framework.TestSuite.org.apache.solr.analytics.OverallAnalyticsTest Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=83, name=qtp2038752375-83, state=TIMED_WAITING, group=TGRP-OverallAnalyticsTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.reservedWait(ReservedThreadExecutor.java:308) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:373) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626) 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=83, name=qtp2038752375-83, state=TIMED_WAITING, group=TGRP-OverallAnalyticsTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.reservedWait(ReservedThreadExecutor.java:308) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:373) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([A523C701FE2DACD0]:0) FAILED: org.apache.solr.cloud.AliasIntegrationTest.testModifyMetadataV1 Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([A7C7ACAA4B877DC5:76A712636B2B6E9C]: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.cloud.AliasIntegrationTest.checkFooAndBarMeta(AliasIntegrationTest.java:287) at org.apache.solr.cloud.AliasIntegrationTest.testModifyMetadataV1(AliasIntegrationTest.java:255) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at
[jira] [Commented] (SOLR-10525) Stacked recovery requests do no cancel an in progress recovery first.
[
https://issues.apache.org/jira/browse/SOLR-10525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343203#comment-16343203
]
ASF subversion and git services commented on SOLR-10525:
Commit f7a75dcc1a2935deda9e4dd4068e141b4b79b820 in lucene-solr's branch
refs/heads/master from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f7a75dc ]
SOLR-10525: Updates CHANGES.txt
> Stacked recovery requests do no cancel an in progress recovery first.
> -
>
> Key: SOLR-10525
> URL: https://issues.apache.org/jira/browse/SOLR-10525
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Mike Drob
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-10525.patch, SOLR-10525.patch
>
>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java#L300-L310
> Two issues with this code:
> {code}
> boolean locked = recoveryLock.tryLock();
> try {
> if (!locked) {
> if (recoveryWaiting.get() > 0) { // line 1
> return;
> }
> recoveryWaiting.incrementAndGet(); // line 2
> } else {
> recoveryWaiting.incrementAndGet();
> cancelRecovery(); // line 3
> }
> {code}
> The {{cancelRecovery}} on line 3 call will only hit when there are no
> recoveries to actually cancel (since we got the lock that means there are no
> recoveries in progress). Instead it should be moved either to the either
> branch of the if, or outside after the if since we know we will be running a
> recovery at that point.
> This code doesn't always prevent multiple requests from stacking. If there is
> a recovery running, but no recoveries currently waiting, multiple requests
> can check the count at line 1 before any of them will increment the count at
> line 2 and thus all of them will hit the increment.
> I don't have specific tests for this, but it's causing failures for me on my
> SOLR-9555 work in progress.
--
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-11879) avoid creating a new Exception object for EOFException in FastinputStream
[ https://issues.apache.org/jira/browse/SOLR-11879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343197#comment-16343197 ] ASF subversion and git services commented on SOLR-11879: Commit 2c21498621426861393358b5da85195e0caafa48 in lucene-solr's branch refs/heads/branch_7x from [~noble.paul] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2c21498 ] SOLR-11879: avoid EOFException when content is send without a payload > avoid creating a new Exception object for EOFException in FastinputStream > - > > Key: SOLR-11879 > URL: https://issues.apache.org/jira/browse/SOLR-11879 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Environment: FastI >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Trivial > Attachments: SOLR-11879.patch, SOLR-11879.patch, Screen Shot > 2018-01-24 at 7.26.16 PM.png > > > FastInputStream creates and throws a new EOFException, every time an end of > stream is encountered. This is wasteful as we never use the stack trace > anywhere -- 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-10525) Stacked recovery requests do no cancel an in progress recovery first.
[
https://issues.apache.org/jira/browse/SOLR-10525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343204#comment-16343204
]
ASF subversion and git services commented on SOLR-10525:
Commit ec2198126fde3638064617d83a077717189d514c in lucene-solr's branch
refs/heads/branch_7x from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ec21981 ]
SOLR-10525: Updates CHANGES.txt
> Stacked recovery requests do no cancel an in progress recovery first.
> -
>
> Key: SOLR-10525
> URL: https://issues.apache.org/jira/browse/SOLR-10525
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Mike Drob
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-10525.patch, SOLR-10525.patch
>
>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java#L300-L310
> Two issues with this code:
> {code}
> boolean locked = recoveryLock.tryLock();
> try {
> if (!locked) {
> if (recoveryWaiting.get() > 0) { // line 1
> return;
> }
> recoveryWaiting.incrementAndGet(); // line 2
> } else {
> recoveryWaiting.incrementAndGet();
> cancelRecovery(); // line 3
> }
> {code}
> The {{cancelRecovery}} on line 3 call will only hit when there are no
> recoveries to actually cancel (since we got the lock that means there are no
> recoveries in progress). Instead it should be moved either to the either
> branch of the if, or outside after the if since we know we will be running a
> recovery at that point.
> This code doesn't always prevent multiple requests from stacking. If there is
> a recovery running, but no recoveries currently waiting, multiple requests
> can check the count at line 1 before any of them will increment the count at
> line 2 and thus all of them will hit the increment.
> I don't have specific tests for this, but it's causing failures for me on my
> SOLR-9555 work in progress.
--
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-11879) avoid creating a new Exception object for EOFException in FastinputStream
[ https://issues.apache.org/jira/browse/SOLR-11879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343201#comment-16343201 ] ASF subversion and git services commented on SOLR-11879: Commit 586aa65110ab873d5faaf7630341deb1674b29a3 in lucene-solr's branch refs/heads/master from [~noble.paul] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=586aa65 ] SOLR-11879: avoid EOFException when content is send without a payload > avoid creating a new Exception object for EOFException in FastinputStream > - > > Key: SOLR-11879 > URL: https://issues.apache.org/jira/browse/SOLR-11879 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Environment: FastI >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Trivial > Attachments: SOLR-11879.patch, SOLR-11879.patch, Screen Shot > 2018-01-24 at 7.26.16 PM.png > > > FastInputStream creates and throws a new EOFException, every time an end of > stream is encountered. This is wasteful as we never use the stack trace > anywhere -- 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-11702) Redesign current LIR implementation
[ https://issues.apache.org/jira/browse/SOLR-11702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat resolved SOLR-11702. - Resolution: Fixed Fix Version/s: 7.3 master (8.0) > Redesign current LIR implementation > --- > > Key: SOLR-11702 > URL: https://issues.apache.org/jira/browse/SOLR-11702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (8.0), 7.3 > > Attachments: SOLR-11702.patch, SOLR-11702.patch > > > I recently looked into some problem related to racing between LIR and > Recovering. I would like to propose a totally new approach to solve SOLR-5495 > problem because fixing current implementation by a bandage will lead us to > other problems (we can not prove the correctness of the implementation). > Feel free to give comments/thoughts about this new scheme. > https://docs.google.com/document/d/1dM2GKMULsS45ZMuvtztVnM2m3fdUeRYNCyJorIIisEo/edit?usp=sharing -- 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-11702) Redesign current LIR implementation
[ https://issues.apache.org/jira/browse/SOLR-11702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343096#comment-16343096 ] ASF subversion and git services commented on SOLR-11702: Commit 8c8d78a4bb6c0f3322471af5765a01848247409c in lucene-solr's branch refs/heads/branch_7x from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8c8d78a ] SOLR-11702: Redesign current LIR implementation > Redesign current LIR implementation > --- > > Key: SOLR-11702 > URL: https://issues.apache.org/jira/browse/SOLR-11702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Attachments: SOLR-11702.patch, SOLR-11702.patch > > > I recently looked into some problem related to racing between LIR and > Recovering. I would like to propose a totally new approach to solve SOLR-5495 > problem because fixing current implementation by a bandage will lead us to > other problems (we can not prove the correctness of the implementation). > Feel free to give comments/thoughts about this new scheme. > https://docs.google.com/document/d/1dM2GKMULsS45ZMuvtztVnM2m3fdUeRYNCyJorIIisEo/edit?usp=sharing -- 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-10525) Stacked recovery requests do no cancel an in progress recovery first.
[
https://issues.apache.org/jira/browse/SOLR-10525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat resolved SOLR-10525.
-
Resolution: Fixed
Assignee: Cao Manh Dat (was: Mark Miller)
Fix Version/s: 7.3
master (8.0)
Committed by SOLR-11702
> Stacked recovery requests do no cancel an in progress recovery first.
> -
>
> Key: SOLR-10525
> URL: https://issues.apache.org/jira/browse/SOLR-10525
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Mike Drob
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-10525.patch, SOLR-10525.patch
>
>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java#L300-L310
> Two issues with this code:
> {code}
> boolean locked = recoveryLock.tryLock();
> try {
> if (!locked) {
> if (recoveryWaiting.get() > 0) { // line 1
> return;
> }
> recoveryWaiting.incrementAndGet(); // line 2
> } else {
> recoveryWaiting.incrementAndGet();
> cancelRecovery(); // line 3
> }
> {code}
> The {{cancelRecovery}} on line 3 call will only hit when there are no
> recoveries to actually cancel (since we got the lock that means there are no
> recoveries in progress). Instead it should be moved either to the either
> branch of the if, or outside after the if since we know we will be running a
> recovery at that point.
> This code doesn't always prevent multiple requests from stacking. If there is
> a recovery running, but no recoveries currently waiting, multiple requests
> can check the count at line 1 before any of them will increment the count at
> line 2 and thus all of them will hit the increment.
> I don't have specific tests for this, but it's causing failures for me on my
> SOLR-9555 work in progress.
--
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-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.
[ https://issues.apache.org/jira/browse/SOLR-9555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat resolved SOLR-9555. Resolution: Fixed Assignee: Cao Manh Dat Fix Version/s: 7.3 master (8.0) Fixed by SOLR-11702 > Leader incorrectly publishes state for replica when it puts replica into LIR. > - > > Key: SOLR-9555 > URL: https://issues.apache.org/jira/browse/SOLR-9555 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alan Woodward >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (8.0), 7.3 > > Attachments: SOLR-9555-WIP-2.patch, SOLR-9555-WIP-3.patch, > SOLR-9555-WIP.patch, SOLR-9555.patch, SOLR-9555.patch, SOLR-9555.patch, > lir-9555-problem.png > > > See > https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull > for an example -- 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-11702) Redesign current LIR implementation
[ https://issues.apache.org/jira/browse/SOLR-11702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343094#comment-16343094 ] ASF subversion and git services commented on SOLR-11702: Commit 27ef6530646a9af6f8fdf491afd80185bc4f7fee in lucene-solr's branch refs/heads/master from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=27ef653 ] SOLR-11702: Redesign current LIR implementation > Redesign current LIR implementation > --- > > Key: SOLR-11702 > URL: https://issues.apache.org/jira/browse/SOLR-11702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Attachments: SOLR-11702.patch, SOLR-11702.patch > > > I recently looked into some problem related to racing between LIR and > Recovering. I would like to propose a totally new approach to solve SOLR-5495 > problem because fixing current implementation by a bandage will lead us to > other problems (we can not prove the correctness of the implementation). > Feel free to give comments/thoughts about this new scheme. > https://docs.google.com/document/d/1dM2GKMULsS45ZMuvtztVnM2m3fdUeRYNCyJorIIisEo/edit?usp=sharing -- 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-8140) Checks for coplanarity when creating polygons shows numerical issues
[ https://issues.apache.org/jira/browse/LUCENE-8140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343092#comment-16343092 ] Karl Wright commented on LUCENE-8140: - [~ivera] I'm not sure it's a good idea to make a non-modifiable class with public members become suddenly modifiable. Can you redo your patch so that we aren't modifying immutable objects? > Checks for coplanarity when creating polygons shows numerical issues > > > Key: LUCENE-8140 > URL: https://issues.apache.org/jira/browse/LUCENE-8140 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Major > Attachments: LUCENE-8140-fix.patch, LUCENE-8140.patch > > > Coplanarity checks in GeoPolygonFactory shows numerical errors when the > distance between two points is very small compared to the distance of the > other two points. The situation is as follows: > Having three points A, B, & C and the distance between A & B is very small > compared to the distance between A & C, then the plane AC contains all points > (co-planar) but the plane defined by AB does not contain C because of > numerical issues. This situation makes some polygons fail to build. -- 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-3475) ShingleFilter should handle positionIncrement of zero, e.g. synonyms
[
https://issues.apache.org/jira/browse/LUCENE-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343073#comment-16343073
]
Adrien Grand commented on LUCENE-3475:
--
I'm not going to work on this in the short term but I just wrote a test case in
case someone else has interest in fixing this issue:
{code}
public void testSynonyms1() throws IOException {
Token t1 = new Token("small", 0, 5);
Token t2 = new Token("little", 0, 5);
t2.setPositionIncrement(0);
Token t3 = new Token("thing", 6, 11);
TokenStream tk = new CannedTokenStream(t1, t2, t3);
ShingleFilter f = new ShingleFilter(tk, 2, 2);
f.setOutputUnigrams(false);
assertTokenStreamContents(f,
new String[] { "small thing", "little thing" },
new int[] {0, 0},
new int[] {11, 11},
new int[] {1, 0});
}
public void testSynonyms2() throws IOException {
Token t1 = new Token("small", 0, 5);
Token t2 = new Token("thing", 6, 11);
Token t3 = new Token("object", 6, 11);
t3.setPositionIncrement(0);
TokenStream tk = new CannedTokenStream(t1, t2, t3);
ShingleFilter f = new ShingleFilter(tk, 2, 2);
f.setOutputUnigrams(false);
assertTokenStreamContents(f,
new String[] { "small thing", "small object" },
new int[] {0, 0},
new int[] {11, 11},
new int[] {1, 0});
}
{code}
> ShingleFilter should handle positionIncrement of zero, e.g. synonyms
>
>
> Key: LUCENE-3475
> URL: https://issues.apache.org/jira/browse/LUCENE-3475
> Project: Lucene - Core
> Issue Type: New Feature
> Components: modules/analysis
>Affects Versions: 3.4
>Reporter: Cameron
>Priority: Minor
> Labels: newdev
>
> ShingleFilter is creating shingles for a single term that has been expanded
> by synonyms when it shouldn't. The position increment is 0.
> As an example, I have an Analyzer with a SynonymFilter followed by a
> ShingleFilter. Assuming car and auto are synonyms, the SynonymFilter produces
> two tokens and position 1: car, auto. The ShingleFilter is then producing 3
> tokens, when there should only be two: car, car auto, auto. This behavior
> seems incorrect.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 132 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/132/ No tests ran. Build Log: [...truncated 28292 lines...] prepare-release-no-sign: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist [copy] Copying 491 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 215 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8 [smoker] NOTE: output encoding is UTF-8 [smoker] [smoker] Load release URL "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.03 sec (7.9 MB/sec) [smoker] check changes HTML... [smoker] download lucene-7.3.0-src.tgz... [smoker] 31.7 MB in 0.45 sec (70.8 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-7.3.0.tgz... [smoker] 73.1 MB in 0.17 sec (439.3 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-7.3.0.zip... [smoker] 83.6 MB in 0.11 sec (769.4 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-7.3.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6284 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-7.3.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6284 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-7.3.0-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run "ant validate" [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'... [smoker] test demo with 1.8... [smoker] got 215 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] generate javadocs w/ Java 8... [smoker] [smoker] Crawl/parse... [smoker] [smoker] Verify... [smoker] confirm all releases have coverage in TestBackwardsCompatibility [smoker] find all past Lucene releases... [smoker] run TestBackwardsCompatibility.. [smoker] success! [smoker] [smoker] Test Solr... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.06 sec (4.0 MB/sec) [smoker] check changes HTML... [smoker] download solr-7.3.0-src.tgz... [smoker] 54.0 MB in 2.10 sec (25.7 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-7.3.0.tgz... [smoker] 151.5 MB in 3.07 sec (49.3 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-7.3.0.zip... [smoker] 152.5 MB in 5.03 sec (30.3 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack solr-7.3.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-7.3.0.tgz... [smoker] **WARNING**: skipping check of /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.3.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar: it has javax.* classes [smoker] **WARNING**: skipping check of /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.3.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: it has javax.* classes [smoker] copying unpacked distribution for Java 8 ... [smoker] test solr example w/ Java 8... [smoker] start Solr instance (log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.3.0-java8/solr-example.log)... [smoker] No process found for Solr node running on port 8983 [smoker] Running techproducts example on port 8983 from /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.3.0-java8 [smoker] *** [WARN] *** Your open file limit is currently 6. [smoker] It should be set to 65000 to avoid operational disruption. [smoker] If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to false in your profile or solr.in.sh [smoker] *** [WARN] *** Your Max Processes Limit is currently 10240. [smoker] It should be set to 65000 to avoid operational disruption. [smoker] If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to false in your profile or solr.in.sh [smoker] Creating Solr home directory
[jira] [Commented] (SOLR-11066) Implement a scheduled trigger
[
https://issues.apache.org/jira/browse/SOLR-11066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16343038#comment-16343038
]
Andrzej Bialecki commented on SOLR-11066:
--
+1 to require {{Z}} and UTC, with optional {{TZ}}. I think that ultimately it’s
better to mandate a single format for a time instant, at least in the config -
we could be perhaps more lenient in the user APIs, or provide a suggested value
expressed in UTC inside the error message.
> Implement a scheduled trigger
> -
>
> Key: SOLR-11066
> URL: https://issues.apache.org/jira/browse/SOLR-11066
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11066.patch, SOLR-11066.patch
>
>
> Implement a trigger that runs on a fixed interval say every 1 hour or every
> 24 hours starting at midnight etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
