[JENKINS-EA] Lucene-Solr-BadApples-7.x-Linux (64bit/jdk-10-ea+43) - Build # 8 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/8/
Java: 64bit/jdk-10-ea+43 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

9 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:40995/solr/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:40995/solr/collection1
at 
__randomizedtesting.SeedInfo.seed([46C32BA68EC3222E:9E34EF422518E072]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:657)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:173)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:152)
at 
org.apache.solr.handler.TestReplicationHandler.index(TestReplicationHandler.java:180)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:643)
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 

[jira] [Commented] (SOLR-12063) Fix tlog entry indexes in UpdateLog for CDCR to work smoothly.

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-12063:
--

Okay let's commit SOLR-12083 first and then use the randomization from there to 
TestStressRecovery as part of this patch ? 

> Fix tlog entry indexes in UpdateLog for CDCR to work smoothly.
> --
>
> Key: SOLR-12063
> URL: https://issues.apache.org/jira/browse/SOLR-12063
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12063.patch, SOLR-12063.patch, SOLR-12063.patch, 
> SOLR-12063.patch, test-report-PeerSyncTest, test-report-TestStressRecovery
>
>
> In *UpdateLog*, {{RecentUpdates}} reads the entry of tlogs, and throughout 
> the project the entry indexes for various operations are consistent, but odd 
> in this part. As we included new entry in TransactionLog for CDCR, read 
> operations in {{update()}} method of {{RecentUpdates}} throw error rightfully 
> as elements are read from wrong indexes of tlog entry. The entry indexes of 
> llog should be consistent throughout.
> {code}
>   [beaster]   2> 27394 WARN  (qtp97093533-72) [n:127.0.0.1:44658_solr 
> c:cdcr-cluster1 s:shard1 r:core_node3 x:cdcr-cluster1_shard1_replica_n1] 
> o.a.s.u.UpdateLog Unexpected log entry or corrupt log.  Entry=[2, 
> -1594312216007409664, [B@28e6859c, true]
>   [beaster]   2> java.lang.ClassCastException: java.lang.Boolean cannot be 
> cast to [B
>   [beaster]   2>  at 
> org.apache.solr.update.UpdateLog$RecentUpdates.update(UpdateLog.java:1443)
>   [beaster]   2>  at 
> org.apache.solr.update.UpdateLog$RecentUpdates.(UpdateLog.java:1340)
>   [beaster]   2>  at 
> org.apache.solr.update.UpdateLog.getRecentUpdates(UpdateLog.java:1513)
>   [beaster]   2>  at 
> org.apache.solr.handler.CdcrRequestHandler.handleShardCheckpointAction(CdcrRequestHandler.java:448)
>   [beaster]   2>  at 
> org.apache.solr.handler.CdcrRequestHandler.handleRequestBody(CdcrRequestHandler.java:198)
>   [beaster]   2>  at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
>   [beaster]   2>  at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
>   [beaster]   2>  at 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   [beaster]   2>  at 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:517)
>   [beaster]   2>  at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)
>   [beaster]   2>  at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)
>   [beaster]   2>  at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>   [beaster]   2>  at 
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
>   [beaster]   2>  at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>   [beaster]   2>  at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
>   [beaster]   2>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>   [beaster]   2>  at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
>   [beaster]   2>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>   [beaster]   2>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
>   [beaster]   2>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
>   [beaster]   2>  at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
>   [beaster]   2>  at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
> {code}



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

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

[jira] [Updated] (SOLR-12090) Move DistribStateManager, NodeStateProvider and SolrCloudManager interfaces out of the autoscaling package

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-12090:
-
Attachment: SOLR-12090.patch

> Move DistribStateManager, NodeStateProvider and SolrCloudManager interfaces 
> out of the autoscaling package
> --
>
> Key: SOLR-12090
> URL: https://issues.apache.org/jira/browse/SOLR-12090
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12090.patch
>
>




--
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-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Varun Thacker (JIRA)]

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

Varun Thacker edited comment on SOLR-12083 at 3/14/18 5:21 AM:
---

Thanks Amrit for working on this!

I kind of like the SOLR-12083-A-within-test-framework.patch approach better

Couple of things about the SOLR-12083-A-within-test-framework.patch patch
 * Any reason why we don't randomzie the update log in 
TestInPlaceUpdatesDistrib like we do in the other approach?
 * Can we log in randomizeUpdateLogClsProp which update log is being used
 * A small refactor could be instead of using a sysprop and then reading the 
sysprop in SolrTestCaseJ4 to call randomizeUpdateLogClsProp , why not just make 
randomizeUpdateLogClsProp and clearUpdateLogClsProp public and call them 
directly in the beforeClass/afterClass method of TestInPlaceUpdatesDistrib / 
UpdateLogTest . What do you think?

Also when uploading a patch with the changes folded in can you please call the 
patch SOLR-12083.patch


was (Author: varunthacker):
Thanks Amrit for working on this!

I kind of like the SOLR-12083-A-within-test-framework.patch approach better

Couple of things about the SOLR-12083-A-within-test-framework.patch patch
 * Any reason why we don't randomzie the update log in 
TestInPlaceUpdatesDistrib like we do in the other approach?
 * Can we log in randomizeUpdateLogClsProp which update log is being used
 * A small refactor could be instead of using a sysprop and then reading the 
sysprop in SolrTestCaseJ4 to call randomizeUpdateLogClsProp , why not just make 
randomizeUpdateLogClsProp and clearUpdateLogClsProp public and call them 
directly in the beforeClass/afterClass method of TestInPlaceUpdatesDistrib / 
UpdateLogTest . What do you think?

Also when uploading a patch with the changes folded in can you please call the 
patch SOLR-12083.patch

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> When we were adding bi-directional sync support in CDCR ( SOLR-11003 ) we 
> changed the CDCR Update Log codec to write an extra bits. 
> When we use the RealTimeGet component on a cluster running CDCR and have 
> in-place updates in the update log we will falsely trip an assert thus 
> causing the request to fail
> Here's the proposed change
> {code:java}
> - assert entry.size() == 5;
> + if (ulog instanceof CdcrUpdateLog) {
> +   assert entry.size() == 6;
> + }
> + else {
> +   assert entry.size() == 5;
> + }{code}
>  



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

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

[jira] [Commented] (SOLR-12063) Fix tlog entry indexes in UpdateLog for CDCR to work smoothly.

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-12063:
--

{quote}{{TestStressRecovery}} throws the {{Unexpected log entry or corrupt log. 
Entry=..}} but test doesn't fail
{quote}
I think that's fine. Currently the design decision is to throw a WARN and not 
an Exception 

> Fix tlog entry indexes in UpdateLog for CDCR to work smoothly.
> --
>
> Key: SOLR-12063
> URL: https://issues.apache.org/jira/browse/SOLR-12063
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12063.patch, SOLR-12063.patch, SOLR-12063.patch, 
> SOLR-12063.patch, test-report-PeerSyncTest, test-report-TestStressRecovery
>
>
> In *UpdateLog*, {{RecentUpdates}} reads the entry of tlogs, and throughout 
> the project the entry indexes for various operations are consistent, but odd 
> in this part. As we included new entry in TransactionLog for CDCR, read 
> operations in {{update()}} method of {{RecentUpdates}} throw error rightfully 
> as elements are read from wrong indexes of tlog entry. The entry indexes of 
> llog should be consistent throughout.
> {code}
>   [beaster]   2> 27394 WARN  (qtp97093533-72) [n:127.0.0.1:44658_solr 
> c:cdcr-cluster1 s:shard1 r:core_node3 x:cdcr-cluster1_shard1_replica_n1] 
> o.a.s.u.UpdateLog Unexpected log entry or corrupt log.  Entry=[2, 
> -1594312216007409664, [B@28e6859c, true]
>   [beaster]   2> java.lang.ClassCastException: java.lang.Boolean cannot be 
> cast to [B
>   [beaster]   2>  at 
> org.apache.solr.update.UpdateLog$RecentUpdates.update(UpdateLog.java:1443)
>   [beaster]   2>  at 
> org.apache.solr.update.UpdateLog$RecentUpdates.(UpdateLog.java:1340)
>   [beaster]   2>  at 
> org.apache.solr.update.UpdateLog.getRecentUpdates(UpdateLog.java:1513)
>   [beaster]   2>  at 
> org.apache.solr.handler.CdcrRequestHandler.handleShardCheckpointAction(CdcrRequestHandler.java:448)
>   [beaster]   2>  at 
> org.apache.solr.handler.CdcrRequestHandler.handleRequestBody(CdcrRequestHandler.java:198)
>   [beaster]   2>  at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
>   [beaster]   2>  at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
>   [beaster]   2>  at 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   [beaster]   2>  at 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:517)
>   [beaster]   2>  at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)
>   [beaster]   2>  at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)
>   [beaster]   2>  at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>   [beaster]   2>  at 
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
>   [beaster]   2>  at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>   [beaster]   2>  at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
>   [beaster]   2>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>   [beaster]   2>  at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
>   [beaster]   2>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>   [beaster]   2>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
>   [beaster]   2>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
>   [beaster]   2>  at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
>   [beaster]   2>  at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
> {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] [Created] (SOLR-12090) Move DistribStateManager, NodeStateProvider and SolrCloudManager interfaces out of the autoscaling package

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-12090:


 Summary: Move DistribStateManager, NodeStateProvider and 
SolrCloudManager interfaces out of the autoscaling package
 Key: SOLR-12090
 URL: https://issues.apache.org/jira/browse/SOLR-12090
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
 Fix For: 7.4, master (8.0)






--
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-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Varun Thacker (JIRA)]

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

Varun Thacker edited comment on SOLR-12083 at 3/14/18 5:07 AM:
---

Thanks Amrit for working on this!

I kind of like the SOLR-12083-A-within-test-framework.patch approach better

Couple of things about the SOLR-12083-A-within-test-framework.patch patch
 * Any reason why we don't randomzie the update log in 
TestInPlaceUpdatesDistrib like we do in the other approach?
 * Can we log in randomizeUpdateLogClsProp which update log is being used
 * A small refactor could be instead of using a sysprop and then reading the 
sysprop in SolrTestCaseJ4 to call randomizeUpdateLogClsProp , why not just make 
randomizeUpdateLogClsProp and clearUpdateLogClsProp public and call them 
directly in the beforeClass/afterClass method of TestInPlaceUpdatesDistrib / 
UpdateLogTest . What do you think?

Also when uploading a patch with the changes folded in can you please call the 
patch SOLR-12083.patch


was (Author: varunthacker):
Thanks Amrit for working on this!

I kind of like the SOLR-12083-A-within-test-framework.patch approach better

Couple of things about the SOLR-12083-A-within-test-framework.patch patch
 * Any reason why we don't randomzie the update log in 
TestInPlaceUpdatesDistrib like we do in the other approach?
 * Can we log in randomizeUpdateLogClsProp which update log is being used
 * A small refactor could be instead of using a sysprop and then reading the 
sysprop in SolrTestCaseJ4 to call randomizeUpdateLogClsProp , why not just make 
randomizeUpdateLogClsProp and clearUpdateLogClsProp public and call them 
directly in the beforeClass/afterClass method of TestInPlaceUpdatesDistrib / 
UpdateLogTest . What do you think?

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> When we were adding bi-directional sync support in CDCR ( SOLR-11003 ) we 
> changed the CDCR Update Log codec to write an extra bits. 
> When we use the RealTimeGet component on a cluster running CDCR and have 
> in-place updates in the update log we will falsely trip an assert thus 
> causing the request to fail
> Here's the proposed change
> {code:java}
> - assert entry.size() == 5;
> + if (ulog instanceof CdcrUpdateLog) {
> +   assert entry.size() == 6;
> + }
> + else {
> +   assert entry.size() == 5;
> + }{code}
>  



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

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

[jira] [Updated] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-12083:
-
Description: 
When we were adding bi-directional sync support in CDCR ( SOLR-11003 ) we 
changed the CDCR Update Log codec to write an extra bits. 

When we use the RealTimeGet component on a cluster running CDCR and have 
in-place updates in the update log we will falsely trip an assert thus causing 
the request to fail

Here's the proposed change
{code:java}
- assert entry.size() == 5;
+ if (ulog instanceof CdcrUpdateLog) {
+   assert entry.size() == 6;
+ }
+ else {
+   assert entry.size() == 5;
+ }{code}
 

  was:
On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
here RealTimeGetComponent is broken. 

As we have added additional flag to each {{tlog}} entry, the following 
assertions fail when Cdcr enabled:
{code}
if (oper == UpdateLog.UPDATE_INPLACE) {
 assert entry.size() == 5;
}
{code}


> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> When we were adding bi-directional sync support in CDCR ( SOLR-11003 ) we 
> changed the CDCR Update Log codec to write an extra bits. 
> When we use the RealTimeGet component on a cluster running CDCR and have 
> in-place updates in the update log we will falsely trip an assert thus 
> causing the request to fail
> Here's the proposed change
> {code:java}
> - assert entry.size() == 5;
> + if (ulog instanceof CdcrUpdateLog) {
> +   assert entry.size() == 6;
> + }
> + else {
> +   assert entry.size() == 5;
> + }{code}
>  



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

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

[jira] [Updated] (SOLR-12066) Autoscaling move replica can cause core initialization failure on the original JVM

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-12066:
-
Fix Version/s: master (8.0)
   7.4

> Autoscaling move replica can cause core initialization failure on the 
> original JVM
> --
>
> Key: SOLR-12066
> URL: https://issues.apache.org/jira/browse/SOLR-12066
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Varun Thacker
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> Initially when SOLR-12047 was created it looked like waiting for a state in 
> ZK for only 3 seconds was the culprit for cores not loading up
>  
> But it turns out to be something else. Here are the steps to reproduce this 
> problem
>  
>  - create a 3 node cluster
>  - create a 1 shard X 2 replica collection to use node1 and node2 ( 
> [http://localhost:8983/solr/admin/collections?action=create=test_node_lost=1=2=true]
>  )
>  - stop node 2 : ./bin/solr stop -p 7574
>  - Solr will create a new replica on node3 after 30 seconds because of the 
> ".auto_add_replicas" trigger
>  - At this point state.json has info about replicas being on node1 and node3
>  - Start node2. Bam!
> {code:java}
> java.util.concurrent.ExecutionException: 
> org.apache.solr.common.SolrException: Unable to create core 
> [test_node_lost_shard1_replica_n2]
> ...
> Caused by: org.apache.solr.common.SolrException: Unable to create core 
> [test_node_lost_shard1_replica_n2]
> at 
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1053)
> ...
> Caused by: org.apache.solr.common.SolrException: 
> at org.apache.solr.cloud.ZkController.preRegister(ZkController.java:1619)
> at 
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1030)
> ...
> Caused by: org.apache.solr.common.SolrException: coreNodeName core_node4 does 
> not exist in shard shard1: 
> DocCollection(test_node_lost//collections/test_node_lost/state.json/12)={
> ...{code}
>  
> The practical effects of this is not big since the move replica has already 
> put the replica on another JVM . But to the user it's super confusing on 
> what's happening. He can never get rid of this error unless he manually 
> cleans up the data directory on node2 and restart
>  
> Please note: I chose autoAddReplicas=true to reproduce this. but a user could 
> be using a node lost trigger and and run into the same issue



--
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-12066) Autoscaling move replica can cause core initialization failure on the original JVM

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-12066:
-
Component/s: SolrCloud
 AutoScaling

> Autoscaling move replica can cause core initialization failure on the 
> original JVM
> --
>
> Key: SOLR-12066
> URL: https://issues.apache.org/jira/browse/SOLR-12066
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Varun Thacker
>Priority: Major
>
> Initially when SOLR-12047 was created it looked like waiting for a state in 
> ZK for only 3 seconds was the culprit for cores not loading up
>  
> But it turns out to be something else. Here are the steps to reproduce this 
> problem
>  
>  - create a 3 node cluster
>  - create a 1 shard X 2 replica collection to use node1 and node2 ( 
> [http://localhost:8983/solr/admin/collections?action=create=test_node_lost=1=2=true]
>  )
>  - stop node 2 : ./bin/solr stop -p 7574
>  - Solr will create a new replica on node3 after 30 seconds because of the 
> ".auto_add_replicas" trigger
>  - At this point state.json has info about replicas being on node1 and node3
>  - Start node2. Bam!
> {code:java}
> java.util.concurrent.ExecutionException: 
> org.apache.solr.common.SolrException: Unable to create core 
> [test_node_lost_shard1_replica_n2]
> ...
> Caused by: org.apache.solr.common.SolrException: Unable to create core 
> [test_node_lost_shard1_replica_n2]
> at 
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1053)
> ...
> Caused by: org.apache.solr.common.SolrException: 
> at org.apache.solr.cloud.ZkController.preRegister(ZkController.java:1619)
> at 
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1030)
> ...
> Caused by: org.apache.solr.common.SolrException: coreNodeName core_node4 does 
> not exist in shard shard1: 
> DocCollection(test_node_lost//collections/test_node_lost/state.json/12)={
> ...{code}
>  
> The practical effects of this is not big since the move replica has already 
> put the replica on another JVM . But to the user it's super confusing on 
> what's happening. He can never get rid of this error unless he manually 
> cleans up the data directory on node2 and restart
>  
> Please note: I chose autoAddReplicas=true to reproduce this. but a user could 
> be using a node lost trigger and and run into the same issue



--
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] [Assigned] (SOLR-12086) Format Problem on Cache Statistics Page

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar reassigned SOLR-12086:


 Assignee: Shalin Shekhar Mangar
Affects Version/s: 7.3
Fix Version/s: master (8.0)
   7.4

> Format Problem on Cache Statistics Page
> ---
>
> Key: SOLR-12086
> URL: https://issues.apache.org/jira/browse/SOLR-12086
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.0, 7.1, 7.2, 7.3
>Reporter: Sathiya N Sundararajan
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
>  Labels: newbie, patch, patch-available
> Fix For: 7.2.2, 7.4, master (8.0)
>
> Attachments: 
> 0001-SOLR-12086-Format-Problem-on-Cache-Statistics-Page.patch, Screen Shot 
> 2018-03-13 at 9.21.50 AM.png
>
>
> Noticed minor formatting issue on Cache Stats page in `Solr 7.2.1`
>  
> should be `ramMaxSize{color:#ff}={color}536870912`
> right now its `ramMaxSize536870912`



--
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-12086) Format Problem on Cache Statistics Page

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12086:


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

SOLR-12086: Fix format problem in FastLRUCache description string shown on 
Cache Statistics page

(cherry picked from commit 9de0ebe)


> Format Problem on Cache Statistics Page
> ---
>
> Key: SOLR-12086
> URL: https://issues.apache.org/jira/browse/SOLR-12086
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.0, 7.1, 7.2
>Reporter: Sathiya N Sundararajan
>Priority: Minor
>  Labels: newbie, patch, patch-available
> Fix For: 7.2.2
>
> Attachments: 
> 0001-SOLR-12086-Format-Problem-on-Cache-Statistics-Page.patch, Screen Shot 
> 2018-03-13 at 9.21.50 AM.png
>
>
> Noticed minor formatting issue on Cache Stats page in `Solr 7.2.1`
>  
> should be `ramMaxSize{color:#ff}={color}536870912`
> right now its `ramMaxSize536870912`



--
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-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-12083:
--

Thanks Amrit for working on this!

I kind of like the SOLR-12083-A-within-test-framework.patch approach better

Couple of things about the SOLR-12083-A-within-test-framework.patch patch
 * Any reason why we don't randomzie the update log in 
TestInPlaceUpdatesDistrib like we do in the other approach?
 * Can we log in randomizeUpdateLogClsProp which update log is being used
 * A small refactor could be instead of using a sysprop and then reading the 
sysprop in SolrTestCaseJ4 to call randomizeUpdateLogClsProp , why not just make 
randomizeUpdateLogClsProp and clearUpdateLogClsProp public and call them 
directly in the beforeClass/afterClass method of TestInPlaceUpdatesDistrib / 
UpdateLogTest . What do you think?

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {code}



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

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

[jira] [Commented] (SOLR-12086) Format Problem on Cache Statistics Page

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12086:


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

SOLR-12086: Fix format problem in FastLRUCache description string shown on 
Cache Statistics page


> Format Problem on Cache Statistics Page
> ---
>
> Key: SOLR-12086
> URL: https://issues.apache.org/jira/browse/SOLR-12086
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.0, 7.1, 7.2
>Reporter: Sathiya N Sundararajan
>Priority: Minor
>  Labels: newbie, patch, patch-available
> Fix For: 7.2.2
>
> Attachments: 
> 0001-SOLR-12086-Format-Problem-on-Cache-Statistics-Page.patch, Screen Shot 
> 2018-03-13 at 9.21.50 AM.png
>
>
> Noticed minor formatting issue on Cache Stats page in `Solr 7.2.1`
>  
> should be `ramMaxSize{color:#ff}={color}536870912`
> right now its `ramMaxSize536870912`



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

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

[JENKINS] Lucene-Solr-BadApples-NightlyTests-7.x - Build # 2 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-7.x/2/

10 tests failed.
FAILED:  org.apache.solr.cloud.RestartWhileUpdatingTest.test

Error Message:
There are still nodes recoverying - waited for 320 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 320 
seconds
at 
__randomizedtesting.SeedInfo.seed([AF42AF945BE7BEEA:2716904EF51BD312]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:185)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:921)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1478)
at 
org.apache.solr.cloud.RestartWhileUpdatingTest.test(RestartWhileUpdatingTest.java:144)
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 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
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 

[jira] [Commented] (SOLR-12088) Shards with dead replicas cause increased write latency

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-12088:
--

Hi Jerry,

So if I was to put it in another way if this was the scenario then shard2's 
write latency will be higher? 

shard1 : has 3 "active" replicas

shard2 : has 3 "active" replicas and 3 replicas in "down" state 

Can you tell me a few things about the cluster:

1. How many nodes are there in the cluster

2. Of the N nodes are there nodes that are part of the cluster but not hosting 
any replica of any shard on nodes 

3. Are you indexing via a SolrJ based client ? 

4. How are you measuring the latency? JMX ?

> Shards with dead replicas cause increased write latency
> ---
>
> Key: SOLR-12088
> URL: https://issues.apache.org/jira/browse/SOLR-12088
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.2
>Reporter: Jerry Bao
>Priority: Major
>
> If a collection's shard contains dead replicas, write latency to the 
> collection is increased. For example, if a collection has 10 shards with a 
> replication factor of 3, and one of those shards contains 3 replicas and 3 
> downed replicas, write latency is increased in comparison to a shard that 
> contains only 3 replicas.
> My feeling here is that downed replicas should be completely ignored and not 
> cause issues to other alive replicas in terms of write latency.



--
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-12089) FileBasedSpellChecker docs have some missing params

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-12089:


 Summary: FileBasedSpellChecker docs have some missing params
 Key: SOLR-12089
 URL: https://issues.apache.org/jira/browse/SOLR-12089
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker


FileBasedSpellChecker has params like "fieldType" that is not documented.

I'm creating a Jira to audit the params on all the spellcheckers and make sure 
they are documented in the ref guide 
http://lucene.apache.org/solr/guide/spell-checking.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

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

[Policeman Jenkins Server]

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

10 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:40481/solr/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:40481/solr/collection1
at 
__randomizedtesting.SeedInfo.seed([1FE03CB41C225DC7:C717F850B7F99F9B]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:657)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:173)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:152)
at 
org.apache.solr.handler.TestReplicationHandler.index(TestReplicationHandler.java:180)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:643)
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 

[jira] [Commented] (SOLR-12087) Deleting shards sometimes fails and causes the shard to exist in the down state

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-12087:
--

What's the error from the logs during the delete call? 

> Deleting shards sometimes fails and causes the shard to exist in the down 
> state
> ---
>
> Key: SOLR-12087
> URL: https://issues.apache.org/jira/browse/SOLR-12087
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.2
>Reporter: Jerry Bao
>Priority: Major
>
> Sometimes when deleting replicas, the replica fails to be removed from the 
> cluster state. This occurs especially when deleting replicas en mass; the 
> resulting cause is that the data is deleted but the replicas aren't removed 
> from the cluster state. Attempting to delete the downed replicas causes 
> failures because the core does not exist anymore.
> It seems like when deleting replicas, ZK writes are timing out, preventing 
> the cluster state from being properly updated.



--
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 # 4494 - Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.SSLMigrationTest.test

Error Message:
Replica didn't have the proper urlScheme in the ClusterState

Stack Trace:
java.lang.AssertionError: Replica didn't have the proper urlScheme in the 
ClusterState
at 
__randomizedtesting.SeedInfo.seed([C82354A89BC073E:84D60A9027406AC6]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SSLMigrationTest.assertReplicaInformation(SSLMigrationTest.java:103)
at 
org.apache.solr.cloud.SSLMigrationTest.testMigrateSSL(SSLMigrationTest.java:96)
at org.apache.solr.cloud.SSLMigrationTest.test(SSLMigrationTest.java:60)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
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 

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

[Policeman Jenkins Server]

Error processing tokens: Error while parsing action 
'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input 
position (line 79, pos 4):
)"}
   ^

java.lang.OutOfMemoryError: Java heap space

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

[jira] [Created] (SOLR-12088) Shards with dead replicas cause increased write latency

[Jerry Bao (JIRA)]

Jerry Bao created SOLR-12088:


 Summary: Shards with dead replicas cause increased write latency
 Key: SOLR-12088
 URL: https://issues.apache.org/jira/browse/SOLR-12088
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Affects Versions: 7.2
Reporter: Jerry Bao


If a collection's shard contains dead replicas, write latency to the collection 
is increased. For example, if a collection has 10 shards with a replication 
factor of 3, and one of those shards contains 3 replicas and 3 downed replicas, 
write latency is increased in comparison to a shard that contains only 3 
replicas.

My feeling here is that downed replicas should be completely ignored and not 
cause issues to other alive replicas in terms of write latency.



--
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-12087) Deleting shards sometimes fails and causes the shard to exist in the down state

[Sathiya N (JIRA)]

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

Sathiya N commented on SOLR-12087:
--

Deletes are done via DELETE Command.

*Steps*:

1. Create a replica in new node.
2. Delete the existing replica in previous node.

and Deletes fail (sometimes) leaving the zombie replicas in a down state.

 

 

> Deleting shards sometimes fails and causes the shard to exist in the down 
> state
> ---
>
> Key: SOLR-12087
> URL: https://issues.apache.org/jira/browse/SOLR-12087
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.2
>Reporter: Jerry Bao
>Priority: Major
>
> Sometimes when deleting replicas, the replica fails to be removed from the 
> cluster state. This occurs especially when deleting replicas en mass; the 
> resulting cause is that the data is deleted but the replicas aren't removed 
> from the cluster state. Attempting to delete the downed replicas causes 
> failures because the core does not exist anymore.
> It seems like when deleting replicas, ZK writes are timing out, preventing 
> the cluster state from being properly updated.



--
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 (32bit/jdk1.8.0_162) - Build # 1528 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1528/
Java: 32bit/jdk1.8.0_162 -server -XX:+UseG1GC

4 tests failed.
FAILED:  org.apache.solr.spelling.SpellCheckCollatorTest.testEstimatedHitCounts

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([8CD7520189270179:BD6CEC342C1811A9]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:908)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:868)
at 
org.apache.solr.spelling.SpellCheckCollatorTest.testEstimatedHitCounts(SpellCheckCollatorTest.java:569)
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)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//lst[@name='spellcheck']/lst[@name='collations']/lst[@name='collation']/long[@name='hits'
 and 3 <= . and . <= 13]
xml response was: 

051918everyotherteststop:everyother14everyother


   

[jira] [Created] (SOLR-12087) Deleting shards sometimes fails and causes the shard to exist in the down state

[Jerry Bao (JIRA)]

Jerry Bao created SOLR-12087:


 Summary: Deleting shards sometimes fails and causes the shard to 
exist in the down state
 Key: SOLR-12087
 URL: https://issues.apache.org/jira/browse/SOLR-12087
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Affects Versions: 7.2
Reporter: Jerry Bao


Sometimes when deleting replicas, the replica fails to be removed from the 
cluster state. This occurs especially when deleting replicas en mass; the 
resulting cause is that the data is deleted but the replicas aren't removed 
from the cluster state. Attempting to delete the downed replicas causes 
failures because the core does not exist anymore.

It seems like when deleting replicas, ZK writes are timing out, preventing the 
cluster state from being properly updated.



--
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-12086) Format Problem on Cache Statistics Page

[Sathiya N (JIRA)]

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

Sathiya N updated SOLR-12086:
-
Attachment: 0001-SOLR-12086-Format-Problem-on-Cache-Statistics-Page.patch

> Format Problem on Cache Statistics Page
> ---
>
> Key: SOLR-12086
> URL: https://issues.apache.org/jira/browse/SOLR-12086
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.2
>Reporter: Sathiya N
>Priority: Minor
> Attachments: 
> 0001-SOLR-12086-Format-Problem-on-Cache-Statistics-Page.patch, Screen Shot 
> 2018-03-13 at 9.21.50 AM.png
>
>
> Noticed minor formatting issue on Cache Stats page in `Solr 7.2.1`
>  
> should be `ramMaxSize{color:#ff}={color}536870912`
> right now its `ramMaxSize536870912`



--
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-11267) Add support for "add-distinct" atomic update operation

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-11267.
---
   Resolution: Fixed
Fix Version/s: master (8.0)

> Add support for "add-distinct" atomic update operation
> --
>
> Key: SOLR-11267
> URL: https://issues.apache.org/jira/browse/SOLR-11267
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-11267.patch, SOLR-11267.patch, SOLR-11267.patch
>
>
> Often, a multivalued field is used as a set of values. Since multivalued 
> fields are more like lists than sets, users do two consecutive operations, 
> remove and add, to insert an element into the field and also maintain the 
> set's property of only having unique elements.
> Proposing a new single operation, called "add-distinct" (which essentially 
> means "add-if-doesn't exist") for this.



--
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/jdk-9.0.1) - Build # 502 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/502/
Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseG1GC

No tests ran.

Build Log:
[...truncated 13 lines...]
FATAL: Could not delete file 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build.repro\solr-core\classes\java\org\apache\solr\internal
java.io.IOException: Could not delete file 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build.repro\solr-core\classes\java\org\apache\solr\internal
at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:197)
at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:166)
at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:166)
at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:166)
at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:166)
at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:166)
at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:166)
at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:166)
at org.eclipse.jgit.api.CleanCommand.cleanPath(CleanCommand.java:176)
at org.eclipse.jgit.api.CleanCommand.call(CleanCommand.java:133)
Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to Windows VBOX
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1737)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:313)
at hudson.remoting.Channel.call(Channel.java:952)
at 
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:278)
at com.sun.proxy.$Proxy65.clean(Unknown Source)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl.clean(RemoteGitImpl.java:450)
at 
hudson.plugins.git.extensions.impl.CleanBeforeCheckout.decorateFetchCommand(CleanBeforeCheckout.java:30)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:858)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1129)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1160)
at hudson.scm.SCM.checkout(SCM.java:504)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1727)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused: org.eclipse.jgit.api.errors.JGitInternalException: Could not delete 
file 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build.repro\solr-core\classes\java\org\apache\solr\internal
at org.eclipse.jgit.api.CleanCommand.call(CleanCommand.java:136)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl.clean(JGitAPIImpl.java:1290)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:927)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:901)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:850)
at hudson.remoting.UserRequest.perform(UserRequest.java:210)
at hudson.remoting.UserRequest.perform(UserRequest.java:53)
at hudson.remoting.Request$2.run(Request.java:364)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: Test reports were found 
but none of them are new. Did leafNodes run? 
For example, 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build.repro\solr-core\test\TEST-org.apache.solr.handler.component.DistributedTermsComponentTest-2.xml
 is 9 hr 33 min old

Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Commented] (SOLR-11267) Add support for "add-distinct" atomic update operation

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11267:
-

bq. It's already in 7.3 branch

Wonderful.  There was a missed commit into JIRA then, so I was confused as to 
the status (not to mention the issue hasn't been resolved)

> Add support for "add-distinct" atomic update operation
> --
>
> Key: SOLR-11267
> URL: https://issues.apache.org/jira/browse/SOLR-11267
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-11267.patch, SOLR-11267.patch, SOLR-11267.patch
>
>
> Often, a multivalued field is used as a set of values. Since multivalued 
> fields are more like lists than sets, users do two consecutive operations, 
> remove and add, to insert an element into the field and also maintain the 
> set's property of only having unique elements.
> Proposing a new single operation, called "add-distinct" (which essentially 
> means "add-if-doesn't exist") for this.



--
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-11267) Add support for "add-distinct" atomic update operation

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-11267 at 3/13/18 9:33 PM:


It's already in 7.3 branch


was (Author: noble.paul):
It can be committed to the 7.3 branch

> Add support for "add-distinct" atomic update operation
> --
>
> Key: SOLR-11267
> URL: https://issues.apache.org/jira/browse/SOLR-11267
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-11267.patch, SOLR-11267.patch, SOLR-11267.patch
>
>
> Often, a multivalued field is used as a set of values. Since multivalued 
> fields are more like lists than sets, users do two consecutive operations, 
> remove and add, to insert an element into the field and also maintain the 
> set's property of only having unique elements.
> Proposing a new single operation, called "add-distinct" (which essentially 
> means "add-if-doesn't exist") for this.



--
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-11267) Add support for "add-distinct" atomic update operation

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-11267:
---

It can be committed to the 7.3 branch

> Add support for "add-distinct" atomic update operation
> --
>
> Key: SOLR-11267
> URL: https://issues.apache.org/jira/browse/SOLR-11267
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-11267.patch, SOLR-11267.patch, SOLR-11267.patch
>
>
> Often, a multivalued field is used as a set of values. Since multivalued 
> fields are more like lists than sets, users do two consecutive operations, 
> remove and add, to insert an element into the field and also maintain the 
> set's property of only having unique elements.
> Proposing a new single operation, called "add-distinct" (which essentially 
> means "add-if-doesn't exist") for this.



--
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-9.0.1) - Build # 7221 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7221/
Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseG1GC

9 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:53423/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:53423/collection1
at 
__randomizedtesting.SeedInfo.seed([8600B2C806863AFF:E548D12A87A5707]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1105)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:885)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:818)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1591)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:212)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
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 

[jira] [Updated] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: (was: SOLR-12083-A-within-test-framework.patch)

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {code}



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

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

[jira] [Updated] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: SOLR-12083-A-within-test-framework.patch
add_support_for_random_ulog_in_tests.patch

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {code}



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

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

[jira] [Updated] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: (was: add_support_for_random_ulog_in_tests.patch)

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {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

[GitHub] lucene-solr pull request #287: SOLR-11331: Ability to Debug Solr With Eclips...

[uschindler]

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

https://github.com/apache/lucene-solr/pull/287#discussion_r174281383
  
--- Diff: dev-tools/eclipse/dot.classpath.xsl ---
@@ -54,7 +55,23 @@
   
 
   
-  
+ 
--- End diff --

sure!


---

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

Re: [JENKINS] Lucene-Solr-Tests-master - Build # 2422 - Unstable

[Dawid Weiss]

There is code in that test that relies on wall time.

  final long stopTime = System.currentTimeMillis() + 200;

I don't think this is a good idea, it will trigger odd exceptions on
heavily loaded test machines.

Dawid

On Tue, Mar 13, 2018 at 9:28 PM, Dawid Weiss  wrote:
> Doesn't reproduce for me, but looks suspicious?
>
>[junit4] Suite: org.apache.lucene.index.TestIndexWriterWithThreads
>[junit4]   2> NOTE: reproduce with: ant test
> -Dtestcase=TestIndexWriterWithThreads
> -Dtests.method=testCloseWithThreads -Dtests.seed=F74EDD534544EE8
> -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=el
> -Dtests.timezone=America/Tortola -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.64s J0 |
> TestIndexWriterWithThreads.testCloseWithThreads <<<
>[junit4]> Throwable #1: java.lang.AssertionError: thread failed
> before indexing a single document
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([F74EDD534544EE8:12B0C4A257A1544E]:0)
>[junit4]> at
> org.apache.lucene.index.TestIndexWriterWithThreads.testCloseWithThreads(TestIndexWriterWithThreads.java:223)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
>[junit4]   1> org.apache.lucene.store.LockObtainFailedException:
> lock instance already obtained: (dir=RAMDirectory@64acc9e2
> lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@609351af,
> lockName=write.lock)
>[junit4]   1> at
> org.apache.lucene.store.SingleInstanceLockFactory.obtainLock(SingleInstanceLockFactory.java:44)
>[junit4]   1> at
> org.apache.lucene.store.BaseDirectory.obtainLock(BaseDirectory.java:45)
>[junit4]   1> at
> org.apache.lucene.store.FilterDirectory.obtainLock(FilterDirectory.java:104)
>[junit4]   1> at
> org.apache.lucene.store.MockDirectoryWrapper.obtainLock(MockDirectoryWrapper.java:1049)
>[junit4]   1> at
> org.apache.lucene.index.IndexWriter.(IndexWriter.java:948)
>[junit4]   1> at
> org.apache.lucene.index.TestIndexWriterWithThreads$DelayedIndexAndCloseRunnable.run(TestIndexWriterWithThreads.java:564)

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

[jira] [Updated] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: (was: SOLR-12083-A-within-test-framework.patch)

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {code}



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

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

[jira] [Updated] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: (was: add_support_for_random_ulog_in_tests.patch)

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {code}



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

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

[jira] [Updated] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: SOLR-12083-A-within-test-framework.patch
add_support_for_random_ulog_in_tests.patch

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {code}



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

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

Re: [JENKINS] Lucene-Solr-Tests-master - Build # 2422 - Unstable

[Dawid Weiss]

Doesn't reproduce for me, but looks suspicious?

   [junit4] Suite: org.apache.lucene.index.TestIndexWriterWithThreads
   [junit4]   2> NOTE: reproduce with: ant test
-Dtestcase=TestIndexWriterWithThreads
-Dtests.method=testCloseWithThreads -Dtests.seed=F74EDD534544EE8
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=el
-Dtests.timezone=America/Tortola -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.64s J0 |
TestIndexWriterWithThreads.testCloseWithThreads <<<
   [junit4]> Throwable #1: java.lang.AssertionError: thread failed
before indexing a single document
   [junit4]> at
__randomizedtesting.SeedInfo.seed([F74EDD534544EE8:12B0C4A257A1544E]:0)
   [junit4]> at
org.apache.lucene.index.TestIndexWriterWithThreads.testCloseWithThreads(TestIndexWriterWithThreads.java:223)
   [junit4]> at java.lang.Thread.run(Thread.java:748)
   [junit4]   1> org.apache.lucene.store.LockObtainFailedException:
lock instance already obtained: (dir=RAMDirectory@64acc9e2
lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@609351af,
lockName=write.lock)
   [junit4]   1> at
org.apache.lucene.store.SingleInstanceLockFactory.obtainLock(SingleInstanceLockFactory.java:44)
   [junit4]   1> at
org.apache.lucene.store.BaseDirectory.obtainLock(BaseDirectory.java:45)
   [junit4]   1> at
org.apache.lucene.store.FilterDirectory.obtainLock(FilterDirectory.java:104)
   [junit4]   1> at
org.apache.lucene.store.MockDirectoryWrapper.obtainLock(MockDirectoryWrapper.java:1049)
   [junit4]   1> at
org.apache.lucene.index.IndexWriter.(IndexWriter.java:948)
   [junit4]   1> at
org.apache.lucene.index.TestIndexWriterWithThreads$DelayedIndexAndCloseRunnable.run(TestIndexWriterWithThreads.java:564)

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

Re: [JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4493 - Failure!

[Dawid Weiss]

Uh, oh. Uwe, I think it's one for you to report! :)

 [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  Internal Error (sharedRuntime.cpp:873), pid=11929,
tid=0x00012033
   [junit4] #  guarantee(nm != NULL) failed: must have containing
nmethod for implicit division-by-zero exceptions

On Tue, Mar 13, 2018 at 3:47 PM, Policeman Jenkins Server
 wrote:
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4493/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC
>
> All tests passed
>
> Build Log:
> [...truncated 1839 lines...]
>[junit4] JVM J1: stdout was not empty, see: 
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/core/test/temp/junit4-J1-20180313_125659_9992744848252775976596.sysout
>[junit4] >>> JVM J1 emitted unexpected output (verbatim) 
>[junit4] codec: Lucene70, pf: TestBloomFilteredLucenePostings, dvf: 
> Asserting
>[junit4] <<< JVM J1: EOF 
>
> [...truncated 11513 lines...]
>[junit4] JVM J0: stdout was not empty, see: 
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/temp/junit4-J0-20180313_131943_979786674861176771711.sysout
>[junit4] >>> JVM J0 emitted unexpected output (verbatim) 
>[junit4] #
>[junit4] # A fatal error has been detected by the Java Runtime Environment:
>[junit4] #
>[junit4] #  Internal Error (sharedRuntime.cpp:873), pid=11929, 
> tid=0x00012033
>[junit4] #  guarantee(nm != NULL) failed: must have containing nmethod for 
> implicit division-by-zero exceptions
>[junit4] #
>[junit4] # JRE version: Java(TM) SE Runtime Environment (8.0_144-b01) 
> (build 1.8.0_144-b01)
>[junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed 
> mode bsd-amd64 )
>[junit4] # Failed to write core dump. Core dumps have been disabled. To 
> enable core dumping, try "ulimit -c unlimited" before starting Java again
>[junit4] #
>[junit4] # An error report file with more information is saved as:
>[junit4] # 
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/J0/hs_err_pid11929.log
>[junit4] #
>[junit4] # If you would like to submit a bug report, please visit:
>[junit4] #   http://bugreport.java.com/bugreport/crash.jsp
>[junit4] #
>[junit4] <<< JVM J0: EOF 
>
> [...truncated 1389 lines...]
>[junit4] ERROR: JVM J0 ended with an exception, command line: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre/bin/java 
> -XX:-UseCompressedOops -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError 
> -XX:HeapDumpPath=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/heapdumps 
> -ea -esa -Dtests.prefix=tests -Dtests.seed=E10269B77231C41B -Xmx512M 
> -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false 
> -Dtests.codec=random -Dtests.postingsformat=random 
> -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random 
> -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz 
> -Dtests.luceneMatchVersion=8.0.0 -Dtests.cleanthreads=perClass 
> -Djava.util.logging.config.file=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/tools/junit4/logging.properties
>  -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
> -Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=1 -DtempDir=./temp 
> -Djava.io.tmpdir=./temp 
> -Djunit4.tempDir=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/temp
>  -Dcommon.dir=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene 
> -Dclover.db.dir=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/clover/db
>  
> -Djava.security.policy=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/tools/junit4/solr-tests.policy
>  -Dtests.LUCENE_VERSION=8.0.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
> -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
> -Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
> -Dtests.src.home=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX 
> -Djava.security.egd=file:/dev/./urandom 
> -Djunit4.childvm.cwd=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/J0
>  -Djunit4.childvm.id=0 -Djunit4.childvm.count=2 -Dtests.leaveTemporary=false 
> -Dtests.filterstacks=true -Dtests.disableHdfs=true -Dtests.badapples=false 
> -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
> -Dfile.encoding=UTF-8 -classpath 
> 

[jira] [Resolved] (SOLR-12081) Improve docs on query parsing: embedded queries, uf (edismax)

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-12081.
-
   Resolution: Fixed
Fix Version/s: 7.3

Thanks for the review Cassandra.  I like how you made the "uf" docs a bulleted 
list of examples -- very nice.  I found an additional thing that needed 
escaping and did it.  Using https://asciidoclive.com/ was very useful to just 
take a particular paragraph/section of interest to work on and feel like the 
results were accurate.  I checked the PDF too.  Unfortunately I can't rely on 
the IntelliJ plugin completely.

BTW I didn't add a CHANGES.txt entry for this issue... IMO it'd be too much 
noise & extra process on top of what we already have for something small-ish 
especially.

> Improve docs on query parsing: embedded queries, uf (edismax)
> -
>
> Key: SOLR-12081
> URL: https://issues.apache.org/jira/browse/SOLR-12081
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.3
>
> Attachments: 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch
>
>
> The {{uf}} parameter is a *space* separated list (not comma). Furthermore the 
> docs should be improved -- see 
> https://issues.apache.org/jira/browse/SOLR-11501?focusedCommentId=16326592=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16326592



--
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-12081) Improve docs on query parsing: embedded queries, uf (edismax)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12081:


Commit 06f89a3671e79e11d4b98565c28bb586203f4fef in lucene-solr's branch 
refs/heads/branch_7_3 from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=06f89a3 ]

SOLR-12081: improve docs on query parsing RE embedded queries, uf

(cherry picked from commit e7dd3fc)


> Improve docs on query parsing: embedded queries, uf (edismax)
> -
>
> Key: SOLR-12081
> URL: https://issues.apache.org/jira/browse/SOLR-12081
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch
>
>
> The {{uf}} parameter is a *space* separated list (not comma). Furthermore the 
> docs should be improved -- see 
> https://issues.apache.org/jira/browse/SOLR-11501?focusedCommentId=16326592=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16326592



--
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-12081) Improve docs on query parsing: embedded queries, uf (edismax)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12081:


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

SOLR-12081: improve docs on query parsing RE embedded queries, uf

(cherry picked from commit e9393e8)


> Improve docs on query parsing: embedded queries, uf (edismax)
> -
>
> Key: SOLR-12081
> URL: https://issues.apache.org/jira/browse/SOLR-12081
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch
>
>
> The {{uf}} parameter is a *space* separated list (not comma). Furthermore the 
> docs should be improved -- see 
> https://issues.apache.org/jira/browse/SOLR-11501?focusedCommentId=16326592=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16326592



--
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-12081) Improve docs on query parsing: embedded queries, uf (edismax)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12081:


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

SOLR-12081: improve docs on query parsing RE embedded queries, uf


> Improve docs on query parsing: embedded queries, uf (edismax)
> -
>
> Key: SOLR-12081
> URL: https://issues.apache.org/jira/browse/SOLR-12081
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch
>
>
> The {{uf}} parameter is a *space* separated list (not comma). Furthermore the 
> docs should be improved -- see 
> https://issues.apache.org/jira/browse/SOLR-11501?focusedCommentId=16326592=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16326592



--
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-11960) Add collection level properties

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-11960:
--

V2 is already verbose which is fine since it's JSON?
Yes, sorry, that's what I meant. In V2 it's just a map, not an odd parameter 
name format

> Add collection level properties
> ---
>
> Key: SOLR-11960
> URL: https://issues.apache.org/jira/browse/SOLR-11960
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Peter Rusko
>Assignee: Tomás Fernández Löbbe
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, 
> SOLR-11960.patch, SOLR-11960.patch
>
>
> Solr has cluster properties, but no easy and extendable way of defining 
> properties that affect a single collection. Collection properties could be 
> stored in a single zookeeper node per collection, making it possible to 
> trigger zookeeper watchers for only those Solr nodes that have cores of that 
> collection.



--
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-11960) Add collection level properties

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11960:
-

bq. The multiple at a time is more "expert" (in V2 it doesn't matter)

What do you mean by "in V2 it doesn't matter"?  Maybe verbosity... as V2 is 
already verbose which is fine since it's JSON?

bq. So, I'd suggest we keep the current format and add the bulk one for 
collection and cluster properties as a separate Jira

+1 We needn't consider this issue a blocker nor open anymore.

> Add collection level properties
> ---
>
> Key: SOLR-11960
> URL: https://issues.apache.org/jira/browse/SOLR-11960
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Peter Rusko
>Assignee: Tomás Fernández Löbbe
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, 
> SOLR-11960.patch, SOLR-11960.patch
>
>
> Solr has cluster properties, but no easy and extendable way of defining 
> properties that affect a single collection. Collection properties could be 
> stored in a single zookeeper node per collection, making it possible to 
> trigger zookeeper watchers for only those Solr nodes that have cores of that 
> collection.



--
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-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-12083:
-

I have uploaded three patches with different designs:

1. add_support_for_random_ulog_in_tests.patch : This patch has nothing to do 
with the problem here but randomizing UpdateLog b/w 'UpdateLog' and 
'CdcrUpdateLog'. We don't need to do 'HdfsUpdateLog' as it gets picked up 
anyway when directoryFactory is HDFSDirectoryFactory.

2. SOLR-12083-B-wo-test-framework.patch : This patch fixes the problem by 
randomising the UpdateLog b/w 'UpdateLog' and 'CdcrUpdateLog' within the 
{{TestInPlaceUpdatesDistrib}} which validates the fix I have put in place.

3. SOLR-12083-A-within-test-framework.patch : This patch extends the 
'add_support_for_random_ulog_in_tests' with the fix in place.

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {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] [Assigned] (SOLR-11267) Add support for "add-distinct" atomic update operation

[David Smiley (JIRA)]

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

David Smiley reassigned SOLR-11267:
---

 Assignee: Noble Paul  (was: Ishan Chattopadhyaya)
 Priority: Blocker  (was: Major)
Fix Version/s: 7.3

Marking as blocker and assigning to [~noble.paul].  The CHANGES.txt entry is 
already in 7.3 even thought the code is not.  Is there any concern it's not 
ready to backport to 7.3?

> Add support for "add-distinct" atomic update operation
> --
>
> Key: SOLR-11267
> URL: https://issues.apache.org/jira/browse/SOLR-11267
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-11267.patch, SOLR-11267.patch, SOLR-11267.patch
>
>
> Often, a multivalued field is used as a set of values. Since multivalued 
> fields are more like lists than sets, users do two consecutive operations, 
> remove and add, to insert an element into the field and also maintain the 
> set's property of only having unique elements.
> Proposing a new single operation, called "add-distinct" (which essentially 
> means "add-if-doesn't exist") for this.



--
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-12081) Improve docs on query parsing: embedded queries, uf (edismax)

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-12081:
-
Attachment: 
SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch

> Improve docs on query parsing: embedded queries, uf (edismax)
> -
>
> Key: SOLR-12081
> URL: https://issues.apache.org/jira/browse/SOLR-12081
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch
>
>
> The {{uf}} parameter is a *space* separated list (not comma). Furthermore the 
> docs should be improved -- see 
> https://issues.apache.org/jira/browse/SOLR-11501?focusedCommentId=16326592=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16326592



--
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-12081) Improve docs on query parsing: embedded queries, uf (edismax)

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-12081:
--

I have dreams of completely redoing the entire query parsing section, but not 
today :)

I found one more example of {{\_query_}} that wasn't escaped. I also changed 
the layout of the {{uf}} params section - it seemed a big block of text, so I 
made all the new example goodness into a bulleted list. I attached a new patch 
that includes your changes + these little additions of mine.

Otherwise, +1 commit when you're ready. Thanks for working on this.



> Improve docs on query parsing: embedded queries, uf (edismax)
> -
>
> Key: SOLR-12081
> URL: https://issues.apache.org/jira/browse/SOLR-12081
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch, 
> SOLR-12081__improve_docs_on_query_parsing,_embedded_queries.patch
>
>
> The {{uf}} parameter is a *space* separated list (not comma). Furthermore the 
> docs should be improved -- see 
> https://issues.apache.org/jira/browse/SOLR-11501?focusedCommentId=16326592=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16326592



--
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-11960) Add collection level properties

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-11960:
--

[~dsmiley] I think both would be nice. For v1 APIs, the single property at a 
time format is simpler and more verbose. The multiple at a time is more 
"expert" (in V2 it doesn't matter). Also, for collection properties we should 
add support for adding properties at collection creation time. So, I'd suggest 
we keep the current format and add the bulk one for collection and cluster 
properties as a separate Jira. Could be something like:
{code}
=VALUE_2=VALUE_2...
{code}
The same parameters could work for {{action=CLUSTERPROP}} and for 
{{action=CREATE}}. 

Similarly, we could have
{code}
=VALUE_2=VALUE_2...
{code}
WDYT?

> Add collection level properties
> ---
>
> Key: SOLR-11960
> URL: https://issues.apache.org/jira/browse/SOLR-11960
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Peter Rusko
>Assignee: Tomás Fernández Löbbe
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, 
> SOLR-11960.patch, SOLR-11960.patch
>
>
> Solr has cluster properties, but no easy and extendable way of defining 
> properties that affect a single collection. Collection properties could be 
> stored in a single zookeeper node per collection, making it possible to 
> trigger zookeeper watchers for only those Solr nodes that have cores of that 
> collection.



--
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-8203) Windows failures when removing test directories

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-8203:
--

{quote}[~hossman] I see one at 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7218/testReport/junit/junit.framework/TestSuite/org_apache_lucene_store_TestMultiMMap/]
{noformat}
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_67336ADD32137F31-001\testSeekSliceZero-026:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_67336ADD32137F31-001\testSeekSliceZero-026
{noformat}
{quote}

Interesting -- that type of failure doesn't seem like it would fit the "Windows 
Search" hypothosis, so it might be a diff root cause?

(crazy idea: is it possible the "create a zero byte file" nature of that test 
is confusing the cleanup code into not realizing it needs deleted???)

> Windows failures when removing test directories
> ---
>
> Key: LUCENE-8203
> URL: https://issues.apache.org/jira/browse/LUCENE-8203
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: image-2018-03-13-19-15-51-149.png
>
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job 
> (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all 
> fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>[junit4]>  at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not 
> use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or 
> try-with-resources block or junit would report the exception that prevented 
> the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException 
> without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed 
> something.



--
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-8203) Windows failures when removing test directories

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-8203:
--

+1 ... that sounds like a promising culprit

searching my mail archives for " {{from:policeman subject:(jenkins windows) 
AccessDeniedException}} " and there was a clear ramp up in the number of 
failure _emails_ mentioning that exception around november...
 * Feb: ~100
 * Jan: ~130
 * Dec: ~112
 * Nov: ~60
 * Oct: ~22
 * Sep: ~18
 * Aug: ~12

> Windows failures when removing test directories
> ---
>
> Key: LUCENE-8203
> URL: https://issues.apache.org/jira/browse/LUCENE-8203
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: image-2018-03-13-19-15-51-149.png
>
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job 
> (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all 
> fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>[junit4]>  at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not 
> use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or 
> try-with-resources block or junit would report the exception that prevented 
> the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException 
> without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed 
> something.



--
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-11648) Create a web UI to display and execute suggestions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11648:


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

SOLR-11648: Add docs for autoscaling suggestions UI that didn't get done with 
the feature


> Create a web UI to display and execute suggestions
> --
>
> Key: SOLR-11648
> URL: https://issues.apache.org/jira/browse/SOLR-11648
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.3
>
> Attachments: no_suggestions.png, screen1.png, screen2.png, 
> screen3.png, screen4.png, sidebar.jpg, suggestions_table.jpg, 
> suggestions_table.jpg
>
>
> Steps to show suggestions
> {code}
> bin/solr start -e cloud
> #give the following inputs for prompts
> This interactive session will help you launch a SolrCloud cluster on your 
> local workstation.
> To begin, how many Solr nodes would you like to run in your local cluster? 
> (specify 1-4 nodes) [2]: 
> 4
> Please provide a name for your new collection: [gettingstarted] 
> mycoll
> How many shards would you like to split mycoll into? [2]
> 4
> How many replicas per shard would you like to create? [2] 
> 2
> #run the following command so that there are violating replicas
> curl http://localhost:8983/api/cluster/autoscaling -H 
> 'Content-type:application/json' -d '{
> "set-cluster-policy": [
>   {"replica": "0", "shard": "#EACH", "port": 7574}
>   ]
> }'
> #hit the suggestions end point at the url
> http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}
> add an entry to the sidebar as follows
> !sidebar.jpg!
> use the output of the suggestions API to map to the table data
> !suggestions_table.jpg!



--
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-8203) Windows failures when removing test directories

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8203:
--

[~hossman] I see one at 
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7218/testReport/junit/junit.framework/TestSuite/org_apache_lucene_store_TestMultiMMap/

{noformat}
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_67336ADD32137F31-001\testSeekSliceZero-026:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J0\temp\lucene.store.TestMultiMMap_67336ADD32137F31-001\testSeekSliceZero-026
{noformat}

bq. One change I did: I disabled now "Windows Search" on the Jenkins 
"workspace" folder.

Thanks Uwe! Let's see whether it makes things better!

> Windows failures when removing test directories
> ---
>
> Key: LUCENE-8203
> URL: https://issues.apache.org/jira/browse/LUCENE-8203
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: image-2018-03-13-19-15-51-149.png
>
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job 
> (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all 
> fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>[junit4]>  at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not 
> use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or 
> try-with-resources block or junit would report the exception that prevented 
> the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException 
> without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed 
> something.



--
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-11648) Create a web UI to display and execute suggestions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11648:


Commit f2b067cef462db9d79902fe1fc13d7eacb4a05b5 in lucene-solr's branch 
refs/heads/branch_7_3 from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f2b067c ]

SOLR-11648: Add docs for autoscaling suggestions UI that didn't get done with 
the feature


> Create a web UI to display and execute suggestions
> --
>
> Key: SOLR-11648
> URL: https://issues.apache.org/jira/browse/SOLR-11648
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.3
>
> Attachments: no_suggestions.png, screen1.png, screen2.png, 
> screen3.png, screen4.png, sidebar.jpg, suggestions_table.jpg, 
> suggestions_table.jpg
>
>
> Steps to show suggestions
> {code}
> bin/solr start -e cloud
> #give the following inputs for prompts
> This interactive session will help you launch a SolrCloud cluster on your 
> local workstation.
> To begin, how many Solr nodes would you like to run in your local cluster? 
> (specify 1-4 nodes) [2]: 
> 4
> Please provide a name for your new collection: [gettingstarted] 
> mycoll
> How many shards would you like to split mycoll into? [2]
> 4
> How many replicas per shard would you like to create? [2] 
> 2
> #run the following command so that there are violating replicas
> curl http://localhost:8983/api/cluster/autoscaling -H 
> 'Content-type:application/json' -d '{
> "set-cluster-policy": [
>   {"replica": "0", "shard": "#EACH", "port": 7574}
>   ]
> }'
> #hit the suggestions end point at the url
> http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}
> add an entry to the sidebar as follows
> !sidebar.jpg!
> use the output of the suggestions API to map to the table data
> !suggestions_table.jpg!



--
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-11648) Create a web UI to display and execute suggestions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11648:


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

SOLR-11648: Add docs for autoscaling suggestions UI that didn't get done with 
the feature


> Create a web UI to display and execute suggestions
> --
>
> Key: SOLR-11648
> URL: https://issues.apache.org/jira/browse/SOLR-11648
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.3
>
> Attachments: no_suggestions.png, screen1.png, screen2.png, 
> screen3.png, screen4.png, sidebar.jpg, suggestions_table.jpg, 
> suggestions_table.jpg
>
>
> Steps to show suggestions
> {code}
> bin/solr start -e cloud
> #give the following inputs for prompts
> This interactive session will help you launch a SolrCloud cluster on your 
> local workstation.
> To begin, how many Solr nodes would you like to run in your local cluster? 
> (specify 1-4 nodes) [2]: 
> 4
> Please provide a name for your new collection: [gettingstarted] 
> mycoll
> How many shards would you like to split mycoll into? [2]
> 4
> How many replicas per shard would you like to create? [2] 
> 2
> #run the following command so that there are violating replicas
> curl http://localhost:8983/api/cluster/autoscaling -H 
> 'Content-type:application/json' -d '{
> "set-cluster-policy": [
>   {"replica": "0", "shard": "#EACH", "port": 7574}
>   ]
> }'
> #hit the suggestions end point at the url
> http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}
> add an entry to the sidebar as follows
> !sidebar.jpg!
> use the output of the suggestions API to map to the table data
> !suggestions_table.jpg!



--
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-8203) Windows failures when removing test directories

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-8203:
-

Could be. I think I excluded my work folders from Windows search... but it was 
a long time ago and I don't even remember where the setting was!

> Windows failures when removing test directories
> ---
>
> Key: LUCENE-8203
> URL: https://issues.apache.org/jira/browse/LUCENE-8203
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: image-2018-03-13-19-15-51-149.png
>
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job 
> (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all 
> fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>[junit4]>  at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not 
> use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or 
> try-with-resources block or junit would report the exception that prevented 
> the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException 
> without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed 
> something.



--
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-6036) TestIndexWriterOnJRECrash suffers from JDK-8047340 - needs workarround

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-6036:
-

Strange... I don't even see the workflow button on this issue. I think I lost 
touch with Jira's changes. ;)

> TestIndexWriterOnJRECrash suffers from JDK-8047340 - needs workarround
> --
>
> Key: LUCENE-6036
> URL: https://issues.apache.org/jira/browse/LUCENE-6036
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 5.0, 6.0
>
> Attachments: LUCENE-6036.patch
>
>
> Similar to issues uncovered in SOLR-6387, TestIndexWriterOnJRECrash does some 
> forking which can hit JDK-8047340 on the turkish locale...
> {noformat}
>[junit4] Suite: org.apache.lucene.index.TestIndexWriterOnJRECrash
>[junit4]   2> NOTE: download the large Jenkins line-docs file by running 
> 'ant get-jenkins-line-docs' in the lucene directory.
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestIndexWriterOnJRECrash -Dtests.method=testNRTThreads 
> -Dtests.seed=B2D360EA192CA242 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=tr -Dtests.timezone=Africa/Monrovia -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   0.04s J0 | TestIndexWriterOnJRECrash.testNRTThreads <<<
>[junit4]> Throwable #1: java.lang.Error: posix_spawn is not a 
> supported process launch mechanism on this platform.
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B2D360EA192CA242:290A74F158D7B429]:0)
>[junit4]>  at java.lang.UNIXProcess$1.run(UNIXProcess.java:111)
>[junit4]>  at java.lang.UNIXProcess$1.run(UNIXProcess.java:93)
>[junit4]>  at java.security.AccessController.doPrivileged(Native 
> Method)
>[junit4]>  at java.lang.UNIXProcess.(UNIXProcess.java:91)
>[junit4]>  at java.lang.ProcessImpl.start(ProcessImpl.java:130)
>[junit4]>  at 
> java.lang.ProcessBuilder.start(ProcessBuilder.java:1028)
>[junit4]>  at 
> org.apache.lucene.index.TestIndexWriterOnJRECrash.forkTest(TestIndexWriterOnJRECrash.java:113)
>[junit4]>  at 
> org.apache.lucene.index.TestIndexWriterOnJRECrash.testNRTThreads(TestIndexWriterOnJRECrash.java:59)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {noformat}
> https://bugs.openjdk.java.net/browse/JDK-8047340



--
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-8203) Windows failures when removing test directories

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-8203:
---

[~dweiss]: The bad guy might be the Windows Search. After the upgrade to 
Windows 10 build 1709 at end of last year it enabled itsself again (how stupid, 
those automatic Windows Services that reconfdigure themselves all the time are 
a pain). So maybe that was the issue here.

> Windows failures when removing test directories
> ---
>
> Key: LUCENE-8203
> URL: https://issues.apache.org/jira/browse/LUCENE-8203
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: image-2018-03-13-19-15-51-149.png
>
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job 
> (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all 
> fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>[junit4]>  at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not 
> use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or 
> try-with-resources block or junit would report the exception that prevented 
> the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException 
> without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed 
> something.



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

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

[jira] [Comment Edited] (LUCENE-8203) Windows failures when removing test directories

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-8203 at 3/13/18 6:22 PM:


Defender is completely disabled:

!image-2018-03-13-19-15-51-149.png!


was (Author: thetaphi):
Defender is completely disabled. And Windows Search, too:

!image-2018-03-13-19-15-51-149.png!

> Windows failures when removing test directories
> ---
>
> Key: LUCENE-8203
> URL: https://issues.apache.org/jira/browse/LUCENE-8203
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: image-2018-03-13-19-15-51-149.png
>
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job 
> (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all 
> fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>[junit4]>  at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not 
> use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or 
> try-with-resources block or junit would report the exception that prevented 
> the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException 
> without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed 
> something.



--
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] [Issue Comment Deleted] (LUCENE-8203) Windows failures when removing test directories

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-8203:
--
Comment: was deleted

(was: One change I did: I disabled now "Windows Search" on the Jenkins 
"workspace" folder.)

> Windows failures when removing test directories
> ---
>
> Key: LUCENE-8203
> URL: https://issues.apache.org/jira/browse/LUCENE-8203
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: image-2018-03-13-19-15-51-149.png
>
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job 
> (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all 
> fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>[junit4]>  at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not 
> use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or 
> try-with-resources block or junit would report the exception that prevented 
> the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException 
> without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed 
> something.



--
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-8203) Windows failures when removing test directories

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-8203:
--

bq. It's also surprising how it sometimes fails with a 
DirectoryNotEmptyException without reporting issues about deleting inner files 
of the directory.

Do you have an example of that?

In the example you posted, the DirNotEmpty comes from 
{{lucene.search.TestBoolean2_B7B1F66EB9785AE1-001}} after saying it already had 
an AccessDeniedException trying to delete 
{{lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001}} -- so the "Not 
Empty" makes sense.

I've seen this pattern a lot, but I can't remember ever seeing 
DirectoryNotEmptyException w/o already reporting a problem w/some other file in 
that directory.

> Windows failures when removing test directories
> ---
>
> Key: LUCENE-8203
> URL: https://issues.apache.org/jira/browse/LUCENE-8203
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: image-2018-03-13-19-15-51-149.png
>
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job 
> (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all 
> fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>[junit4]>  at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not 
> use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or 
> try-with-resources block or junit would report the exception that prevented 
> the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException 
> without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed 
> something.



--
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-8203) Windows failures when removing test directories

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-8203:
---

One change I did: I disabled now "Windows Search" on the Jenkins "workspace" 
folder.

> Windows failures when removing test directories
> ---
>
> Key: LUCENE-8203
> URL: https://issues.apache.org/jira/browse/LUCENE-8203
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: image-2018-03-13-19-15-51-149.png
>
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job 
> (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all 
> fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>[junit4]>  at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not 
> use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or 
> try-with-resources block or junit would report the exception that prevented 
> the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException 
> without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed 
> something.



--
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-8203) Windows failures when removing test directories

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-8203:
---

One change I did: I disabled now "Windows Search" on the Jenkins "workspace" 
folder.

> Windows failures when removing test directories
> ---
>
> Key: LUCENE-8203
> URL: https://issues.apache.org/jira/browse/LUCENE-8203
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: image-2018-03-13-19-15-51-149.png
>
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job 
> (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all 
> fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>[junit4]>  at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not 
> use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or 
> try-with-resources block or junit would report the exception that prevented 
> the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException 
> without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed 
> something.



--
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-8203) Windows failures when removing test directories

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-8203:
--
Attachment: image-2018-03-13-19-15-51-149.png

> Windows failures when removing test directories
> ---
>
> Key: LUCENE-8203
> URL: https://issues.apache.org/jira/browse/LUCENE-8203
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: image-2018-03-13-19-15-51-149.png
>
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job 
> (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all 
> fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>[junit4]>  at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not 
> use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or 
> try-with-resources block or junit would report the exception that prevented 
> the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException 
> without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed 
> something.



--
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-8203) Windows failures when removing test directories

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-8203:
---

Defender is completely disabled. And Windows Search, too:

!image-2018-03-13-19-15-51-149.png!

> Windows failures when removing test directories
> ---
>
> Key: LUCENE-8203
> URL: https://issues.apache.org/jira/browse/LUCENE-8203
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: image-2018-03-13-19-15-51-149.png
>
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job 
> (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all 
> fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>[junit4]>  at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not 
> use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or 
> try-with-resources block or junit would report the exception that prevented 
> the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException 
> without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed 
> something.



--
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-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: (was: add_support_for_random_ulog_in_tests.patch)

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {code}



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

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

[jira] [Updated] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: (was: SOLR-12083-A-within-test-framework.patch)

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {code}



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

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

[jira] [Updated] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: SOLR-12083-A-within-test-framework.patch
add_support_for_random_ulog_in_tests.patch

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {code}



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

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

[jira] [Updated] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: (was: add_support_for_random_ulog_in_tests.patch)

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {code}



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

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

[jira] [Updated] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: SOLR-12083-A-within-test-framework.patch
add_support_for_random_ulog_in_tests.patch

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {code}



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

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

[jira] [Updated] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: (was: SOLR-12083-A-within-test-framework.patch)

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {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] [Resolved] (SOLR-12082) Improve docs on query parsing: embedded queries, uf (edismax)

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-12082.
--
Resolution: Duplicate

I think this is an inadvertent duplicate of SOLR-12081? Resolving as such, 
please reopen if I got that wrong.

> Improve docs on query parsing: embedded queries, uf (edismax)
> -
>
> Key: SOLR-12082
> URL: https://issues.apache.org/jira/browse/SOLR-12082
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
>
> The {{uf}} parameter is a *space* separated list (not comma). Furthermore the 
> docs should be improved -- see 
> https://issues.apache.org/jira/browse/SOLR-11501?focusedCommentId=16326592=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16326592



--
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-6036) TestIndexWriterOnJRECrash suffers from JDK-8047340 - needs workarround

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-6036:
--

i think that's a quirk of the workflow? after re-opening?  not sure if there is 
a way to remove the "resolution" once it's set, even though it's been re-opened.

> TestIndexWriterOnJRECrash suffers from JDK-8047340 - needs workarround
> --
>
> Key: LUCENE-6036
> URL: https://issues.apache.org/jira/browse/LUCENE-6036
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 5.0, 6.0
>
> Attachments: LUCENE-6036.patch
>
>
> Similar to issues uncovered in SOLR-6387, TestIndexWriterOnJRECrash does some 
> forking which can hit JDK-8047340 on the turkish locale...
> {noformat}
>[junit4] Suite: org.apache.lucene.index.TestIndexWriterOnJRECrash
>[junit4]   2> NOTE: download the large Jenkins line-docs file by running 
> 'ant get-jenkins-line-docs' in the lucene directory.
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestIndexWriterOnJRECrash -Dtests.method=testNRTThreads 
> -Dtests.seed=B2D360EA192CA242 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=tr -Dtests.timezone=Africa/Monrovia -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   0.04s J0 | TestIndexWriterOnJRECrash.testNRTThreads <<<
>[junit4]> Throwable #1: java.lang.Error: posix_spawn is not a 
> supported process launch mechanism on this platform.
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B2D360EA192CA242:290A74F158D7B429]:0)
>[junit4]>  at java.lang.UNIXProcess$1.run(UNIXProcess.java:111)
>[junit4]>  at java.lang.UNIXProcess$1.run(UNIXProcess.java:93)
>[junit4]>  at java.security.AccessController.doPrivileged(Native 
> Method)
>[junit4]>  at java.lang.UNIXProcess.(UNIXProcess.java:91)
>[junit4]>  at java.lang.ProcessImpl.start(ProcessImpl.java:130)
>[junit4]>  at 
> java.lang.ProcessBuilder.start(ProcessBuilder.java:1028)
>[junit4]>  at 
> org.apache.lucene.index.TestIndexWriterOnJRECrash.forkTest(TestIndexWriterOnJRECrash.java:113)
>[junit4]>  at 
> org.apache.lucene.index.TestIndexWriterOnJRECrash.testNRTThreads(TestIndexWriterOnJRECrash.java:59)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {noformat}
> https://bugs.openjdk.java.net/browse/JDK-8047340



--
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-8200) Allow doc-values to be updated atomically together with a document

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-8200:
--

That was it; thanks. IntelliJ likes this one, and so does {{git apply ...}}

>  Allow doc-values to be updated atomically together with a document
> ---
>
> Key: LUCENE-8200
> URL: https://issues.apache.org/jira/browse/LUCENE-8200
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
>Priority: Major
> Attachments: LUCENE-8200.patch, LUCENE-8200.patch, LUCENE-8200.patch
>
>
> Today we can only update a document by deleting all previously indexed 
> documents for the given term. In some cases like when deletes are not `final` 
> in the way that documents that are marked as deleted should not be merged 
> away a `soft-delete` is needed which is possible when doc-values updates can 
> be done atomically just like delete and add in updateDocument(s)
> 
> This change introduces such a soft update that reuses all code paths from 
> deletes to update all previously updated documents for a given term instead 
> of marking it as deleted. This is a spinnoff from LUCENE-8198



--
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-8200) Allow doc-values to be updated atomically together with a document

[Simon Willnauer (JIRA)]

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

Simon Willnauer commented on LUCENE-8200:
-

[~dsmiley] I updated the patch and uploaded it. I think the previous patch had 
2 commits in it. Sorry for the confusion. I applied it with _patch -p1 < 
../LUCENE-8200.patch_ just fine

>  Allow doc-values to be updated atomically together with a document
> ---
>
> Key: LUCENE-8200
> URL: https://issues.apache.org/jira/browse/LUCENE-8200
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
>Priority: Major
> Attachments: LUCENE-8200.patch, LUCENE-8200.patch, LUCENE-8200.patch
>
>
> Today we can only update a document by deleting all previously indexed 
> documents for the given term. In some cases like when deletes are not `final` 
> in the way that documents that are marked as deleted should not be merged 
> away a `soft-delete` is needed which is possible when doc-values updates can 
> be done atomically just like delete and add in updateDocument(s)
> 
> This change introduces such a soft update that reuses all code paths from 
> deletes to update all previously updated documents for a given term instead 
> of marking it as deleted. This is a spinnoff from LUCENE-8198



--
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-8200) Allow doc-values to be updated atomically together with a document

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-8200:
--

{quote}my repo is aligned with whatever is on 
_[https://git-wip-us.apache.org/repos/asf/lucene-solr.git_] it has not been 
forked from a specific mirror on github which doesn't matter at all here. I 
don't really understand why you bring this up like a second time here. it's 
unrelated.
{quote}
1st time was just an unrelated question; sorry if asking it annoyed you.
2nd time is perhaps in retrospect misattributed.  I thought that your repo 
shared no lineage with ASF's but now I think I'm mistaken.  If it didn't share 
lineage (which was my thinking at the time I commented), it would explain why 
"git apply ..." didn't work.  But it's not that.  It didn't work when I tried 
to apply it in IntelliJ either.  A mystery; ah well.  Does "git apply ..." work 
for anyone else here for this patch?  My usual method is to apply patches 
directly in IntelliJ but when that failed I went to the CLI and found it failed 
there too, so I'm stumped.  Raw patches are harder to review as thoroughly as 
one can in an IDE (of course).

>  Allow doc-values to be updated atomically together with a document
> ---
>
> Key: LUCENE-8200
> URL: https://issues.apache.org/jira/browse/LUCENE-8200
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
>Priority: Major
> Attachments: LUCENE-8200.patch, LUCENE-8200.patch, LUCENE-8200.patch
>
>
> Today we can only update a document by deleting all previously indexed 
> documents for the given term. In some cases like when deletes are not `final` 
> in the way that documents that are marked as deleted should not be merged 
> away a `soft-delete` is needed which is possible when doc-values updates can 
> be done atomically just like delete and add in updateDocument(s)
> 
> This change introduces such a soft update that reuses all code paths from 
> deletes to update all previously updated documents for a given term instead 
> of marking it as deleted. This is a spinnoff from LUCENE-8198



--
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-8200) Allow doc-values to be updated atomically together with a document

[Simon Willnauer (JIRA)]

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

Simon Willnauer updated LUCENE-8200:

Attachment: LUCENE-8200.patch

>  Allow doc-values to be updated atomically together with a document
> ---
>
> Key: LUCENE-8200
> URL: https://issues.apache.org/jira/browse/LUCENE-8200
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
>Priority: Major
> Attachments: LUCENE-8200.patch, LUCENE-8200.patch, LUCENE-8200.patch
>
>
> Today we can only update a document by deleting all previously indexed 
> documents for the given term. In some cases like when deletes are not `final` 
> in the way that documents that are marked as deleted should not be merged 
> away a `soft-delete` is needed which is possible when doc-values updates can 
> be done atomically just like delete and add in updateDocument(s)
> 
> This change introduces such a soft update that reuses all code paths from 
> deletes to update all previously updated documents for a given term instead 
> of marking it as deleted. This is a spinnoff from LUCENE-8198



--
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-12086) Format Problem on Cache Statistics Page

[Sathiya N (JIRA)]

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

Sathiya N updated SOLR-12086:
-
Description: 
Noticed minor formatting issue on Cache Stats page in `Solr 7.2.1`

 

should be `ramMaxSize{color:#ff}={color}536870912`

right now its `ramMaxSize536870912`

  was:
Noticed minor formatting issue on Cache Stats page in `Solr 7.2.1`

 

should be `ramMaxSize*{color:#FF}={color}*536870912`

right now its `ramMaxSize536870912`


> Format Problem on Cache Statistics Page
> ---
>
> Key: SOLR-12086
> URL: https://issues.apache.org/jira/browse/SOLR-12086
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.2
>Reporter: Sathiya N
>Priority: Minor
> Attachments: Screen Shot 2018-03-13 at 9.21.50 AM.png
>
>
> Noticed minor formatting issue on Cache Stats page in `Solr 7.2.1`
>  
> should be `ramMaxSize{color:#ff}={color}536870912`
> right now its `ramMaxSize536870912`



--
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-12086) Format Problem on Cache Statistics Page

[Sathiya N (JIRA)]

Sathiya N created SOLR-12086:


 Summary: Format Problem on Cache Statistics Page
 Key: SOLR-12086
 URL: https://issues.apache.org/jira/browse/SOLR-12086
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Admin UI
Affects Versions: 7.2
Reporter: Sathiya N
 Attachments: Screen Shot 2018-03-13 at 9.21.50 AM.png

Noticed minor formatting issue on Cache Stats page in `Solr 7.2.1`

 

should be `ramMaxSize*{color:#FF}={color}*536870912`

right now its `ramMaxSize536870912`



--
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-8200) Allow doc-values to be updated atomically together with a document

[Simon Willnauer (JIRA)]

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

Simon Willnauer commented on LUCENE-8200:
-

> The patch did not apply for me git apply ../patches/LUCENE-8200.patch ... 
> probably because your GH repository does not have the same git lineage as the 
> official ASF repo that is mirrored/forked elsewhere.
ok sure.

> I suggest the javadocs more explicitly give the user an idea of what this 
> might be used for, since it seems a bit abstract as-is. For example:
I can do that.

> The patch did not apply for me git apply ../patches/LUCENE-8200.patch ... 
> probably because your GH repository does not have the same git lineage as the 
> official ASF repo that is mirrored/forked elsewhere.

my repo is aligned with whatever is on  
_https://git-wip-us.apache.org/repos/asf/lucene-solr.git_ it has not been 
forked from a specific mirror on github which doesn't matter at all here. I 
don't really understand why you bring this up like a second time here. it's 
unrelated. 


>  Allow doc-values to be updated atomically together with a document
> ---
>
> Key: LUCENE-8200
> URL: https://issues.apache.org/jira/browse/LUCENE-8200
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
>Priority: Major
> Attachments: LUCENE-8200.patch, LUCENE-8200.patch
>
>
> Today we can only update a document by deleting all previously indexed 
> documents for the given term. In some cases like when deletes are not `final` 
> in the way that documents that are marked as deleted should not be merged 
> away a `soft-delete` is needed which is possible when doc-values updates can 
> be done atomically just like delete and add in updateDocument(s)
> 
> This change introduces such a soft update that reuses all code paths from 
> deletes to update all previously updated documents for a given term instead 
> of marking it as deleted. This is a spinnoff from LUCENE-8198



--
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-8200) Allow doc-values to be updated atomically together with a document

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-8200:
--

Cool feature!  I like the name "softUpdateDocuments" for this.  Maybe the 
CHANGES.txt entry should make reference to the particular method so user's can 
easily get to further explanatory javadocs.

I suggest the javadocs more explicitly give the user an idea of what this might 
be used for, since it seems a bit abstract as-is.  For example:
bq. One use of this API is to retain older versions of documents instead of 
replacing them. The existing documents can be updated to reflect they are no 
longer current while atomically adding new documents at the same time.

The patch did not apply for me {{git apply ../patches/LUCENE-8200.patch}} ... 
probably because your GH repository does not have the same git lineage as the 
official ASF repo that is mirrored/forked elsewhere.

>  Allow doc-values to be updated atomically together with a document
> ---
>
> Key: LUCENE-8200
> URL: https://issues.apache.org/jira/browse/LUCENE-8200
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
>Priority: Major
> Attachments: LUCENE-8200.patch, LUCENE-8200.patch
>
>
> Today we can only update a document by deleting all previously indexed 
> documents for the given term. In some cases like when deletes are not `final` 
> in the way that documents that are marked as deleted should not be merged 
> away a `soft-delete` is needed which is possible when doc-values updates can 
> be done atomically just like delete and add in updateDocument(s)
> 
> This change introduces such a soft update that reuses all code paths from 
> deletes to update all previously updated documents for a given term instead 
> of marking it as deleted. This is a spinnoff from LUCENE-8198



--
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-8203) Windows failures when removing test directories

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-8203:
-

It looks strange. I don't see those exceptions at all (and I just ran a full 
suite before I committed a change, recently). But then -- I do have an explicit 
exclusion on Windows Defender to *not* scan my work folder. Perhaps Uwe needs 
to do it as well?

> Windows failures when removing test directories
> ---
>
> Key: LUCENE-8203
> URL: https://issues.apache.org/jira/browse/LUCENE-8203
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Adrien Grand
>Priority: Minor
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job 
> (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all 
> fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>[junit4]>  at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not 
> use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or 
> try-with-resources block or junit would report the exception that prevented 
> the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException 
> without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed 
> something.



--
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-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: SOLR-12083-A-within-test-framework.patch

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-A-within-test-framework.patch, 
> SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {code}



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

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

[jira] [Updated] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: SOLR-12083-B-wo-test-framework.patch

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, 
> SOLR-12083.patch, add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {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] [Resolved] (SOLR-12058) Ref Guide: Upgrade notes for 7.3

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-12058.
--
Resolution: Fixed

> Ref Guide: Upgrade notes for 7.3
> 
>
> Key: SOLR-12058
> URL: https://issues.apache.org/jira/browse/SOLR-12058
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
> Fix For: 7.3
>
>
> This issue is to add upgrade notes for 7.3 to the Ref Guide.



--
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-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12083:

Attachment: add_support_for_random_ulog_in_tests.patch

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> 
>
> Key: SOLR-12083
> URL: https://issues.apache.org/jira/browse/SOLR-12083
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2, 7.2.1, 7.3
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12083.patch, SOLR-12083.patch, 
> add_support_for_random_ulog_in_tests.patch
>
>
> On the lines of SOLR-12063: Bidirectional support introduced serious bugs and 
> here RealTimeGetComponent is broken. 
> As we have added additional flag to each {{tlog}} entry, the following 
> assertions fail when Cdcr enabled:
> {code}
> if (oper == UpdateLog.UPDATE_INPLACE) {
>  assert entry.size() == 5;
> }
> {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] [Created] (SOLR-12085) IndexFetcher does not honor SolrDeletionPolicy

[Karishma Agrawal (JIRA)]

Karishma Agrawal created SOLR-12085:
---

 Summary: IndexFetcher does not honor SolrDeletionPolicy
 Key: SOLR-12085
 URL: https://issues.apache.org/jira/browse/SOLR-12085
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: replication (java)
Affects Versions: 5.4.1
Reporter: Karishma Agrawal


Index Fetcher is not in sync with Solr Deletion Policy.

If we set the SolrDeletionPolicy to retain more than 1 commit - i.e. 
maxCommitsToKeep > 1. Then slaves get stuck in alternate full replication. This 
happens because within IndexFetcher, there is a check for unusedFiles - 
hasUnusedFile, which takes IndexDirectory and latest commit as parameters. If 
there are files unrelated to latest commit in the index dir then this method 
returns true, and SolrDeletionPolicy is invoked. However there are no pending 
files to delete according to the index deletion policy since that is aware of 
other valid commits, and no action is taken. Once all the retries are 
exhausted, index fetcher sets fullreplication to true.  

Possible solutions: 
 # remove the check for hasUnusedFile completely. We invoke 
IndexWriter#deleteUnusedFiles and move on.
 # Add another method in IndexFileDeleter (Lucene) which returns number of 
pending deleted files. We can replace the IndexFetcher#hasUnusedFile method 
with this.
 # Keep track of unused files in IndexDeletionPolicyWrapper.     

A variation of this bug was previously noted in 
https://issues.apache.org/jira/browse/SOLR-9278    



--
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-12084) ShingleFilter cause threads consume all available memory

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-12084.
---
Resolution: Invalid

Please raise this question on the user's list at solr-u...@lucene.apache.org, 
see: (http://lucene.apache.org/solr/community.html#mailing-lists-irc) there are 
a _lot_ more people watching that list who may be able to help. 

If it's determined that this really is a code issue in Solr and not a 
configuration/usage problem, we can raise a new JIRA or reopen this one.


> ShingleFilter cause threads consume all available memory
> 
>
> Key: SOLR-12084
> URL: https://issues.apache.org/jira/browse/SOLR-12084
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 6.5, 6.5.1, 7.0.1
>Reporter: Tanapol Nearunchorn
>Priority: Major
>
> When putting ShingleFilter on query analyzer and after some specific query 
> patterns go through Solr, it causes all of handlers thread to hold a large 
> amount of SpanNearQuery objects and consume all available memory.
> My query analyzer looks like this:
> {code:java}
> 
> 
> 
>  />
> 
>  maxShingleSize="3" />
> {code}
> After I tested with queries, it seems that the number of terms passing to 
> ShingleFilter directly effect Solr memory usage. If ShingleFilter got 10-15 
> terms as input, it takes much memory to process the request, so multiply with 
> concurrent make problem goes worse.
> Not sure how to handle this problem, maybe we can put an upper limit number 
> of terms produced by ShingleFilter or should we optimize something?
> Thank you.



--
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-12058) Ref Guide: Upgrade notes for 7.3

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12058:


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

SOLR-12058: Add 7.3 Upgrade Notes to Ref Guide; clarify LIR changes for CHANGES 
Upgrade Notes


> Ref Guide: Upgrade notes for 7.3
> 
>
> Key: SOLR-12058
> URL: https://issues.apache.org/jira/browse/SOLR-12058
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
> Fix For: 7.3
>
>
> This issue is to add upgrade notes for 7.3 to the Ref Guide.



--
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-12058) Ref Guide: Upgrade notes for 7.3

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12058:


Commit 00635fd648ff457de6a81a150172cd841ae17beb in lucene-solr's branch 
refs/heads/branch_7_3 from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=00635fd ]

SOLR-12058: Add 7.3 Upgrade Notes to Ref Guide; clarify LIR changes for CHANGES 
Upgrade Notes


> Ref Guide: Upgrade notes for 7.3
> 
>
> Key: SOLR-12058
> URL: https://issues.apache.org/jira/browse/SOLR-12058
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
> Fix For: 7.3
>
>
> This issue is to add upgrade notes for 7.3 to the Ref Guide.



--
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-12058) Ref Guide: Upgrade notes for 7.3

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12058:


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

SOLR-12058: Add 7.3 Upgrade Notes to Ref Guide; clarify LIR changes for CHANGES 
Upgrade Notes


> Ref Guide: Upgrade notes for 7.3
> 
>
> Key: SOLR-12058
> URL: https://issues.apache.org/jira/browse/SOLR-12058
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
> Fix For: 7.3
>
>
> This issue is to add upgrade notes for 7.3 to the Ref Guide.



--
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-8203) Windows failures when removing test directories

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8203:
--

Thanks [~dweiss]. [~thetaphi] do you know of external processes that might 
access files while jobs are running?

bq. and I'm running tests on Windows 10 myself

Out of curiosity, do you see such failures on your machine as well or would you 
say it looks specific 

> Windows failures when removing test directories
> ---
>
> Key: LUCENE-8203
> URL: https://issues.apache.org/jira/browse/LUCENE-8203
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Adrien Grand
>Priority: Minor
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job 
> (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all 
> fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>[junit4]>  at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not 
> use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or 
> try-with-resources block or junit would report the exception that prevented 
> the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException 
> without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed 
> something.



--
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-11670) Implement a periodic house-keeping task

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-11670:
--

bq. it's confusing that TimeSource.getTime & getEpochTime return nanoseconds
{{System.nanoTime}} returns time in ns, too ... but I see your point, we can 
rename these two methods to {{getTimeNs}} and {{getEpochTimeNs}}.

> Implement a periodic house-keeping task
> ---
>
> Key: SOLR-11670
> URL: https://issues.apache.org/jira/browse/SOLR-11670
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-11670.patch, SOLR-11670.patch, SOLR-11670.patch
>
>
> Some high-impact cluster changes (such as split shard) leave the original 
> data and original state that is no longer actively used. This makes sense due 
> to safety reasons and to make it easier to roll-back the changes.
> However, this unused data will accumulate over time, especially when actions 
> like split shard are invoked automatically by the autoscaling framework. We 
> need a periodic task that would clean up this kind of data after a certain 
> period.



--
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-11670) Implement a periodic house-keeping task

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11670:
-

[~ab] I think it's confusing that TimeSource.getTime & getEpochTime return 
nanoseconds.  I think the methods should be renamed so that it's clear what 
unit it is, otherwise the conditions are ripe for continuing bugs in unit 
conversions.  Perhaps rename getTime to {{getTimeNs}}.

> Implement a periodic house-keeping task
> ---
>
> Key: SOLR-11670
> URL: https://issues.apache.org/jira/browse/SOLR-11670
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-11670.patch, SOLR-11670.patch, SOLR-11670.patch
>
>
> Some high-impact cluster changes (such as split shard) leave the original 
> data and original state that is no longer actively used. This makes sense due 
> to safety reasons and to make it easier to roll-back the changes.
> However, this unused data will accumulate over time, especially when actions 
> like split shard are invoked automatically by the autoscaling framework. We 
> need a periodic task that would clean up this kind of data after a certain 
> period.



--
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-12070) TestJMXIntegration.testJMXOnCoreReload always fails

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12070:


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

SOLR-12070: Make sure searcher beans are registered.


> TestJMXIntegration.testJMXOnCoreReload always fails
> ---
>
> Key: SOLR-12070
> URL: https://issues.apache.org/jira/browse/SOLR-12070
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3, master (8.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Blocker
>
> This test is marked @BadApple but the issue it refers to probably doesn't 
> apply anymore since the JMX integration has been substantially changed as a 
> part of the metrics refactoring.



--
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-12070) TestJMXIntegration.testJMXOnCoreReload always fails

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12070:


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

SOLR-12070: Make sure searcher beans are registered.


> TestJMXIntegration.testJMXOnCoreReload always fails
> ---
>
> Key: SOLR-12070
> URL: https://issues.apache.org/jira/browse/SOLR-12070
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3, master (8.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Blocker
>
> This test is marked @BadApple but the issue it refers to probably doesn't 
> apply anymore since the JMX integration has been substantially changed as a 
> part of the metrics refactoring.



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