[jira] [Updated] (SOLR-8748) OverseerTaskProcessor limits number of concurrent tasks to just 10 even though the thread pool size is 100

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-8748:

Attachment: SOLR-8748.patch

# Renamed maxParallelThreads to a static constant MAX_PARALLEL_TASKS
# Increased value of constant to 100 from 10.

> OverseerTaskProcessor limits number of concurrent tasks to just 10 even 
> though the thread pool size is 100
> --
>
> Key: SOLR-8748
> URL: https://issues.apache.org/jira/browse/SOLR-8748
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.10.4, 5.5
>Reporter: Shalin Shekhar Mangar
> Fix For: master, 6.0
>
> Attachments: SOLR-8748.patch
>
>
> OverseerTaskProcessor uses maxParallelThreads to limit number of concurrent 
> tasks but the same is not used for creating the thread pool. The default 
> limit of 10 is too small, IMO and we should change it to 100. The overseer 
> collection processor mostly just waits around on network calls so there is no 
> harm in increasing this limit.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8731) onException behavior in search components

[Dean Gurvitz (JIRA)]

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

Dean Gurvitz updated SOLR-8731:
---
Fix Version/s: master

> onException behavior in search components
> -
>
> Key: SOLR-8731
> URL: https://issues.apache.org/jira/browse/SOLR-8731
> Project: Solr
>  Issue Type: New Feature
>  Components: SearchComponents - other
>Affects Versions: master
>Reporter: Dean Gurvitz
>Priority: Minor
>  Labels: features, newdev
> Fix For: master
>
> Attachments: SOLR-8731.patch
>
>
> The idea is to allow search components to execute logic in case an exception  
> was thrown while processing a query.
> A new "onException" function can be added to the SearchComponent class. Then, 
> parts of SearchHandler's handle-request functions can be surrounded in a 
> try-catch block, where onException is called within the catch section on all 
> relevant SearchComponents.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-8746) Document the usage and difference between various overseer queues, rename methods if necessary

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-8746.
-
Resolution: Fixed
  Assignee: Shalin Shekhar Mangar

> Document the usage and difference between various overseer queues, rename 
> methods if necessary
> --
>
> Key: SOLR-8746
> URL: https://issues.apache.org/jira/browse/SOLR-8746
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master, 6.0
>
> Attachments: SOLR-8746.patch
>
>
> The various overseer queues can use better javadocs to document their purpose 
> and usage. The method names such as getInQueue, getInternalQueue and 
> getCollectionQueue aren't descriptive enough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_72) - Build # 16020 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16020/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 36079 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
API invocations (in 1.07s), 1 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:740: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:347: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:504: 
Check for forbidden API calls failed, see log.

Total time: 63 minutes 49 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Commented] (SOLR-8746) Document the usage and difference between various overseer queues, rename methods if necessary

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8746:
---

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

SOLR-8746: Renamed Overseer.getInQueue to getStateUpdateQueue, getInternalQueue 
to getInternalWorkQueue and added javadocs


> Document the usage and difference between various overseer queues, rename 
> methods if necessary
> --
>
> Key: SOLR-8746
> URL: https://issues.apache.org/jira/browse/SOLR-8746
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: master, 6.0
>
> Attachments: SOLR-8746.patch
>
>
> The various overseer queues can use better javadocs to document their purpose 
> and usage. The method names such as getInQueue, getInternalQueue and 
> getCollectionQueue aren't descriptive enough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8746) Document the usage and difference between various overseer queues, rename methods if necessary

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-8746:

Attachment: SOLR-8746.patch

# Renamed Overseer.getInQueue to getStateUpdateQueue
# Renamed Overseer.getInternalQueue to getInternalWorkQueue
# Added javadocs for getStateUpdateQueue, getInternalWorkQueue, 
getCollectionQueue

> Document the usage and difference between various overseer queues, rename 
> methods if necessary
> --
>
> Key: SOLR-8746
> URL: https://issues.apache.org/jira/browse/SOLR-8746
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: master, 6.0
>
> Attachments: SOLR-8746.patch
>
>
> The various overseer queues can use better javadocs to document their purpose 
> and usage. The method names such as getInQueue, getInternalQueue and 
> getCollectionQueue aren't descriptive enough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-8752) Add a test for SizeLimitedDistributedMap

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-8752.
-
Resolution: Fixed

> Add a test for SizeLimitedDistributedMap
> 
>
> Key: SOLR-8752
> URL: https://issues.apache.org/jira/browse/SOLR-8752
> Project: Solr
>  Issue Type: Test
>  Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master, 6.0
>
> Attachments: SOLR-8752.patch
>
>
> This class performs cleanup logic on a put operation. We should add a test 
> for it and beef up javadocs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: lucene-solr git commit: SOLR-8697: Add synchronization around registering as leader and canceling.

[Shalin Shekhar Mangar]

I pushed a fix.

On Sat, Feb 27, 2016 at 9:25 AM, Scott Blum  wrote:
> That's annoying, since there's no semantic difference between that and a
> log.warn(fmt, arg, arg).  Except that this particular logging API doesn't
> have an overload that takes a throwable, a format string, and a set of args.
>
> On Fri, Feb 26, 2016 at 8:02 PM, Chris Hostetter 
> wrote:
>>
>>
>> this breaks precommit...
>>
>>
>> [forbidden-apis] Forbidden method invocation:
>> java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default
>> locale]
>> [forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController
>> (OverseerTest.java:128)
>> [forbidden-apis] Scanned 3181 (and 1946 related) class file(s) for
>> forbidden API invocations (in 1.27s), 1 error(s).
>>
>>
>>
>>
>> : Date: Fri, 26 Feb 2016 17:32:25 + (UTC)
>> : From: markrmil...@apache.org
>> : Reply-To: dev@lucene.apache.org
>> : To: comm...@lucene.apache.org
>> : Subject: lucene-solr git commit: SOLR-8697: Add synchronization around
>> : registering as leader and canceling.
>> :
>> : Repository: lucene-solr
>> : Updated Branches:
>> :   refs/heads/master 0ed625b10 -> efb7bb171
>> :
>> :
>> : SOLR-8697: Add synchronization around registering as leader and
>> canceling.
>> :
>> :
>> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>> : Commit:
>> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/efb7bb17
>> : Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/efb7bb17
>> : Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/efb7bb17
>> :
>> : Branch: refs/heads/master
>> : Commit: efb7bb171b22a3c6a00d30eefe935a0024df0c71
>> : Parents: 0ed625b
>> : Author: markrmiller 
>> : Authored: Fri Feb 26 12:32:12 2016 -0500
>> : Committer: markrmiller 
>> : Committed: Fri Feb 26 12:32:12 2016 -0500
>> :
>> : --
>> :  .../org/apache/solr/cloud/ElectionContext.java  | 110
>> ++-
>> :  .../org/apache/solr/cloud/ZkController.java |   2 +-
>> :  .../org/apache/solr/cloud/OverseerTest.java |   7 ++
>> :  3 files changed, 69 insertions(+), 50 deletions(-)
>> : --
>> :
>> :
>> :
>> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/efb7bb17/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
>> : --
>> : diff --git
>> a/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
>> b/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
>> : index da4b0c6..6743436 100644
>> : --- a/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
>> : +++ b/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
>> : @@ -110,8 +110,11 @@ class ShardLeaderElectionContextBase extends
>> ElectionContext {
>> :protected String shardId;
>> :protected String collection;
>> :protected LeaderElector leaderElector;
>> : -  protected volatile Integer leaderZkNodeParentVersion;
>> : -
>> : +  private Integer leaderZkNodeParentVersion;
>> : +
>> : +  // Prevents a race between cancelling and becoming leader.
>> : +  private final Object lock = new Object();
>> : +
>> :public ShardLeaderElectionContextBase(LeaderElector leaderElector,
>> :final String shardId, final String collection, final String
>> coreNodeName,
>> :ZkNodeProps props, ZkStateReader zkStateReader) {
>> : @@ -138,31 +141,33 @@ class ShardLeaderElectionContextBase extends
>> ElectionContext {
>> :@Override
>> :public void cancelElection() throws InterruptedException,
>> KeeperException {
>> :  super.cancelElection();
>> : -if (leaderZkNodeParentVersion != null) {
>> : -  try {
>> : -// We need to be careful and make sure we *only* delete our own
>> leader registration node.
>> : -// We do this by using a multi and ensuring the parent znode of
>> the leader registration node
>> : -// matches the version we expect - there is a setData call that
>> increments the parent's znode
>> : -// version whenever a leader registers.
>> : -log.info("Removing leader registration node on cancel: {} {}",
>> leaderPath, leaderZkNodeParentVersion);
>> : -List ops = new ArrayList<>(2);
>> : -ops.add(Op.check(new Path(leaderPath).getParent().toString(),
>> leaderZkNodeParentVersion));
>> : -ops.add(Op.delete(leaderPath, -1));
>> : -zkClient.multi(ops, true);
>> : -  } catch (KeeperException.NoNodeException nne) {
>> : -// no problem
>> : -log.info("No leader registration node found to remove: {}",
>> leaderPath);
>> : -  } catch (KeeperException.BadVersionException bve) {
>> : -log.info("Cannot remove leader registration node because the
>> current registered node is not ours: {}", 

[jira] [Commented] (SOLR-8697) Fix LeaderElector issues

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8697:
---

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

SOLR-8697: Fix precommit failure


> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: OverseerTestFail.log, SOLR-8697-followup.patch, 
> SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8752) Add a test for SizeLimitedDistributedMap

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8752:
---

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

SOLR-8752: Add a test for SizeLimitedDistributedMap and improve javadocs


> Add a test for SizeLimitedDistributedMap
> 
>
> Key: SOLR-8752
> URL: https://issues.apache.org/jira/browse/SOLR-8752
> Project: Solr
>  Issue Type: Test
>  Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master, 6.0
>
> Attachments: SOLR-8752.patch
>
>
> This class performs cleanup logic on a put operation. We should add a test 
> for it and beef up javadocs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 880 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/880/

1 tests failed.
FAILED:  org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([31C685F6F8BEA479:D89C3ECE662734D1]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:764)
at 
org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir(TestArbitraryIndexDir.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=*[count(//doc)=1]
xml response was: 

00


request was:q=id:2=standard=0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:757)
... 41 more




Build 

[jira] [Updated] (SOLR-8752) Add a test for SizeLimitedDistributedMap

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-8752:

Attachment: SOLR-8752.patch

Test + simple javadocs for SizeLimitedDistributedMap

> Add a test for SizeLimitedDistributedMap
> 
>
> Key: SOLR-8752
> URL: https://issues.apache.org/jira/browse/SOLR-8752
> Project: Solr
>  Issue Type: Test
>  Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master, 6.0
>
> Attachments: SOLR-8752.patch
>
>
> This class performs cleanup logic on a put operation. We should add a test 
> for it and beef up javadocs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-8752) Add a test for SizeLimitedDistributedMap

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-8752:
---

 Summary: Add a test for SizeLimitedDistributedMap
 Key: SOLR-8752
 URL: https://issues.apache.org/jira/browse/SOLR-8752
 Project: Solr
  Issue Type: Test
  Components: SolrCloud, Tests
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
 Fix For: master, 6.0


This class performs cleanup logic on a put operation. We should add a test for 
it and beef up javadocs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-5.5-Linux (64bit/jdk-9-ea+106) - Build # 137 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/137/
Java: 64bit/jdk-9-ea+106 -XX:+UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.memory.TestMemoryPostingsFormat

Error Message:
The test or suite printed 10450 bytes to stdout and stderr, even though the 
limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
completely with @SuppressSysoutChecks or run with -Dtests.verbose=true

Stack Trace:
java.lang.AssertionError: The test or suite printed 10450 bytes to stdout and 
stderr, even though the limit was set to 8192 bytes. Increase the limit with 
@Limit, ignore it completely with @SuppressSysoutChecks or run with 
-Dtests.verbose=true
at __randomizedtesting.SeedInfo.seed([E29A46429CEDF9DF]:0)
at 
org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:211)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
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:367)
at java.lang.Thread.run(Thread.java:804)


FAILED:  
org.apache.lucene.codecs.blockterms.TestFixedGapPostingsFormat.testDocsAndFreqsAndPositionsAndOffsets

Error Message:
Captured an uncaught exception in thread: Thread[id=624, name=Thread-601, 
state=RUNNABLE, group=TGRP-TestFixedGapPostingsFormat]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=624, name=Thread-601, state=RUNNABLE, 
group=TGRP-TestFixedGapPostingsFormat]
Caused by: java.lang.RuntimeException: java.lang.IllegalArgumentException: 
source=3 is out of bounds (maxState is 2)
at __randomizedtesting.SeedInfo.seed([E29A46429CEDF9DF]:0)
at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1005)
Caused by: java.lang.IllegalArgumentException: source=3 is out of bounds 
(maxState is 2)
at 
org.apache.lucene.util.automaton.Automaton.addTransition(Automaton.java:167)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:245)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:537)
at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:612)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:521)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomSingleAutomaton(AutomatonTestUtil.java:262)
at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomAutomaton(AutomatonTestUtil.java:277)
at 
org.apache.lucene.index.RandomPostingsTester.testTermsOneThread(RandomPostingsTester.java:1166)
at 
org.apache.lucene.index.RandomPostingsTester.access$000(RandomPostingsTester.java:62)
at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1003)


FAILED:  
org.apache.lucene.codecs.memory.TestMemoryPostingsFormat.testDocsAndFreqsAndPositionsAndPayloads

Error Message:
Captured an uncaught exception in thread: Thread[id=265, name=Thread-248, 
state=RUNNABLE, group=TGRP-TestMemoryPostingsFormat]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=265, name=Thread-248, state=RUNNABLE, 
group=TGRP-TestMemoryPostingsFormat]
Caused by: java.lang.RuntimeException: java.lang.IllegalArgumentException: 
source=3 is out of bounds (maxState is 2)
at __randomizedtesting.SeedInfo.seed([E29A46429CEDF9DF]:0)
at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1005)
Caused by: java.lang.IllegalArgumentException: source=3 is out of bounds 
(maxState is 2)
at 
org.apache.lucene.util.automaton.Automaton.addTransition(Automaton.java:167)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:245)
at 

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 879 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/879/

4 tests failed.
FAILED:  
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.testFullImportFieldsParam

Error Message:
IOException occured when talking to server at: 
https://127.0.0.1:45946/solr/collection1

Stack Trace:
java.lang.AssertionError: IOException occured when talking to server at: 
https://127.0.0.1:45946/solr/collection1
at 
__randomizedtesting.SeedInfo.seed([6CC006AF69DFEFE6:9B0B4966C4DD5C3B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.testFullImportFieldsParam(TestSolrEntityProcessorEndToEnd.java:184)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.testFullImportFqParam

Error Message:
IOException occured when talking to server at: 
https://127.0.0.1:48782/solr/collection1

Stack 

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+106) - Build # 16019 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16019/
Java: 32bit/jdk-9-ea+106 -server -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 36439 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.awt.Component#getPeer() [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.awt.Font#getPeer() [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.awt.MenuComponent#getPeer() [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.awt.Toolkit#getFontPeer(java.lang.String,int) [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.jar.Pack200$Packer#addPropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.jar.Pack200$Packer#removePropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.jar.Pack200$Unpacker#addPropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.jar.Pack200$Unpacker#removePropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.logging.LogManager#addPropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.logging.LogManager#removePropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
API invocations (in 1.38s), 1 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:740: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:347: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:504: 
Check for forbidden API calls failed, see log.

Total time: 70 minutes 32 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[GitHub] lucene-solr pull request: add tests for org.apache.solr.util.hll.N...

[bvanalderweireldt]

GitHub user bvanalderweireldt opened a pull request:

https://github.com/apache/lucene-solr/pull/15

add tests for org.apache.solr.util.hll.NumberUtilTest

First commit and first contribution, I haven't created any Jira ticket.

I create a test class for an uncovered class I found using the test 
coverage report.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bvanalderweireldt/lucene-solr NumberUtilTest

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/15.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #15


commit b1042b6443a1987a50b5f3bfcedd74c5e6c708cb
Author: bvanalderweireldt 
Date:   2016-02-27T05:38:33Z

add tests for org.apache.solr.util.hll.NumberUtilTest




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 3114 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/3114/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
KeeperErrorCode = Session expired for /clusterstate.json

Stack Trace:
org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = 
Session expired for /clusterstate.json
at 
__randomizedtesting.SeedInfo.seed([C4FB79DA0B0CFF25:4CAF4600A5F092DD]:0)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:127)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1155)
at 
org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:353)
at 
org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:350)
at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
at 
org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:350)
at 
org.apache.solr.common.cloud.ZkStateReader.refreshLegacyClusterState(ZkStateReader.java:448)
at 
org.apache.solr.common.cloud.ZkStateReader.updateClusterState(ZkStateReader.java:240)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:148)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:135)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:130)
at 
org.apache.solr.cloud.BasicDistributedZkTest.testANewCollectionInOneInstance(BasicDistributedZkTest.java:929)
at 
org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:359)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 878 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/878/

All tests passed

Build Log:
[...truncated 36078 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
API invocations (in 1.41s), 1 error(s).

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:740:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:117:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build.xml:347:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/common-build.xml:504:
 Check for forbidden API calls failed, see log.

Total time: 65 minutes 45 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[JENKINS] Lucene-Solr-5.5-Linux (64bit/jdk1.7.0_80) - Build # 136 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/136/
Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseG1GC

No tests ran.

Build Log:
[...truncated 14 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: 
org.eclipse.jgit.api.errors.TransportException: Connection reset
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:639)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:764)
... 11 more
Caused by: org.eclipse.jgit.api.errors.TransportException: Connection reset
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:637)
... 12 more
Caused by: org.eclipse.jgit.errors.TransportException: Connection reset
at 
org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefs(BasePackConnection.java:182)
at 
org.eclipse.jgit.transport.TransportGitAnon$TcpFetchConnection.(TransportGitAnon.java:194)
at 
org.eclipse.jgit.transport.TransportGitAnon.openFetch(TransportGitAnon.java:120)
at 
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
at 
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
... 13 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
at org.eclipse.jgit.util.IO.readFully(IO.java:246)
at 
org.eclipse.jgit.transport.PacketLineIn.readLength(PacketLineIn.java:186)
at 
org.eclipse.jgit.transport.PacketLineIn.readString(PacketLineIn.java:138)
at 
org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefsImpl(BasePackConnection.java:195)
at 
org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefs(BasePackConnection.java:176)
... 19 more
ERROR: null
Retrying after 10 seconds
Fetching changes from the remote Git repository
Cleaning workspace
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: 
org.eclipse.jgit.api.errors.TransportException: Connection reset
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:639)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:764)
... 11 more
Caused by: org.eclipse.jgit.api.errors.TransportException: Connection reset
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:637)
... 12 more
Caused by: org.eclipse.jgit.errors.TransportException: Connection 

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_72) - Build # 16018 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16018/
Java: 32bit/jdk1.8.0_72 -client -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 36086 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
API invocations (in 1.48s), 1 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:740: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:347: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:504: 
Check for forbidden API calls failed, see log.

Total time: 77 minutes 56 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

Re: lucene-solr git commit: SOLR-8697: Add synchronization around registering as leader and canceling.

[Scott Blum]

That's annoying, since there's no semantic difference between that and a
log.warn(fmt, arg, arg).  Except that this particular logging API doesn't
have an overload that takes a throwable, a format string, and a set of args.

On Fri, Feb 26, 2016 at 8:02 PM, Chris Hostetter 
wrote:

>
> this breaks precommit...
>
>
> [forbidden-apis] Forbidden method invocation:
> java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default
> locale]
> [forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController
> (OverseerTest.java:128)
> [forbidden-apis] Scanned 3181 (and 1946 related) class file(s) for
> forbidden API invocations (in 1.27s), 1 error(s).
>
>
>
>
> : Date: Fri, 26 Feb 2016 17:32:25 + (UTC)
> : From: markrmil...@apache.org
> : Reply-To: dev@lucene.apache.org
> : To: comm...@lucene.apache.org
> : Subject: lucene-solr git commit: SOLR-8697: Add synchronization around
> : registering as leader and canceling.
> :
> : Repository: lucene-solr
> : Updated Branches:
> :   refs/heads/master 0ed625b10 -> efb7bb171
> :
> :
> : SOLR-8697: Add synchronization around registering as leader and
> canceling.
> :
> :
> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> : Commit:
> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/efb7bb17
> : Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/efb7bb17
> : Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/efb7bb17
> :
> : Branch: refs/heads/master
> : Commit: efb7bb171b22a3c6a00d30eefe935a0024df0c71
> : Parents: 0ed625b
> : Author: markrmiller 
> : Authored: Fri Feb 26 12:32:12 2016 -0500
> : Committer: markrmiller 
> : Committed: Fri Feb 26 12:32:12 2016 -0500
> :
> : --
> :  .../org/apache/solr/cloud/ElectionContext.java  | 110
> ++-
> :  .../org/apache/solr/cloud/ZkController.java |   2 +-
> :  .../org/apache/solr/cloud/OverseerTest.java |   7 ++
> :  3 files changed, 69 insertions(+), 50 deletions(-)
> : --
> :
> :
> :
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/efb7bb17/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
> : --
> : diff --git
> a/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
> b/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
> : index da4b0c6..6743436 100644
> : --- a/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
> : +++ b/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
> : @@ -110,8 +110,11 @@ class ShardLeaderElectionContextBase extends
> ElectionContext {
> :protected String shardId;
> :protected String collection;
> :protected LeaderElector leaderElector;
> : -  protected volatile Integer leaderZkNodeParentVersion;
> : -
> : +  private Integer leaderZkNodeParentVersion;
> : +
> : +  // Prevents a race between cancelling and becoming leader.
> : +  private final Object lock = new Object();
> : +
> :public ShardLeaderElectionContextBase(LeaderElector leaderElector,
> :final String shardId, final String collection, final String
> coreNodeName,
> :ZkNodeProps props, ZkStateReader zkStateReader) {
> : @@ -138,31 +141,33 @@ class ShardLeaderElectionContextBase extends
> ElectionContext {
> :@Override
> :public void cancelElection() throws InterruptedException,
> KeeperException {
> :  super.cancelElection();
> : -if (leaderZkNodeParentVersion != null) {
> : -  try {
> : -// We need to be careful and make sure we *only* delete our own
> leader registration node.
> : -// We do this by using a multi and ensuring the parent znode of
> the leader registration node
> : -// matches the version we expect - there is a setData call that
> increments the parent's znode
> : -// version whenever a leader registers.
> : -log.info("Removing leader registration node on cancel: {} {}",
> leaderPath, leaderZkNodeParentVersion);
> : -List ops = new ArrayList<>(2);
> : -ops.add(Op.check(new Path(leaderPath).getParent().toString(),
> leaderZkNodeParentVersion));
> : -ops.add(Op.delete(leaderPath, -1));
> : -zkClient.multi(ops, true);
> : -  } catch (KeeperException.NoNodeException nne) {
> : -// no problem
> : -log.info("No leader registration node found to remove: {}",
> leaderPath);
> : -  } catch (KeeperException.BadVersionException bve) {
> : -log.info("Cannot remove leader registration node because the
> current registered node is not ours: {}", leaderPath);
> : -// no problem
> : -  } catch (InterruptedException e) {
> : -throw e;
> : -  } catch (Exception e) {
> : -SolrException.log(log, e);
> : +synchronized (lock) {

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 877 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/877/

All tests passed

Build Log:
[...truncated 36087 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
API invocations (in 1.33s), 1 error(s).

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:740:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:117:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build.xml:347:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/common-build.xml:504:
 Check for forbidden API calls failed, see log.

Total time: 66 minutes 39 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_72) - Build # 5648 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5648/
Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 36095 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
[forbidden-apis] Reading API signatures: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\tools\forbiddenApis\base.txt
[forbidden-apis] Reading API signatures: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\tools\forbiddenApis\servlet-api.txt
[forbidden-apis] Reading API signatures: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\tools\forbiddenApis\solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
API invocations (in 3.85s), 1 error(s).

BUILD FAILED
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:740: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:117: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build.xml:347: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\common-build.xml:504:
 Check for forbidden API calls failed, see log.

Total time: 86 minutes 17 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[JENKINS] Lucene-Solr-Tests-trunk-mmap-Java8 - Build # 8 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-mmap-Java8/8/

2 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication

Error Message:
Index: 0, Size: 0

Stack Trace:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at 
__randomizedtesting.SeedInfo.seed([C0DEF529AD400B57:37AD1B716BA8A4B1]:0)
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1241)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'CY val' for path 'response/params/y/c' full 
output: {   "responseHeader":{ "status":0, "QTime":0},   "response":{   
  "znodeVersion":0, "params":{"x":{ "a":"A val", 

Re: [JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk-9-ea+105) - Build # 15587 - Still Failing!

[Robert Muir]

I see Tobias Hartmann debugged the issue and its already fixed.
(https://bugs.openjdk.java.net/browse/JDK-8150280)

Please tell him thanks!

On Fri, Feb 19, 2016 at 1:04 PM, Robert Muir  wrote:
> Thanks!
>
> On Fri, Feb 19, 2016 at 1:01 PM, Rory O'Donnell
>  wrote:
>> Hi Robert,
>>
>> https://bugs.openjdk.java.net/browse/JDK-8150280 logged.
>>
>> Rgds,Rory
>>
>>
>> On 17/02/2016 17:58, Robert Muir wrote:
>>>
>>> We got this reproducing 100% and I opened a bug report:
>>>
>>> Review ID: JI-9029607
>>>
>>>
>>> On Wed, Feb 17, 2016 at 12:50 AM, Robert Muir  wrote:

 It may be the same bug triggering all the automaton failures (we have
 had several now with EA 105).

 I can trigger it to happen it in a really inefficient way at the
 moment by running the test thousands of times:
 https://issues.apache.org/jira/browse/LUCENE-7032

 I tested with it enough to know its unrelated to CompactStrings or any
 of the other options that we randomize in jenkins.

 On Tue, Feb 16, 2016 at 4:07 AM, Uwe Schindler  wrote:
>
> Hi,
>
> yes will do. At the moment I am analyzing the problematic test runs. We
> had many other failures last night all looking a bit different (no 
> crushes,
> but assertions failing). I will disable compact strings one more time to 
> see
> if this makes it better. I still have the feeling that it could be related
> to that! But definitely the compact strings issue seen last time looks
> solved.
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -Original Message-
>> From: Rory O'Donnell [mailto:rory.odonn...@oracle.com]
>> Sent: Tuesday, February 16, 2016 9:39 AM
>> To: dev@lucene.apache.org
>> Cc: rory.odonn...@oracle.com; 'Dalibor Topic'
>> ;
>> 'Balchandra Vaidya' ; 'Muneer Kolarkunnu'
>> 
>> Subject: Re: [JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk-9-ea+105) -
>> Build
>> # 15587 - Still Failing!
>>
>> Hi Uwe,
>>
>> Let us know the incident number if it turns out to be a JDK 9 issue.
>>
>> Thanks,Rory
>>
>> On 15/02/2016 22:30, Uwe Schindler wrote:
>>>
>>> Hi Rory, hi committers,
>>>
>>> Unless this is a new bug in Lucene Master (but there was no related
>>
>> commit!!!), this looks like a new bug in Java 9 build 105.
>>>
>>> Uwe
>>>
>>> -
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>> eMail: u...@thetaphi.de
>>>
>>>
 -Original Message-
 From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
 Sent: Monday, February 15, 2016 11:26 PM
 To: u...@thetaphi.de; dev@lucene.apache.org
 Subject: [JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk-9-ea+105) -
 Build #
 15587 - Still Failing!
 Importance: Low

 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15587/
 Java: 64bit/jdk-9-ea+105 -XX:-UseCompressedOops -XX:+UseG1GC -XX:-
 UseSuperWord

 2 tests failed.
 FAILED:

>> org.apache.lucene.search.TestMinShouldMatch2.testNextVaryingNumberOf

 Terms

 Error Message:


 Stack Trace:
 java.lang.AssertionError
 at

>> __randomizedtesting.SeedInfo.seed([F872E59E6028464C:7A3791B3AC63E2D]

 :0)
 at

>> org.apache.lucene.search.BooleanScorer.scoreWindowIntoBitSetAndReplay(

 BooleanScorer.java:218)
 at

>> org.apache.lucene.search.BooleanScorer.scoreWindowMultipleScorers(Bool

 eanScorer.java:266)
 at

>> org.apache.lucene.search.BooleanScorer.scoreWindow(BooleanScorer.java:

 311)
 at
 org.apache.lucene.search.BooleanScorer.score(BooleanScorer.java:335)
 at

>>
>> org.apache.lucene.search.BulkScorerWrapperScorer.refill(BulkScorerWrappe

 rScorer.java:52)
 at

>> org.apache.lucene.search.BulkScorerWrapperScorer.access$500(BulkScorer

 WrapperScorer.java:25)
 at

>> org.apache.lucene.search.BulkScorerWrapperScorer$2.advance(BulkScorer

 WrapperScorer.java:101)
 at

>> org.apache.lucene.search.BulkScorerWrapperScorer$2.nextDoc(BulkScorer

 WrapperScorer.java:95)
 at

>> org.apache.lucene.search.TestMinShouldMatch2.assertNext(TestMinShould

 Match2.java:157)

[jira] [Resolved] (LUCENE-7032) jdk-9-ea+105 breaks MinimizeOperations.minimize()

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-7032.
-
Resolution: Fixed

See https://bugs.openjdk.java.net/browse/JDK-8150280

Tobias Hartmann debugged the issue.

> jdk-9-ea+105 breaks MinimizeOperations.minimize()
> -
>
> Key: LUCENE-7032
> URL: https://issues.apache.org/jira/browse/LUCENE-7032
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: master
>Reporter: Robert Muir
>  Labels: Java9
>
> As soon as jdk-9-ea+105 was put into test rotation, automaton tests have been 
> sporatically failing in non-reproducible ways. All of them invoke hopcroft 
> minimization either directly or indirectly.
> The bug manifests in several forms:
> * ArrayIndexOutOfBoundsException in minimize()
> * IllegalArgumentException for an explicit bounds check
> * incorrect resulting automaton
> This method is ... let's say not the ideal one to debug something like this, 
> but I've at least got it where I can make it fail in a few minutes with 
> beasting, so we can try simple things like turning on/off jvm flags to try to 
> narrow it more.
> It would be really great to make it fail more efficiently, but unfortunately 
> it takes many thousands of iterations until we understand more about it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-8751) ResourceLoader should be able to load content from blob store

[Noble Paul (JIRA)]

Noble Paul created SOLR-8751:


 Summary: ResourceLoader should be able to load content from blob 
store
 Key: SOLR-8751
 URL: https://issues.apache.org/jira/browse/SOLR-8751
 Project: Solr
  Issue Type: Task
Reporter: Noble Paul
Assignee: Noble Paul


blob store is not necessarily available at the core load time. So it may 
require a new method to load such content. 
{code}
//add a new method to SolrResourceLoader

public void openResource(String resource , Callable callback) {
   //todo implement this to load from blob store , if resource name is prefixed 
with "blob:" , example: "blob:mysynonymys/1"

  }
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-5.5-Linux (64bit/jdk-9-ea+106) - Build # 135 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/135/
Java: 64bit/jdk-9-ea+106 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3.test

Error Message:
17

Stack Trace:
java.lang.ArrayIndexOutOfBoundsException: 17
at 
__randomizedtesting.SeedInfo.seed([1E982F6A0EA0EB45:96CC10B0A05C86BD]:0)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:524)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
at 
org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3.assertTerms(TestBlockPostingsFormat3.java:186)
at 
org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3.verify(TestBlockPostingsFormat3.java:153)
at 
org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3.test(TestBlockPostingsFormat3.java:137)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:804)




Build Log:
[...truncated 1429 lines...]
   [junit4] Suite: org.apache.lucene.codecs.lucene50.TestBlockPostingsFormat3
   [junit4]   2> NOTE: reproduce with: ant test  

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk-9-ea+106) - Build # 16017 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16017/
Java: 64bit/jdk-9-ea+106 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.lucene.codecs.perfield.TestPerFieldPostingsFormat.testDocsOnly

Error Message:
Captured an uncaught exception in thread: Thread[id=655, name=Thread-467, 
state=RUNNABLE, group=TGRP-TestPerFieldPostingsFormat]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=655, name=Thread-467, state=RUNNABLE, 
group=TGRP-TestPerFieldPostingsFormat]
at 
__randomizedtesting.SeedInfo.seed([A8B6A11D0F51F0D5:D4F20B0F05808585]:0)
Caused by: java.lang.RuntimeException: 
java.lang.ArrayIndexOutOfBoundsException: 13
at __randomizedtesting.SeedInfo.seed([A8B6A11D0F51F0D5]:0)
at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1006)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 13
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:524)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomSingleAutomaton(AutomatonTestUtil.java:262)
at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomAutomaton(AutomatonTestUtil.java:277)
at 
org.apache.lucene.index.RandomPostingsTester.testTermsOneThread(RandomPostingsTester.java:1167)
at 
org.apache.lucene.index.RandomPostingsTester.access$000(RandomPostingsTester.java:61)
at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1004)




Build Log:
[...truncated 1165 lines...]
   [junit4] Suite: org.apache.lucene.codecs.perfield.TestPerFieldPostingsFormat
   [junit4]   2> Feb 26, 2016 10:57:26 NYIAGHUO 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> WARNING: Uncaught exception in thread: 
Thread[Thread-467,5,TGRP-TestPerFieldPostingsFormat]
   [junit4]   2> java.lang.RuntimeException: 
java.lang.ArrayIndexOutOfBoundsException: 13
   [junit4]   2>at 
__randomizedtesting.SeedInfo.seed([A8B6A11D0F51F0D5]:0)
   [junit4]   2>at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1006)
   [junit4]   2> Caused by: java.lang.ArrayIndexOutOfBoundsException: 13
   [junit4]   2>at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:524)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
   [junit4]   2>at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomSingleAutomaton(AutomatonTestUtil.java:262)
   [junit4]   2>at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomAutomaton(AutomatonTestUtil.java:277)
   [junit4]   2>at 
org.apache.lucene.index.RandomPostingsTester.testTermsOneThread(RandomPostingsTester.java:1167)
   [junit4]   2>at 
org.apache.lucene.index.RandomPostingsTester.access$000(RandomPostingsTester.java:61)
   [junit4]   2>at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1004)
   [junit4]   2> 
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestPerFieldPostingsFormat -Dtests.method=testDocsOnly 
-Dtests.seed=A8B6A11D0F51F0D5 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=ksb -Dtests.timezone=America/Argentina/San_Luis 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.07s J0 | TestPerFieldPostingsFormat.testDocsOnly <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=655, name=Thread-467, state=RUNNABLE, 
group=TGRP-TestPerFieldPostingsFormat]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([A8B6A11D0F51F0D5:D4F20B0F05808585]:0)
   [junit4]> Caused by: java.lang.RuntimeException: 
java.lang.ArrayIndexOutOfBoundsException: 13
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([A8B6A11D0F51F0D5]:0)
   [junit4]>at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1006)
   [junit4]> Caused by: java.lang.ArrayIndexOutOfBoundsException: 13
   [junit4]>at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
   [junit4]>at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:524)
   

[jira] [Created] (SOLR-8750) Use lambdas in code where SAM type interfaces are used

[Noble Paul (JIRA)]

Noble Paul created SOLR-8750:


 Summary: Use lambdas in code where SAM type interfaces are used
 Key: SOLR-8750
 URL: https://issues.apache.org/jira/browse/SOLR-8750
 Project: Solr
  Issue Type: Task
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8110) Start enforcing field naming recomendations in next X.0 release?

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8110:


Right now, the first attempts at validation (SOLR-8642) have resulted in 
SOLR-8725.  I believe that the restrictions in SOLR-8642 are the only ones that 
will be safe for advanced and possible future features (like infix expressions 
and separators that have meaning to Solr) that Yonik mentioned.

I've stared at my keyboard for several minutes trying to see whether there are 
any other good choices for a meaningful separator character other than the 
period, and all of the possibilities are either used for something else, or 
they're really arcane and likely to cause the kind of problems we're aiming to 
prevent with this issue.  For that reason, I think that periods should be 
banned for right now, and then only allowed in a limited fashion as necessary 
to support that future separator idea, if it ever becomes a reality.

For my purposes, I'm perfectly OK with breaking backward compatibility in 6.0 
and enforcing SOLR-8642 across the board.  I will need to change my own core 
names (which currently use hyphens), but I'm OK with that.  Recognizing the 
pain this could cause, I can get behind an approach where violations cause a 
warning in 6.0, and default to enforcement later.

Parsing code tends to be extremely complex and fragile in the best conditions.  
When a character that has special meaning in some contexts is allowed in 
identifiers, that code is even more fragile.  I would rather be more 
restrictive on this issue than risk parser bugs.


> Start enforcing field naming recomendations in next X.0 release?
> 
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> For a very long time now, Solr has made the following "recommendation" 
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only 
> and not start with a digit.  This is not currently strictly enforced, but 
> other field names will not have first class support from all components and 
> back compatibility is not guaranteed.  ...
> I'm opening this issue to track discussion about if/how we should start 
> enforcing this as a rule instead (instead of just a "recommendation") in our 
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with 
> lists of field and produce strange errors when the huerstic fails (example: 
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the 
> recommended conventions and then only later encountering a situation where 
> their field names are not supported by some feature and get frustrated 
> because they have to change their schema, reindex, update index/query client 
> expectations, etc...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8724) Upgrade Zookeeper to 3.4.8

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8724:
--

I'm getting the same errors when running the older patch too; previous success 
with the older patch was on my laptop, but seeing consistent failures on my 
server with more test concurrency.  So the errors are unrelated to the 
parseProperties() implementation.

Here's one (all 5 suites that fail have this pattern: in the process of a 
ZkTestServer starting up, it fails to register the connection in the platform 
MBean server):

{noformat}
   [junit4] Suite: org.apache.solr.handler.TestSolrConfigHandlerConcurrent
   [junit4]   2> Creating dataDir: 
/home/sarowe/git/lucene-solr/solr/build/solr-core/test/J12/temp/solr.handler.TestSolrConfigHandlerConcurrent_ACC627484AE10FE0-001/init-core-data-001
   [junit4]   2> 0INFO  
(SUITE-TestSolrConfigHandlerConcurrent-seed#[ACC627484AE10FE0]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false)
   [junit4]   2> 37   INFO  
(SUITE-TestSolrConfigHandlerConcurrent-seed#[ACC627484AE10FE0]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 107  INFO  
(TEST-TestSolrConfigHandlerConcurrent.test-seed#[ACC627484AE10FE0]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 117  INFO  (Thread-1) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 117  INFO  (Thread-1) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 215  INFO  
(TEST-TestSolrConfigHandlerConcurrent.test-seed#[ACC627484AE10FE0]) [] 
o.a.s.c.ZkTestServer start zk server on port:34020
   [junit4]   2> 243  INFO  
(TEST-TestSolrConfigHandlerConcurrent.test-seed#[ACC627484AE10FE0]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 298  INFO  
(TEST-TestSolrConfigHandlerConcurrent.test-seed#[ACC627484AE10FE0]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 334  ERROR (SyncThread:0) [] 
o.a.z.s.ZooKeeperCriticalThread Severe unrecoverable error, from thread : 
SyncThread:0
   [junit4]   2> java.lang.AssertionError
   [junit4]   2>at 
org.apache.zookeeper.jmx.MBeanRegistry.register(MBeanRegistry.java:93)
   [junit4]   2>at 
org.apache.zookeeper.server.ServerCnxnFactory.registerConnection(ServerCnxnFactory.java:147)
   [junit4]   2>at 
org.apache.zookeeper.server.ZooKeeperServer.finishSessionInit(ZooKeeperServer.java:613)
   [junit4]   2>at 
org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:181)
   [junit4]   2>at 
org.apache.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:200)
   [junit4]   2>at 
org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:131)
   [junit4]   2> 45314 WARN  
(TEST-TestSolrConfigHandlerConcurrent.test-seed#[ACC627484AE10FE0]-SendThread(127.0.0.1:34020))
 [] o.a.z.ClientCnxn Client session timed out, have not heard from server 
in 45007ms for sessionid 0x0
   [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=TestSolrConfigHandlerConcurrent -Dtests.method=test 
-Dtests.seed=ACC627484AE10FE0 -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=de-LU -Dtests.timezone=Cuba -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   45.4s J12 | TestSolrConfigHandlerConcurrent.test <<<
   [junit4]> Throwable #1: org.apache.solr.common.SolrException: 
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:34020 within 45000 ms
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([ACC627484AE10FE0:24921892E41D6218]:0)
   [junit4]>at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:181)
   [junit4]>at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:115)
   [junit4]>at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:105)
   [junit4]>at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:88)
   [junit4]>at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:82)
   [junit4]>at 
org.apache.solr.cloud.AbstractDistribZkTestBase.distribSetUp(AbstractDistribZkTestBase.java:75)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.distribSetUp(AbstractFullDistribZkTestBase.java:217)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:966)
   [junit4]>at 

Re: [JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 876 - Still Failing

[Michael McCandless]

Mark it looks like you broke the build ... can you fix?  Thanks.

Next time try to run "ant precommit" first, or at least try not to
"commit and run".

Mike McCandless

http://blog.mikemccandless.com

On Fri, Feb 26, 2016 at 8:22 PM, Apache Jenkins Server
 wrote:
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/876/
>
> All tests passed
>
> Build Log:
> [...truncated 36078 lines...]
> -check-forbidden-all:
> [forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
> [forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
> [forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
> [forbidden-apis] Reading API signatures: 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/base.txt
> [forbidden-apis] Reading API signatures: 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/servlet-api.txt
> [forbidden-apis] Reading API signatures: 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/solr.txt
> [forbidden-apis] Loading classes to check...
> [forbidden-apis] Scanning classes for violations...
> [forbidden-apis] Forbidden method invocation: 
> java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
> locale]
> [forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
> (OverseerTest.java:128)
> [forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
> API invocations (in 1.43s), 1 error(s).
>
> BUILD FAILED
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:740:
>  The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:117:
>  The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build.xml:347:
>  The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/common-build.xml:504:
>  Check for forbidden API calls failed, see log.
>
> Total time: 66 minutes 1 second
> Build step 'Invoke Ant' marked build as failure
> Archiving artifacts
> Recording test results
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 876 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/876/

All tests passed

Build Log:
[...truncated 36078 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
API invocations (in 1.43s), 1 error(s).

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:740:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:117:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build.xml:347:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/common-build.xml:504:
 Check for forbidden API calls failed, see log.

Total time: 66 minutes 1 second
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Created] (SOLR-8749) blob store API should have convenience methods for editing json

[Noble Paul (JIRA)]

Noble Paul created SOLR-8749:


 Summary: blob store API should have convenience methods for 
editing json
 Key: SOLR-8749
 URL: https://issues.apache.org/jira/browse/SOLR-8749
 Project: Solr
  Issue Type: Bug
  Components: blobstore
Reporter: Noble Paul
Assignee: Noble Paul


if the blob content is a json it should be possible to edit the content without 
downloading it

example commands

{code}

curl http://localhost:8983/solr/.system/myblobname/json -H 
'Content-type:application/json' -d '{
   set : {
"/full/path" : {}
  },
  set : { "/full/path" : "The value"  } 
  append : {"/full/path" : "val"},
  append : {"/full/path" : { map_key, " map value"  }},
  delete : "/full/path"
}
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-8748) OverseerTaskProcessor limits number of concurrent tasks to just 10 even though the thread pool size is 100

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-8748:
---

 Summary: OverseerTaskProcessor limits number of concurrent tasks 
to just 10 even though the thread pool size is 100
 Key: SOLR-8748
 URL: https://issues.apache.org/jira/browse/SOLR-8748
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 5.5, 4.10.4
Reporter: Shalin Shekhar Mangar
 Fix For: master, 6.0


OverseerTaskProcessor uses maxParallelThreads to limit number of concurrent 
tasks but the same is not used for creating the thread pool. The default limit 
of 10 is too small, IMO and we should change it to 100. The overseer collection 
processor mostly just waits around on network calls so there is no harm in 
increasing this limit.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: lucene-solr git commit: SOLR-8697: Add synchronization around registering as leader and canceling.

[Chris Hostetter]

this breaks precommit...


[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3181 (and 1946 related) class file(s) for 
forbidden API invocations (in 1.27s), 1 error(s).




: Date: Fri, 26 Feb 2016 17:32:25 + (UTC)
: From: markrmil...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: lucene-solr git commit: SOLR-8697: Add synchronization around
: registering as leader and canceling.
: 
: Repository: lucene-solr
: Updated Branches:
:   refs/heads/master 0ed625b10 -> efb7bb171
: 
: 
: SOLR-8697: Add synchronization around registering as leader and canceling.
: 
: 
: Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
: Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/efb7bb17
: Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/efb7bb17
: Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/efb7bb17
: 
: Branch: refs/heads/master
: Commit: efb7bb171b22a3c6a00d30eefe935a0024df0c71
: Parents: 0ed625b
: Author: markrmiller 
: Authored: Fri Feb 26 12:32:12 2016 -0500
: Committer: markrmiller 
: Committed: Fri Feb 26 12:32:12 2016 -0500
: 
: --
:  .../org/apache/solr/cloud/ElectionContext.java  | 110 ++-
:  .../org/apache/solr/cloud/ZkController.java |   2 +-
:  .../org/apache/solr/cloud/OverseerTest.java |   7 ++
:  3 files changed, 69 insertions(+), 50 deletions(-)
: --
: 
: 
: 
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/efb7bb17/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
: --
: diff --git a/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java 
b/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
: index da4b0c6..6743436 100644
: --- a/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
: +++ b/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
: @@ -110,8 +110,11 @@ class ShardLeaderElectionContextBase extends 
ElectionContext {
:protected String shardId;
:protected String collection;
:protected LeaderElector leaderElector;
: -  protected volatile Integer leaderZkNodeParentVersion;
: -  
: +  private Integer leaderZkNodeParentVersion;
: +
: +  // Prevents a race between cancelling and becoming leader.
: +  private final Object lock = new Object();
: +
:public ShardLeaderElectionContextBase(LeaderElector leaderElector,
:final String shardId, final String collection, final String 
coreNodeName,
:ZkNodeProps props, ZkStateReader zkStateReader) {
: @@ -138,31 +141,33 @@ class ShardLeaderElectionContextBase extends 
ElectionContext {
:@Override
:public void cancelElection() throws InterruptedException, KeeperException {
:  super.cancelElection();
: -if (leaderZkNodeParentVersion != null) {
: -  try {
: -// We need to be careful and make sure we *only* delete our own 
leader registration node.
: -// We do this by using a multi and ensuring the parent znode of the 
leader registration node
: -// matches the version we expect - there is a setData call that 
increments the parent's znode
: -// version whenever a leader registers.
: -log.info("Removing leader registration node on cancel: {} {}", 
leaderPath, leaderZkNodeParentVersion);
: -List ops = new ArrayList<>(2);
: -ops.add(Op.check(new Path(leaderPath).getParent().toString(), 
leaderZkNodeParentVersion));
: -ops.add(Op.delete(leaderPath, -1));
: -zkClient.multi(ops, true);
: -  } catch (KeeperException.NoNodeException nne) {
: -// no problem
: -log.info("No leader registration node found to remove: {}", 
leaderPath);
: -  } catch (KeeperException.BadVersionException bve) {
: -log.info("Cannot remove leader registration node because the current 
registered node is not ours: {}", leaderPath);
: -// no problem
: -  } catch (InterruptedException e) {
: -throw e;
: -  } catch (Exception e) {
: -SolrException.log(log, e);
: +synchronized (lock) {
: +  if (leaderZkNodeParentVersion != null) {
: +try {
: +  // We need to be careful and make sure we *only* delete our own 
leader registration node.
: +  // We do this by using a multi and ensuring the parent znode of 
the leader registration node
: +  // matches the version we expect - there is a setData call that 
increments the parent's znode
: +  // version whenever a leader registers.
: +  log.info("Removing leader registration node on 

[jira] [Created] (SOLR-8747) ExclusiveMarking enum and checkExclusiveMarking method is very confusing

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-8747:
---

 Summary: ExclusiveMarking enum and checkExclusiveMarking method is 
very confusing
 Key: SOLR-8747
 URL: https://issues.apache.org/jira/browse/SOLR-8747
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Shalin Shekhar Mangar
Priority: Minor
 Fix For: master, 6.0


ExclusiveMarking enum and checkExclusiveMarking method is very confusing.  It 
appears to do the opposite of its name e.g.
{code}
@Override
  public ExclusiveMarking checkExclusiveMarking(String collectionName, 
ZkNodeProps message) {
// CLUSTERSTATUS is always mutually exclusive
//TODO deprecated remove this check .
if(CLUSTERSTATUS.isEqual(message.getStr(Overseer.QUEUE_OPERATION)))
  return ExclusiveMarking.EXCLUSIVE;

synchronized (collectionWip) {
  if(collectionWip.contains(collectionName))
return ExclusiveMarking.NONEXCLUSIVE;
}

return ExclusiveMarking.NOTDETERMINED;
  }
{code}

I guess it returns exclusive if the current task is the only one to run. We 
should document it or rename it to make its function more comprehensible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-8746) Document the usage and difference between various overseer queues, rename methods if necessary

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-8746:
---

 Summary: Document the usage and difference between various 
overseer queues, rename methods if necessary
 Key: SOLR-8746
 URL: https://issues.apache.org/jira/browse/SOLR-8746
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Shalin Shekhar Mangar
 Fix For: master, 6.0


The various overseer queues can use better javadocs to document their purpose 
and usage. The method names such as getInQueue, getInternalQueue and 
getCollectionQueue aren't descriptive enough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-8745) Deprecate ZkStateReader.updateClusterState(), remove uses

[Scott Blum (JIRA)]

Scott Blum created SOLR-8745:


 Summary: Deprecate ZkStateReader.updateClusterState(), remove uses
 Key: SOLR-8745
 URL: https://issues.apache.org/jira/browse/SOLR-8745
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 5.4.1
Reporter: Scott Blum


Forcing a full ZK cluster state update creates a lot of unnecessary work and 
load at scale.  We need to deprecate and remove existing callers.

- The one at the start of ClusterStateUpdater thread is fine, it's a one-time 
thing.
- The one in OverseerCollectionMessageHandler is getting removed in SOLR-8722
- The rest of them can be replaced with a version that only updates a single 
collection; not everything!

Patch will be forthcoming.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-8744) SplitShard needs finer-grained mutual exclusion

[Scott Blum (JIRA)]

Scott Blum created SOLR-8744:


 Summary: SplitShard needs finer-grained mutual exclusion
 Key: SOLR-8744
 URL: https://issues.apache.org/jira/browse/SOLR-8744
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 5.4.1
Reporter: Scott Blum


SplitShard creates a mutex over the whole collection, but in practice this is a 
big scaling problem.  Multiple split shard operations could happen at the time 
time, as long as different shards are being split.  In practice, those shards 
often reside on different machines, so there's no I/O bottleneck in those 
cases, just the mutex in Overseer forcing the operations to be done serially.

Given that a single split can take many minutes on a large collection, this is 
a bottleneck at scale.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_72) - Build # 16016 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16016/
Java: 32bit/jdk1.8.0_72 -client -XX:+UseConcMarkSweepGC

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

Error Message:
Captured an uncaught exception in thread: Thread[id=6186, 
name=testExecutor-2813-thread-1, state=RUNNABLE, 
group=TGRP-UnloadDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=6186, name=testExecutor-2813-thread-1, 
state=RUNNABLE, group=TGRP-UnloadDistributedZkTest]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:54145/yj_hld/tf
at __randomizedtesting.SeedInfo.seed([609C45DBF90ECFCC]:0)
at 
org.apache.solr.cloud.BasicDistributedZkTest$1.run(BasicDistributedZkTest.java:586)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:231)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.solr.client.solrj.SolrServerException: Timeout occured 
while waiting response from server at: http://127.0.0.1:54145/yj_hld/tf
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:588)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.BasicDistributedZkTest$1.run(BasicDistributedZkTest.java:584)
... 4 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
at 
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at 
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
at 
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:685)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:487)
at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:482)
... 8 more




Build Log:
[...truncated 11183 lines...]
   [junit4] Suite: org.apache.solr.cloud.UnloadDistributedZkTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.UnloadDistributedZkTest_609C45DBF90ECFCC-001/init-core-data-001
   [junit4]   2> 874349 INFO  
(SUITE-UnloadDistributedZkTest-seed#[609C45DBF90ECFCC]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: 
/yj_hld/tf
   [junit4]   2> 874351 INFO  
(TEST-UnloadDistributedZkTest.test-seed#[609C45DBF90ECFCC]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 874352 INFO  (Thread-2334) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 874352 INFO  (Thread-2334) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 

[jira] [Commented] (SOLR-8110) Start enforcing field naming recomendations in next X.0 release?

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8110:


bq. I've accepted the fact that Solr will probably never need to support full 
infix expressions.

We may already have that via lucene expressions?  or the new SQL support?  Any 
future integration with scripting languages may also hit the issue.

bq. Note that I am still a proponent of having quoted/escaped names which allow 
anything in names, ala SQL.

I think I agree, but that doesn't seem compatible with this JIRA (which is 
about enforcing a specific restricted set).
If we expand the set to include what people may have used in the past (dashes, 
dots, etc), that sort of takes us full circle back to the state of things today?

> Start enforcing field naming recomendations in next X.0 release?
> 
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> For a very long time now, Solr has made the following "recommendation" 
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only 
> and not start with a digit.  This is not currently strictly enforced, but 
> other field names will not have first class support from all components and 
> back compatibility is not guaranteed.  ...
> I'm opening this issue to track discussion about if/how we should start 
> enforcing this as a rule instead (instead of just a "recommendation") in our 
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with 
> lists of field and produce strange errors when the huerstic fails (example: 
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the 
> recommended conventions and then only later encountering a situation where 
> their field names are not supported by some feature and get frustrated 
> because they have to change their schema, reindex, update index/query client 
> expectations, etc...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1690: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1690/

No tests ran.

Build Log:
[...truncated 44394 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/build.xml:763: The 
following error occurred while executing this line:
: Java returned: 1

Total time: 17 minutes 49 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Commented] (SOLR-8724) Upgrade Zookeeper to 3.4.8

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8724:
--

Hmm, must've done something wrong in the latest patch, tests are failing with 
"TimeoutException: Could not connect to ZooKeeper 127.0.0.1: within 45000 
ms".

> Upgrade Zookeeper to 3.4.8
> --
>
> Key: SOLR-8724
> URL: https://issues.apache.org/jira/browse/SOLR-8724
> Project: Solr
>  Issue Type: Bug
>Reporter: Steve Rowe
> Fix For: master
>
> Attachments: SOLR-8724.patch, SOLR-8724.patch, SOLR-8724.patch
>
>
> Zookeeper 3.4.8 was released a few days ago - we should upgrade.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8110) Start enforcing field naming recomendations in next X.0 release?

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-8110:
--

I've accepted the fact that Solr will probably never need to support full infix 
expressions. If somebody wants to seriously propose full infix expressions, 
fine, but it seems too much to me to worry much about vague possibilities.

Note that I am still a proponent of having quoted/escaped names which allow 
anything in names, ala SQL.

> Start enforcing field naming recomendations in next X.0 release?
> 
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> For a very long time now, Solr has made the following "recommendation" 
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only 
> and not start with a digit.  This is not currently strictly enforced, but 
> other field names will not have first class support from all components and 
> back compatibility is not guaranteed.  ...
> I'm opening this issue to track discussion about if/how we should start 
> enforcing this as a rule instead (instead of just a "recommendation") in our 
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with 
> lists of field and produce strange errors when the huerstic fails (example: 
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the 
> recommended conventions and then only later encountering a situation where 
> their field names are not supported by some feature and get frustrated 
> because they have to change their schema, reindex, update index/query client 
> expectations, etc...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 875 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/875/

All tests passed

Build Log:
[...truncated 36091 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
API invocations (in 1.64s), 1 error(s).

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:740:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:117:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build.xml:347:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/common-build.xml:504:
 Check for forbidden API calls failed, see log.

Total time: 80 minutes 31 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Created] (SOLR-8743) Data loss on shard recovery and leader election

[Matt Weber (JIRA)]

Matt Weber created SOLR-8743:


 Summary: Data loss on shard recovery and leader election
 Key: SOLR-8743
 URL: https://issues.apache.org/jira/browse/SOLR-8743
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 5.5
Reporter: Matt Weber


SolrCloud with 3 external ZK nodes in quorum, 2 data nodes (NodeA and NodeB).  
Single collection that has a single shard and a single replica (replication 
factor 2).  The primary shard is initially on NodeA and the replica on NodeB.

1.  Index Doc1 via NodeA

./solr/bin/post -c people -d '1'

2.  Shutdown NodeA, NodeB becomes the primary. Doc1 is searchable.
3.  Delete Doc1 and index Doc2 via NodeB.

./solr/bin/post -c people -d "1"
./solr/bin/post -c people -d '2'

4.  Shutdown NodeB, no nodes online.  ZK still up.
5.  Start NodeA, it remains in "down" status since NodeB is down and it was 
last seen as the primary.
6.  Start NodeB, it comes online in  "down" status.  NodeA is elected leader 
and sync starts.  Doc2 is gone, Doc1 exists in both shards.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8724) Upgrade Zookeeper to 3.4.8

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-8724:
-
Attachment: SOLR-8724.patch

{quote}
bq. If it weren't for that last item, I'd advocate for getting rid of this 
patched parseProperties() and directly calling the superclass version, catching 
the ".../myid file is missing" IllegalArgumentException, and handling setting 
the server id in the catch block.

Might not be a bad improvement - not ideal to have the MDC call, but also 
probably not very problematic.
{quote}

Yeah, the MDC call only happens when there's a myid file present, certainly not 
the case for OOTB embedded Solr ZK.

This version of the patch makes the above-described change.  Running tests now.

> Upgrade Zookeeper to 3.4.8
> --
>
> Key: SOLR-8724
> URL: https://issues.apache.org/jira/browse/SOLR-8724
> Project: Solr
>  Issue Type: Bug
>Reporter: Steve Rowe
> Fix For: master
>
> Attachments: SOLR-8724.patch, SOLR-8724.patch, SOLR-8724.patch
>
>
> Zookeeper 3.4.8 was released a few days ago - we should upgrade.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8110) Start enforcing field naming recomendations in next X.0 release?

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8110:


Dash is also problematic for unequivocal full support.  For infix arithmetic 
expressions, it's natural to expect "a - 1" to be equivalent to "a-1".

> Start enforcing field naming recomendations in next X.0 release?
> 
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> For a very long time now, Solr has made the following "recommendation" 
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only 
> and not start with a digit.  This is not currently strictly enforced, but 
> other field names will not have first class support from all components and 
> back compatibility is not guaranteed.  ...
> I'm opening this issue to track discussion about if/how we should start 
> enforcing this as a rule instead (instead of just a "recommendation") in our 
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with 
> lists of field and produce strange errors when the huerstic fails (example: 
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the 
> recommended conventions and then only later encountering a situation where 
> their field names are not supported by some feature and get frustrated 
> because they have to change their schema, reindex, update index/query client 
> expectations, etc...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-trunk-Solaris (64bit/jdk1.8.0) - Build # 431 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/431/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([E89D6B31DF326B66:1C7D00941ABFBCE]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:764)
at 
org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir(TestArbitraryIndexDir.java:107)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=*[count(//doc)=1]
xml response was: 

00


request was:q=id:2=standard=0=20=2.2
at 

[jira] [Commented] (SOLR-8722) Don't force a full ZkStateReader refresh on every Overseer operation

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-8722:
-

bq. What would you suggest in this case? Spinning for a very long time when the 
remote call might have failed quickly seems bad.

I guess the only way is to modify the processResponses method to throw an 
exception in case the async request failed just like how we do it today for 
non-async requests.

bq. What other handler methods do you think demonstrate the correct pattern?

I don't think any of them do :(

> Don't force a full ZkStateReader refresh on every Overseer operation
> 
>
> Key: SOLR-8722
> URL: https://issues.apache.org/jira/browse/SOLR-8722
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Shalin Shekhar Mangar
>  Labels: patch, performance, solrcloud
> Attachments: SOLR-8722.patch
>
>
> We're doing an unnecessary ZkStateReader forced refresh on all Overseer 
> operations.  This isn't necessary because ZkStateReader keeps itself up to 
> date.
> According to [~shalinmangar]'s analysis, we just need to put a wait loop at 
> the end of addReplica to observe the state change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8741) Json Facet API, numBuckets not returning real number of buckets.

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-8741:
-

If that's in the SolrCloud, then this is probably a duplicate of SOLR-7452

> Json Facet API, numBuckets not returning real number of buckets.
> 
>
> Key: SOLR-8741
> URL: https://issues.apache.org/jira/browse/SOLR-8741
> Project: Solr
>  Issue Type: Bug
>Reporter: Pablo Anzorena
>
> Hi, using the json facet api I realized that the numBuckets is wrong. It is 
> not returning the right number of buckets. I have a dimension which 
> numBuckets says it has 1340, but when retrieving all the results it brings 
> 988. 
> FYI the field is of type string.
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+106) - Build # 16015 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16015/
Java: 32bit/jdk-9-ea+106 -client -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 36433 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.awt.Component#getPeer() [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.awt.Font#getPeer() [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.awt.MenuComponent#getPeer() [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.awt.Toolkit#getFontPeer(java.lang.String,int) [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.jar.Pack200$Packer#addPropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.jar.Pack200$Packer#removePropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.jar.Pack200$Unpacker#addPropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.jar.Pack200$Unpacker#removePropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.logging.LogManager#addPropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.logging.LogManager#removePropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
API invocations (in 1.21s), 1 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:740: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:347: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:504: 
Check for forbidden API calls failed, see log.

Total time: 63 minutes 49 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Created] (SOLR-8742) HdfsDirectoryTest fails reliably after changes in LUCENE-6932

[Hoss Man (JIRA)]

Hoss Man created SOLR-8742:
--

 Summary: HdfsDirectoryTest fails reliably after changes in 
LUCENE-6932
 Key: SOLR-8742
 URL: https://issues.apache.org/jira/browse/SOLR-8742
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man


the following seed fails reliably for me on master...

{noformat}
   [junit4]   2> 1370568 INFO  
(TEST-HdfsDirectoryTest.testEOF-seed#[A0D22782D87E1CE2]) [] 
o.a.s.SolrTestCaseJ4 ###Ending testEOF
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=HdfsDirectoryTest 
-Dtests.method=testEOF -Dtests.seed=A0D22782D87E1CE2 -Dtests.slow=true 
-Dtests.locale=es-PR -Dtests.timezone=Indian/Mauritius -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.13s J0 | HdfsDirectoryTest.testEOF <<<
   [junit4]> Throwable #1: java.lang.NullPointerException
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([A0D22782D87E1CE2:31B9658A9A5ABA9E]:0)
   [junit4]>at 
org.apache.lucene.store.RAMInputStream.readByte(RAMInputStream.java:69)
   [junit4]>at 
org.apache.solr.store.hdfs.HdfsDirectoryTest.testEof(HdfsDirectoryTest.java:159)
   [junit4]>at 
org.apache.solr.store.hdfs.HdfsDirectoryTest.testEOF(HdfsDirectoryTest.java:151)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
{noformat}

git bisect says this is the first commit where it started failing..

{noformat}
ddc65d977f920013c5fca16c8ac75ae2c6895f9d is the first bad commit
commit ddc65d977f920013c5fca16c8ac75ae2c6895f9d
Author: Michael McCandless 
Date:   Thu Jan 21 17:50:28 2016 +

LUCENE-6932: RAMInputStream now throws EOFException if you seek beyond the 
end of the file

git-svn-id: https://svn.apache.org/repos/asf/lucene/dev/trunk@1726039 
13f79535-47bb-0310-9956-ffa450edef68

{noformat}

...which seems remarkable relevant and likely to indicate a problem that needs 
fixed in the HdfsDirectory code (or perhaps just the test)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 874 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/874/

All tests passed

Build Log:
[...truncated 36086 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
API invocations (in 1.48s), 1 error(s).

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:740:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:117:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build.xml:347:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/common-build.xml:504:
 Check for forbidden API calls failed, see log.

Total time: 69 minutes 34 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_72) - Build # 16008 - Still Failing!

[Chris Hostetter]

Hmmm... for me, i haven't been able to reproduce these seeds since trying 
"ant clean-jars" ... aren't the jenkins builds already doing that?




: Date: Fri, 26 Feb 2016 14:42:20 -0700 (MST)
: From: Chris Hostetter 
: To: Lucene Dev 
: Subject: Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_72) - Build #
: 16008 - Still Failing!
: 
: 
: : Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16008/
: : Java: 32bit/jdk1.8.0_72 -server -XX:+UseConcMarkSweepGC
: 
: I'm seeing some (very) reproducible failures similar to these -- the root 
: causes cases coming from NPEs from IOUtils.copyLarge ...
: 
: org.apache.solr.cloud.CollectionStateFormat2Test.test
: org.apache.solr.cloud.TestCryptoKeys.test
: org.apache.solr.core.TestDynamicLoading.testDynamicLoading
: org.apache.solr.handler.TestBlobHandler.doBlobHandlerTest
: org.apache.solr.update.processor.TestNamedUpdateProcessors.test
: 
: what changed here, and what do these tests have in common ???
: 
: Seeds that failed for me locally...
: 
: 
: 
:[junit4]   2> NOTE: reproduce with: ant test  
: -Dtestcase=TestBlobHandler -Dtests.method=doBlobHandlerTest 
: -Dtests.seed=A0D22782D87E1CE2 -Dtests.slow=true -Dtests.locale=vi 
: -Dtests.timezone=Africa/Gaborone -Dtests.asserts=true 
: -Dtests.file.encoding=ISO-8859-1
:[junit4] ERROR   20.6s J2 | TestBlobHandler.doBlobHandlerTest <<<
:[junit4]> Throwable #1: 
: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
: Error from server at http://127.0.0.1:43795: 
: java.lang.NullPointerException
:[junit4]>  at 
: org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1792)
:[junit4]>  at 
: org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1769)
:[junit4]>  at 
: org.apache.commons.io.IOUtils.copy(IOUtils.java:1744)
:[junit4]>  at 
: org.apache.commons.io.IOUtils.toByteArray(IOUtils.java:462)
:[junit4]>  at 
: 
org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation$1.createSysConfigSet(CollectionsHandler.java:385)
: 
: 
: 
: 
:[junit4]   2> NOTE: reproduce with: ant test  
: -Dtestcase=TestDynamicLoading -Dtests.method=testDynamicLoading 
: -Dtests.seed=A0D22782D87E1CE2 -Dtests.slow=true -Dtests.locale=fi-FI 
: -Dtests.timezone=Indian/Christmas -Dtests.asserts=true 
: -Dtests.file.encoding=ISO-8859-1
:[junit4] ERROR   22.3s J0 | TestDynamicLoading.testDynamicLoading <<<
:[junit4]> Throwable #1: 
: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
: Error from server at http://127.0.0.1:43757/i/q: 
: java.lang.NullPointerException
:[junit4]>  at 
: org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1792)
:[junit4]>  at 
: org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1769)
:[junit4]>  at 
: org.apache.commons.io.IOUtils.copy(IOUtils.java:1744)
:[junit4]>  at 
: org.apache.commons.io.IOUtils.toByteArray(IOUtils.java:462)
:[junit4]>  at 
: 
org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation$1.createSysConfigSet(CollectionsHandler.java:385)
:[junit4]>  at 
: 
org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation$1.call(CollectionsHandler.java:366)
:[junit4]>  at 
: 
org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:188)
:[junit4]>  at 
: 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
:[junit4]>  at 
: org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:655)
:[junit4]>  at 
: org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:438)
:[junit4]>  at 
: 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
:[junit4]>  at 
: 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
: 
: 
: 
:[junit4]   2> NOTE: reproduce with: ant test  
: -Dtestcase=CollectionStateFormat2Test -Dtests.method=test 
: -Dtests.seed=A0D22782D87E1CE2 -Dtests.slow=true -Dtests.locale=lt-LT 
: -Dtests.timezone=SystemV/YST9YDT -Dtests.asserts=true 
: -Dtests.file.encoding=ISO-8859-1
:[junit4] ERROR   28.6s J2 | CollectionStateFormat2Test.test <<<
:[junit4]> Throwable #1: 
: org.apache.solr.client.solrj.SolrServerException: No live SolrServers 
: available to handle this request:[http://127.0.0.1:53761, 
: http://127.0.0.1:57816, http://127.0.0.1:60992, http://127.0.0.1:55172, 
: http://127.0.0.1:59845]
:[junit4]>  at 
: __randomizedtesting.SeedInfo.seed([A0D22782D87E1CE2:288618587682711A]:0)
:[junit4]>  at 
: 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
:[junit4]>  at 
: 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
:[junit4]>  

[jira] [Updated] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-7339:
--
Priority: Blocker  (was: Major)

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Mark Miller
>Priority: Blocker
> Fix For: master
>
> Attachments: SOLR-7339-revert.patch, SOLR-7339.patch, 
> SOLR-7339.patch, SOLR-7339.patch, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7339:
---

Looks like I may have to back this out again for the 6.0 release.

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-7339-revert.patch, SOLR-7339.patch, 
> SOLR-7339.patch, SOLR-7339.patch, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-8725) Cores, collections, and shards should accept hyphens in identifier name

[Anshum Gupta (JIRA)]

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

Anshum Gupta reassigned SOLR-8725:
--

Assignee: Anshum Gupta

> Cores, collections, and shards should accept hyphens in identifier name
> ---
>
> Key: SOLR-8725
> URL: https://issues.apache.org/jira/browse/SOLR-8725
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5
>Reporter: Chris Beer
>Assignee: Anshum Gupta
> Attachments: SOLR-8725.patch
>
>
> In SOLR-8642, hyphens are no longer considered valid identifiers for cores 
> (and collections?). Our solr instance was successfully using hyphens in our 
> core names, and our affected cores now error with:
> marc-profiler_shard1_replica1: 
> org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist 
> entirely of periods, underscores and alphanumerics
> Before starting to rename all of our collections, I wonder if this decision 
> could be revisited to be backwards compatible with previously created 
> collections.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8725) Cores, collections, and shards should accept hyphens in identifier name

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8725:
---
Attachment: SOLR-8725.patch

Patch without tests. Will add them in a bit and commit.
This allows hyphens in the name but not as the first char.

> Cores, collections, and shards should accept hyphens in identifier name
> ---
>
> Key: SOLR-8725
> URL: https://issues.apache.org/jira/browse/SOLR-8725
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5
>Reporter: Chris Beer
> Attachments: SOLR-8725.patch
>
>
> In SOLR-8642, hyphens are no longer considered valid identifiers for cores 
> (and collections?). Our solr instance was successfully using hyphens in our 
> core names, and our affected cores now error with:
> marc-profiler_shard1_replica1: 
> org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist 
> entirely of periods, underscores and alphanumerics
> Before starting to rename all of our collections, I wonder if this decision 
> could be revisited to be backwards compatible with previously created 
> collections.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8725) Cores, collections, and shards should accept hyphens in identifier name

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8725:
---
Summary: Cores, collections, and shards should accept hyphens in identifier 
name  (was: Invalid name error with core names with hyphens)

> Cores, collections, and shards should accept hyphens in identifier name
> ---
>
> Key: SOLR-8725
> URL: https://issues.apache.org/jira/browse/SOLR-8725
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5
>Reporter: Chris Beer
>
> In SOLR-8642, hyphens are no longer considered valid identifiers for cores 
> (and collections?). Our solr instance was successfully using hyphens in our 
> core names, and our affected cores now error with:
> marc-profiler_shard1_replica1: 
> org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist 
> entirely of periods, underscores and alphanumerics
> Before starting to rename all of our collections, I wonder if this decision 
> could be revisited to be backwards compatible with previously created 
> collections.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_72) - Build # 16008 - Still Failing!

[Chris Hostetter]

: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16008/
: Java: 32bit/jdk1.8.0_72 -server -XX:+UseConcMarkSweepGC

I'm seeing some (very) reproducible failures similar to these -- the root 
causes cases coming from NPEs from IOUtils.copyLarge ...

org.apache.solr.cloud.CollectionStateFormat2Test.test
org.apache.solr.cloud.TestCryptoKeys.test
org.apache.solr.core.TestDynamicLoading.testDynamicLoading
org.apache.solr.handler.TestBlobHandler.doBlobHandlerTest
org.apache.solr.update.processor.TestNamedUpdateProcessors.test

what changed here, and what do these tests have in common ???

Seeds that failed for me locally...



   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestBlobHandler -Dtests.method=doBlobHandlerTest 
-Dtests.seed=A0D22782D87E1CE2 -Dtests.slow=true -Dtests.locale=vi 
-Dtests.timezone=Africa/Gaborone -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   20.6s J2 | TestBlobHandler.doBlobHandlerTest <<<
   [junit4]> Throwable #1: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
Error from server at http://127.0.0.1:43795: 
java.lang.NullPointerException
   [junit4]>at 
org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1792)
   [junit4]>at 
org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1769)
   [junit4]>at 
org.apache.commons.io.IOUtils.copy(IOUtils.java:1744)
   [junit4]>at 
org.apache.commons.io.IOUtils.toByteArray(IOUtils.java:462)
   [junit4]>at 
org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation$1.createSysConfigSet(CollectionsHandler.java:385)




   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestDynamicLoading -Dtests.method=testDynamicLoading 
-Dtests.seed=A0D22782D87E1CE2 -Dtests.slow=true -Dtests.locale=fi-FI 
-Dtests.timezone=Indian/Christmas -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   22.3s J0 | TestDynamicLoading.testDynamicLoading <<<
   [junit4]> Throwable #1: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
Error from server at http://127.0.0.1:43757/i/q: 
java.lang.NullPointerException
   [junit4]>at 
org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1792)
   [junit4]>at 
org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1769)
   [junit4]>at 
org.apache.commons.io.IOUtils.copy(IOUtils.java:1744)
   [junit4]>at 
org.apache.commons.io.IOUtils.toByteArray(IOUtils.java:462)
   [junit4]>at 
org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation$1.createSysConfigSet(CollectionsHandler.java:385)
   [junit4]>at 
org.apache.solr.handler.admin.CollectionsHandler$CollectionOperation$1.call(CollectionsHandler.java:366)
   [junit4]>at 
org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:188)
   [junit4]>at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
   [junit4]>at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:655)
   [junit4]>at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:438)
   [junit4]>at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
   [junit4]>at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)



   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=CollectionStateFormat2Test -Dtests.method=test 
-Dtests.seed=A0D22782D87E1CE2 -Dtests.slow=true -Dtests.locale=lt-LT 
-Dtests.timezone=SystemV/YST9YDT -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   28.6s J2 | CollectionStateFormat2Test.test <<<
   [junit4]> Throwable #1: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers 
available to handle this request:[http://127.0.0.1:53761, 
http://127.0.0.1:57816, http://127.0.0.1:60992, http://127.0.0.1:55172, 
http://127.0.0.1:59845]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([A0D22782D87E1CE2:288618587682711A]:0)
   [junit4]>at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
   [junit4]>at 
org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:15




   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestNamedUpdateProcessors 

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 873 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/873/

All tests passed

Build Log:
[...truncated 36085 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
API invocations (in 1.62s), 1 error(s).

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:740:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:117:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build.xml:347:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/common-build.xml:504:
 Check for forbidden API calls failed, see log.

Total time: 73 minutes 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[JENKINS-EA] Lucene-Solr-5.5-Linux (64bit/jdk-9-ea+106) - Build # 132 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/132/
Java: 64bit/jdk-9-ea+106 -XX:-UseCompressedOops -XX:+UseSerialGC

6 tests failed.
FAILED:  org.apache.lucene.search.TestPrefixRandom.testPrefixes

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([4F8366A723D0AD1C:1D570AAEDA65A1B5]:0)
at 
org.apache.lucene.search.BooleanScorer.scoreWindowIntoBitSetAndReplay(BooleanScorer.java:218)
at 
org.apache.lucene.search.BooleanScorer.scoreWindowMultipleScorers(BooleanScorer.java:266)
at 
org.apache.lucene.search.BooleanScorer.scoreWindow(BooleanScorer.java:311)
at org.apache.lucene.search.BooleanScorer.score(BooleanScorer.java:335)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
at 
org.apache.lucene.search.LRUQueryCache.cacheImpl(LRUQueryCache.java:422)
at 
org.apache.lucene.search.LRUQueryCache$CachingWrapperWeight.cache(LRUQueryCache.java:608)
at 
org.apache.lucene.search.LRUQueryCache$CachingWrapperWeight.bulkScorer(LRUQueryCache.java:652)
at 
org.apache.lucene.search.AssertingWeight.bulkScorer(AssertingWeight.java:68)
at 
org.apache.lucene.search.ConstantScoreQuery$1.bulkScorer(ConstantScoreQuery.java:125)
at 
org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.bulkScorer(MultiTermQueryConstantScoreWrapper.java:201)
at 
org.apache.lucene.search.AssertingWeight.bulkScorer(AssertingWeight.java:68)
at 
org.apache.lucene.search.AssertingWeight.bulkScorer(AssertingWeight.java:68)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:818)
at 
org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:91)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:535)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:744)
at 
org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:460)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:489)
at 
org.apache.lucene.search.TestPrefixRandom.assertSame(TestPrefixRandom.java:135)
at 
org.apache.lucene.search.TestPrefixRandom.testPrefixes(TestPrefixRandom.java:125)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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)

[jira] [Commented] (SOLR-8110) Start enforcing field naming recomendations in next X.0 release?

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-8110:
--

Dot is a tough case. I can see reserving it for future expansion, but I can 
also see its utility in field names where its value is based on using it as a 
pseudo-field delimiter, such as in cases where data may in fact have come from 
an SQL ETL operation that actually did use the dot as a compound field name.

How about... saying that dot is pseudo-reserved for compound field name 
references, and if the decomposed field name has a well-defined meaning in some 
context, such as where there are contextual named structural entities, such as 
table or collection names, then so be it, but if it has no clear meaning in a 
context, then the full, dotted name will be treated as a raw field name? So, at 
the level of the fl parameter a dotted name would get parsed as a compound name 
and then treated as a simple field name.

> Start enforcing field naming recomendations in next X.0 release?
> 
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Attachments: SOLR-8110.patch, SOLR-8110.patch
>
>
> For a very long time now, Solr has made the following "recommendation" 
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only 
> and not start with a digit.  This is not currently strictly enforced, but 
> other field names will not have first class support from all components and 
> back compatibility is not guaranteed.  ...
> I'm opening this issue to track discussion about if/how we should start 
> enforcing this as a rule instead (instead of just a "recommendation") in our 
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with 
> lists of field and produce strange errors when the huerstic fails (example: 
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the 
> recommended conventions and then only later encountering a situation where 
> their field names are not supported by some feature and get frustrated 
> because they have to change their schema, reindex, update index/query client 
> expectations, etc...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8713) New UI points to the wiki for Query Syntax instead of the Reference Guide

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8713:


bq. points towards Solr 4.x wiki

The moinmoin wiki is *not* for 4.x.  A lot of the content has gotten out of 
date, but other parts of it are updated regularly and have fully current 
information.

That older wiki needs an overhaul.  Some of the information needs to be removed 
because the information in the reference guide is better and completely 
supersedes what's there now, but there is still some value in having duplicate 
information for certain topics, because the wiki version can be presented 
differently, in a format that's better for quick lookups than the reference 
guide, which is intended to be full documentation.  A good example of this is 
the following page:

https://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters

I use this page all the time, because it's easily searchable for a particular 
analysis component and has quick-n-dirty examples.  I don't recall seeing 
anything in the reference guide like that page.


> New UI points to the wiki for Query Syntax instead of the Reference Guide
> -
>
> Key: SOLR-8713
> URL: https://issues.apache.org/jira/browse/SOLR-8713
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: master
>Reporter: Tomás Fernández Löbbe
>Priority: Trivial
>  Labels: newdev
>
> Old Admin UI points to 
> https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing but 
> the new one points to http://wiki.apache.org/solr/SolrQuerySyntax



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_72) - Build # 16014 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16014/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 36095 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
API invocations (in 1.14s), 1 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:740: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:347: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:504: 
Check for forbidden API calls failed, see log.

Total time: 58 minutes 29 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Updated] (SOLR-8722) Don't force a full ZkStateReader refresh on every Overseer operation

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-8722:
--
Assignee: Shalin Shekhar Mangar  (was: Mark Miller)

> Don't force a full ZkStateReader refresh on every Overseer operation
> 
>
> Key: SOLR-8722
> URL: https://issues.apache.org/jira/browse/SOLR-8722
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Shalin Shekhar Mangar
>  Labels: patch, performance, solrcloud
> Attachments: SOLR-8722.patch
>
>
> We're doing an unnecessary ZkStateReader forced refresh on all Overseer 
> operations.  This isn't necessary because ZkStateReader keeps itself up to 
> date.
> According to [~shalinmangar]'s analysis, we just need to put a wait loop at 
> the end of addReplica to observe the state change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8725) Invalid name error with core names with hyphens

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8725:


After discussions on other JIRAs mentioned above, I'll add the hypen to the 
allowed char list and an added check to make sure that it's not the first char 
when naming a core, collection, shard etc.

> Invalid name error with core names with hyphens
> ---
>
> Key: SOLR-8725
> URL: https://issues.apache.org/jira/browse/SOLR-8725
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5
>Reporter: Chris Beer
>
> In SOLR-8642, hyphens are no longer considered valid identifiers for cores 
> (and collections?). Our solr instance was successfully using hyphens in our 
> core names, and our affected cores now error with:
> marc-profiler_shard1_replica1: 
> org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist 
> entirely of periods, underscores and alphanumerics
> Before starting to rename all of our collections, I wonder if this decision 
> could be revisited to be backwards compatible with previously created 
> collections.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8497) Merge index does not mark the Directories it creates as 'done' and they are retained in the Directory cache.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-8497:
---

Commit 54e7bb5f58931cef9ead049313804c2b9a10ce88 in lucene-solr's branch 
refs/heads/master from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=54e7bb5 ]

SOLR-8497: Only mark diectory as done if it was not previously in the cache.


> Merge index does not mark the Directories it creates as 'done' and they are 
> retained in the Directory cache.
> 
>
> Key: SOLR-8497
> URL: https://issues.apache.org/jira/browse/SOLR-8497
> Project: Solr
>  Issue Type: Bug
>  Components: Hadoop Integration, SolrCloud
>Affects Versions: 4.10.3
> Environment: Cloudera Search (CDH 5.4.5 Solr 4.10.3)
>Reporter: Sivlio Sanchez
>Assignee: Mark Miller
>Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8497.patch
>
>
> After a Merge Indexes, the input directories on HDFS do not get closed (only 
> released by the CachingDirectoryFactory). This causes the 
> HDFSLocalityReporter to continue monitoring the input directories even after 
> they are cleaned up/deleted. This results in a large volume of logged 
> warnings on the Solr node.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-8497) Merge index does not mark the Directories it creates as 'done' and they are retained in the Directory cache.

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-8497.
---
Resolution: Fixed

> Merge index does not mark the Directories it creates as 'done' and they are 
> retained in the Directory cache.
> 
>
> Key: SOLR-8497
> URL: https://issues.apache.org/jira/browse/SOLR-8497
> Project: Solr
>  Issue Type: Bug
>  Components: Hadoop Integration, SolrCloud
>Affects Versions: 4.10.3
> Environment: Cloudera Search (CDH 5.4.5 Solr 4.10.3)
>Reporter: Sivlio Sanchez
>Assignee: Mark Miller
>Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8497.patch
>
>
> After a Merge Indexes, the input directories on HDFS do not get closed (only 
> released by the CachingDirectoryFactory). This causes the 
> HDFSLocalityReporter to continue monitoring the input directories even after 
> they are cleaned up/deleted. This results in a large volume of logged 
> warnings on the Solr node.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 3113 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/3113/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 16 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: 
org.eclipse.jgit.api.errors.TransportException: Connection reset
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:639)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to MacOSX VBOX(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
at hudson.remoting.Channel.call(Channel.java:781)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor685.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at com.sun.proxy.$Proxy67.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:764)
... 11 more
Caused by: org.eclipse.jgit.api.errors.TransportException: Connection reset
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:637)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.eclipse.jgit.errors.TransportException: Connection reset
at 
org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefs(BasePackConnection.java:182)
at 
org.eclipse.jgit.transport.TransportGitAnon$TcpFetchConnection.(TransportGitAnon.java:194)
at 
org.eclipse.jgit.transport.TransportGitAnon.openFetch(TransportGitAnon.java:120)
at 
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
at 
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
... 11 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at 

Re: Zookeeper and Solr Clients

[Upayavira]

Perfect. So, if when I want to find a node to talk to, I do: * locate
state.json or clusterstate.json * identify a suitable node * confirm the
node is life, and if not repeat from previous step

Then I should be good.

Upayavira


On Fri, Feb 26, 2016, at 08:32 PM, Mark Miller wrote:
> Right, clusterstate.json is never used by itself to determine a
> replica's state. It's always, is it live? Then find it's state in
> clusterstate.json. If it's not live, the state can be anything in
> clusterstate.json and should be ignored.
>
> We make some best efforts to keep it up to date, but it should not be
> counted on (and can't always be counted on), and the above logic is
> how all Solr code reads state.
>
> - Mark
>
> On Fri, Feb 26, 2016 at 2:13 PM Scott Blum
>  wrote:
>> Published cluster state always lags.  And if a solr node crashes, the
>> status on affected replicas won't actually change until the owning
>> instances tries to come back up.  If you're working on a generally
>> reusable library, you'd want to also watch live_nodes.
>>
>> On Fri, Feb 26, 2016 at 5:23 AM, Upayavira  wrote:
>>> This is for making a ZK aware Pysolr client (i.e. Python equiv
>>> of SolrJ
>>>
CloudSolrClient). It clearly needs to watch ZK to be able to update the
>>>
list of hosts that make up a collection. We can't use the API, because
>>>
we don't yet know where the Solr nodes are!
>>>
>>>
Upayavira
>>>
>>>
On Fri, Feb 26, 2016, at 09:09 AM, Noble Paul wrote:
>>>
> why do you need to watch anything? you can get the whole clusterstate
>>>
> using the API. ZK access is not required
>>>
>
>>>
> On Thu, Feb 25, 2016 at 9:42 PM, Upayavira  wrote:
>>>
> > I've recently had a patch merged into Pysolr that adds ZK awareness
>>>
> > (compatible with custerstate.json). Now I need to update it to be
>>>
> > compatible with the newer state.json, and I just wanted to
> > confirm my
>>>
> > understanding
>>>
> >
>>>
> > If we create a Python 'client' that is tied to a specific
> > collection,
>>>
> > then all I need to do is set up a watch on
>>>
> > /collections/${collection}/state.json, and update the list of nodes
>>>
> > accordingly (as I would have on a watch on clusterstate.json) when
>>>
> > state.json changes.
>>>
> >
>>>
> > There's a lot more that *could* be done, but for the basics,
> > it seems
>>>
> > that's enough.
>>>
> >
>>>
> > Is it really this simple?
>>>
> >
>>>
> > Upayavira
>>>
> >
>>>
> > ---
> > --
>>>
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
> >
>>>
>
>>>
>
>>>
>
>>>
> --
>>>
> -
>>>
> Noble Paul
>>>
>
>>>
> -
>>>
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>
> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>
>>>
>>>
-
>>>
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>
For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
> --
> - Mark about.me/markrmiller

Re: Zookeeper and Solr Clients

[Mark Miller]

Right, clusterstate.json is never used by itself to determine a replica's
state. It's always, is it live? Then find it's state in clusterstate.json.
If it's not live, the state can be anything in clusterstate.json and should
be ignored.

We make some best efforts to keep it up to date, but it should not be
counted on (and can't always be counted on), and the above logic is how all
Solr code reads state.

- Mark

On Fri, Feb 26, 2016 at 2:13 PM Scott Blum  wrote:

> Published cluster state always lags.  And if a solr node crashes, the
> status on affected replicas won't actually change until the owning
> instances tries to come back up.  If you're working on a generally reusable
> library, you'd want to also watch live_nodes.
>
> On Fri, Feb 26, 2016 at 5:23 AM, Upayavira  wrote:
>
>> This is for making a ZK aware Pysolr client (i.e. Python equiv of SolrJ
>> CloudSolrClient). It clearly needs to watch ZK to be able to update the
>> list of hosts that make up a collection. We can't use the API, because
>> we don't yet know where the Solr nodes are!
>>
>> Upayavira
>>
>> On Fri, Feb 26, 2016, at 09:09 AM, Noble Paul wrote:
>> > why do you need to watch anything? you can get the whole clusterstate
>> > using the API. ZK access is not required
>> >
>> > On Thu, Feb 25, 2016 at 9:42 PM, Upayavira  wrote:
>> > > I've recently had a patch merged into Pysolr that adds ZK awareness
>> > > (compatible with custerstate.json). Now I need to update it to be
>> > > compatible with the newer state.json, and I just wanted to confirm my
>> > > understanding
>> > >
>> > > If we create a Python 'client' that is tied to a specific collection,
>> > > then all I need to do is set up a watch on
>> > > /collections/${collection}/state.json, and update the list of nodes
>> > > accordingly (as I would have on a watch on clusterstate.json) when
>> > > state.json changes.
>> > >
>> > > There's a lot more that *could* be done, but for the basics, it seems
>> > > that's enough.
>> > >
>> > > Is it really this simple?
>> > >
>> > > Upayavira
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > > For additional commands, e-mail: dev-h...@lucene.apache.org
>> > >
>> >
>> >
>> >
>> > --
>> > -
>> > Noble Paul
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
> --
- Mark
about.me/markrmiller

[jira] [Commented] (SOLR-8713) New UI points to the wiki for Query Syntax instead of the Reference Guide

[Marius Grama (JIRA)]

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

Marius Grama commented on SOLR-8713:


[~jkrupan] thank you for the feedback.
I agree with what you are saying that the wiki page may be misleading pointing 
towards the NEXT version of Solr (6.0 now), but I see the link "5.5 Ref Guide 
(PDF Download)" referenced in the wiki page. Also the solr ref guide PDF 
provides not only query syntax help, but is the full reference guide for Solr. 
In case that the link would point towards this PDF, the name of the link would 
need to be changed to "Solr Reference Guide".
Nevertheless, the current link http://wiki.apache.org/solr/SolrQuerySyntax 
points towards  Solr 4.x wiki. The solr query syntax link was until recently 
pointing towards to the 
https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing (from 
admin.html ) webpage. IMO the link should still point to the confluence query 
link.

bq. It would be nice if the Confluence doc was per-release in addition to the 
development version
I guess the reason why there is only the one (latest) version of the document 
present in the wiki, is to avoid the duplication of maintenance.

> New UI points to the wiki for Query Syntax instead of the Reference Guide
> -
>
> Key: SOLR-8713
> URL: https://issues.apache.org/jira/browse/SOLR-8713
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: master
>Reporter: Tomás Fernández Löbbe
>Priority: Trivial
>  Labels: newdev
>
> Old Admin UI points to 
> https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing but 
> the new one points to http://wiki.apache.org/solr/SolrQuerySyntax



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8713) New UI points to the wiki for Query Syntax instead of the Reference Guide

[JIRA]

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

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

That's true, but the same thing happens with the wiki (yes, sometimes we put 
things like "Only since 4.0" there, but anyway). I think pointing to the right 
page in Confluence is good enough, specially since that's what we are currently 
doing in the deprecated UI. I wouldn't like pointing to the PDF

> New UI points to the wiki for Query Syntax instead of the Reference Guide
> -
>
> Key: SOLR-8713
> URL: https://issues.apache.org/jira/browse/SOLR-8713
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: master
>Reporter: Tomás Fernández Löbbe
>Priority: Trivial
>  Labels: newdev
>
> Old Admin UI points to 
> https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing but 
> the new one points to http://wiki.apache.org/solr/SolrQuerySyntax



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8724) Upgrade Zookeeper to 3.4.8

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8724:
---

+1, LGTM.

bq. If it weren't for that last item, I'd advocate for getting rid of this 
patched parseProperties() and directly calling the superclass version, catching 
the ".../myid file is missing" IllegalArgumentException, and handling setting 
the server id in the catch block.

Might not be a bad improvement - not ideal to have the MDC call, but also 
probably not very problematic.

> Upgrade Zookeeper to 3.4.8
> --
>
> Key: SOLR-8724
> URL: https://issues.apache.org/jira/browse/SOLR-8724
> Project: Solr
>  Issue Type: Bug
>Reporter: Steve Rowe
> Fix For: master
>
> Attachments: SOLR-8724.patch, SOLR-8724.patch
>
>
> Zookeeper 3.4.8 was released a few days ago - we should upgrade.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8713) New UI points to the wiki for Query Syntax instead of the Reference Guide

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-8713:
--

Be careful, because Confluence has the working text of the NEXT release of Solr 
(6.0 right now), not the current release or even necessarily the release that 
the admin UI is running.

It would be nice if the Confluence doc was per-release in addition to the 
development version, but right now only the PDF is per-release, which is what 
the admin UI should point to.


> New UI points to the wiki for Query Syntax instead of the Reference Guide
> -
>
> Key: SOLR-8713
> URL: https://issues.apache.org/jira/browse/SOLR-8713
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: master
>Reporter: Tomás Fernández Löbbe
>Priority: Trivial
>  Labels: newdev
>
> Old Admin UI points to 
> https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing but 
> the new one points to http://wiki.apache.org/solr/SolrQuerySyntax



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8713) New UI points to the wiki for Query Syntax instead of the Reference Guide

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8713:
--

GitHub user mariusneo opened a pull request:

https://github.com/apache/lucene-solr/pull/14

SOLR-8713 Update wiki-query-syntax link

Update wiki-query-syntax link to point towards : 
https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing


Along the way I've updated the Solr query syntax link also within several 
solrconfig.xml files.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mariusneo/lucene-solr bugfix/SOLR-8713

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/14.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #14


commit 9f5e4768a772b4375c5979dd61a440504bfdceb0
Author: Marius 
Date:   2016-02-26T19:15:14Z

SOLR-8713 Update wiki-query-syntax link to point towards : 
https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing




> New UI points to the wiki for Query Syntax instead of the Reference Guide
> -
>
> Key: SOLR-8713
> URL: https://issues.apache.org/jira/browse/SOLR-8713
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: master
>Reporter: Tomás Fernández Löbbe
>Priority: Trivial
>  Labels: newdev
>
> Old Admin UI points to 
> https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing but 
> the new one points to http://wiki.apache.org/solr/SolrQuerySyntax



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr pull request: SOLR-8713 Update wiki-query-syntax link

[mariusneo]

GitHub user mariusneo opened a pull request:

https://github.com/apache/lucene-solr/pull/14

SOLR-8713 Update wiki-query-syntax link

Update wiki-query-syntax link to point towards : 
https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing


Along the way I've updated the Solr query syntax link also within several 
solrconfig.xml files.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mariusneo/lucene-solr bugfix/SOLR-8713

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/14.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #14


commit 9f5e4768a772b4375c5979dd61a440504bfdceb0
Author: Marius 
Date:   2016-02-26T19:15:14Z

SOLR-8713 Update wiki-query-syntax link to point towards : 
https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (LUCENE-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6993:
-

Yeah its tricky. I kinda view classictokenizer as a tokenizer for the 
ignorant... its got tons of bogus western only assumptions and is basically 
wrong in every possible way. But arguing with this is like arguing with donald 
trump, so better to give folks like this their own dedicated crappy tokenizer 
and keep them off our back. From this perspective, it can be wired to unicode 
1.0 and it serves its intended purpose.

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch, LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr pull request: Inherit SOLR_LOGS_DIR from environment

[demiankatz]

GitHub user demiankatz opened a pull request:

https://github.com/apache/lucene-solr/pull/13

Inherit SOLR_LOGS_DIR from environment

It is sometimes useful to override SOLR_LOGS_DIR from within a wrapping 
script; these changes make it possible while maintaining existing defaults.

(This behavior already exists in the Linux shell script; this PR adds 
equivalent behavior to the Windows wrapper).

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/demiankatz/lucene-solr-1 patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/13.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #13


commit 209179891b33eee39219c648dcd2171f9b7789d8
Author: Demian Katz 
Date:   2016-02-26T19:53:16Z

Inherit SOLR_LOGS_DIR from environment

It is sometimes useful to override SOLR_LOGS_DIR from within a wrapping 
script; these changes make it possible while maintaining existing defaults.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 872 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/872/

All tests passed

Build Log:
[...truncated 36082 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
API invocations (in 1.76s), 1 error(s).

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:740:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:117:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build.xml:347:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/common-build.xml:504:
 Check for forbidden API calls failed, see log.

Total time: 73 minutes 30 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Comment Edited] (LUCENE-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on LUCENE-6993 at 2/26/16 7:41 PM:
-

{{ClassicTokenizer}} does have direct Unicode version dependencies: 
{{\[:digit:]}} and {{\[:alpha:]}} are the equivalent of {{\p\{Digit} and 
\p\{Letter},}} respectively.  Right now those definitions are pinned at Unicode 
3.0, which means that characters added since Unicode 3.0 (released 15 years 
ago, in 2000) will not be properly tokenized.

Also, there are several effectively-pinned character sets (for CJK and Thai) 
that are hard-coded in the grammar, and don't include any supplementary 
characters at all.  If the Unicode version changes, these will need to be moved 
to use the appropriate Unicode properties instead.

I guess I'm -0 on leaving the Unicode version as-is because of the above, but 
since this tokenizer will never be removed, it seems bad to me to keep it 
pinned to such an old Unicode version.


was (Author: steve_rowe):
{{ClassicTokenizer}} does have direct Unicode version dependencies: 
{{\[:digit:]}} and {{\[:alpha:]}} are the equivalent of {{\p\{Digit} and 
\p\{Letter},}} respectively.  Right now those definitions are pinned at Unicode 
3.0, which means that characters added since Unicode 3.0 (released 15 years 
ago, in 2000) will not be properly tokenized.

Also, there are several effectively-pinned character sets (for CJK) that are 
hard-coded in the grammar, and don't include any supplementary characters at 
all.  If the Unicode version changes, these will need to be moved to use the 
appropriate Unicode properties instead.

I guess I'm -0 on leaving the Unicode version as-is because of the above, but 
since this tokenizer will never be removed, it seems bad to me to keep it 
pinned to such an old Unicode version.

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch, LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-6993:


{{ClassicTokenizer}} does have direct Unicode version dependencies: 
{{\[:digit:]}} and {{\[:alpha:]}} are the equivalent of {{\p\{Digit} and 
\p\{Letter},}} respectively.  Right now those definitions are pinned at Unicode 
3.0, which means that characters added since Unicode 3.0 (released 15 years 
ago, in 2000) will not be properly tokenized.

Also, there are several effectively-pinned character sets (for CJK) that are 
hard-coded in the grammar, and don't include any supplementary characters at 
all.  If the Unicode version changes, these will need to be moved to use the 
appropriate Unicode properties instead.

I guess I'm -0 on leaving the Unicode version as-is because of the above, but 
since this tokenizer will never be removed, it seems bad to me to keep it 
pinned to such an old Unicode version.

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch, LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8459) NPE using TermVectorComponent in combinition with ExactStatsCache

[Andreas Daffner (JIRA)]

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

Andreas Daffner commented on SOLR-8459:
---

Hello,

is it possible to make first re-tests with these 3 patches?

> NPE using TermVectorComponent in combinition with ExactStatsCache
> -
>
> Key: SOLR-8459
> URL: https://issues.apache.org/jira/browse/SOLR-8459
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Andreas Daffner
>Assignee: Varun Thacker
> Fix For: 5.5, master
>
> Attachments: SOLR-8459.patch, SOLR-8459.patch, SOLR-8459.patch
>
>
> Hello,
> I am getting a NPE when using the TermVectorComponent in combinition with 
> ExactStatsCache.
> I am using SOLR 5.3.0 with 4 shards in total.
> I set up my solrconfig.xml as described in these 2 links:
> TermVectorComponent:
> https://cwiki.apache.org/confluence/display/solr/The+Term+Vector+Component
> ExactStatsCache:
> https://cwiki.apache.org/confluence/display/solr/Distributed+Requests#Configuring+statsCache+implementation
> My snippets from solrconfig.xml:
> {code}
> ...
>   
>   
>   
>class="org.apache.solr.handler.component.TermVectorComponent"/>
>class="org.apache.solr.handler.component.SearchHandler">
> 
>   true
> 
> 
>   tvComponent
> 
>   
> ...
> {code}
> Unfortunately a request to SOLR like 
> "http://host/solr/corename/tvrh?q=site_url_id:74; ends up with this NPE:
> {code}
> 4329458 ERROR (qtp59559151-17) [c:SingleDomainSite_11 s:shard1 r:core_node1 
> x:SingleDomainSite_11_shard1_replica1] o.a.s.c.SolrCore 
> java.lang.NullPointerException
>   at 
> org.apache.solr.handler.component.TermVectorComponent.finishStage(TermVectorComponent.java:454)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:416)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:210)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:499)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> According to https://issues.apache.org/jira/browse/SOLR-7756 this Bug should 
> be fixed with SOLR 5.3.0, but obviously this NPE is still present.
> Can you please help me here?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8713) New UI points to the wiki for Query Syntax instead of the Reference Guide

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8713:
--

GitHub user mariusneo opened a pull request:

https://github.com/apache/lucene-solr/pull/12

SOLR-8713 Update wiki-query-syntax link to point towards : https://cw…

Update wiki-query-syntax link to point towards 
https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing


Along the way I've updated the links that existed in some other 
solrconfig.xml files.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mariusneo/lucene-solr bugfix/SOLR-8713

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/12.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #12


commit e86fa97d5830887d73a275ad3a95e69ac79c6c20
Author: Marius 
Date:   2016-02-26T19:15:14Z

SOLR-8713 Update wiki-query-syntax link to point towards : 
https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing




> New UI points to the wiki for Query Syntax instead of the Reference Guide
> -
>
> Key: SOLR-8713
> URL: https://issues.apache.org/jira/browse/SOLR-8713
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: master
>Reporter: Tomás Fernández Löbbe
>Priority: Trivial
>  Labels: newdev
>
> Old Admin UI points to 
> https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing but 
> the new one points to http://wiki.apache.org/solr/SolrQuerySyntax



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr pull request: SOLR-8713 Update wiki-query-syntax link ...

[mariusneo]

GitHub user mariusneo opened a pull request:

https://github.com/apache/lucene-solr/pull/12

SOLR-8713 Update wiki-query-syntax link to point towards : https://cw…

Update wiki-query-syntax link to point towards 
https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing


Along the way I've updated the links that existed in some other 
solrconfig.xml files.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mariusneo/lucene-solr bugfix/SOLR-8713

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/12.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #12


commit e86fa97d5830887d73a275ad3a95e69ac79c6c20
Author: Marius 
Date:   2016-02-26T19:15:14Z

SOLR-8713 Update wiki-query-syntax link to point towards : 
https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Zookeeper and Solr Clients

[Scott Blum]

Published cluster state always lags.  And if a solr node crashes, the
status on affected replicas won't actually change until the owning
instances tries to come back up.  If you're working on a generally reusable
library, you'd want to also watch live_nodes.

On Fri, Feb 26, 2016 at 5:23 AM, Upayavira  wrote:

> This is for making a ZK aware Pysolr client (i.e. Python equiv of SolrJ
> CloudSolrClient). It clearly needs to watch ZK to be able to update the
> list of hosts that make up a collection. We can't use the API, because
> we don't yet know where the Solr nodes are!
>
> Upayavira
>
> On Fri, Feb 26, 2016, at 09:09 AM, Noble Paul wrote:
> > why do you need to watch anything? you can get the whole clusterstate
> > using the API. ZK access is not required
> >
> > On Thu, Feb 25, 2016 at 9:42 PM, Upayavira  wrote:
> > > I've recently had a patch merged into Pysolr that adds ZK awareness
> > > (compatible with custerstate.json). Now I need to update it to be
> > > compatible with the newer state.json, and I just wanted to confirm my
> > > understanding
> > >
> > > If we create a Python 'client' that is tied to a specific collection,
> > > then all I need to do is set up a watch on
> > > /collections/${collection}/state.json, and update the list of nodes
> > > accordingly (as I would have on a watch on clusterstate.json) when
> > > state.json changes.
> > >
> > > There's a lot more that *could* be done, but for the basics, it seems
> > > that's enough.
> > >
> > > Is it really this simple?
> > >
> > > Upayavira
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> >
> >
> >
> > --
> > -
> > Noble Paul
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+106) - Build # 16013 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/16013/
Java: 32bit/jdk-9-ea+106 -client -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 36445 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.awt.Component#getPeer() [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.awt.Font#getPeer() [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.awt.MenuComponent#getPeer() [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.awt.Toolkit#getFontPeer(java.lang.String,int) [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.jar.Pack200$Packer#addPropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.jar.Pack200$Packer#removePropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.jar.Pack200$Unpacker#addPropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.jar.Pack200$Unpacker#removePropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.logging.LogManager#addPropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] WARNING: Method not found while parsing signature: 
java.util.logging.LogManager#removePropertyChangeListener(java.beans.PropertyChangeListener)
 [signature ignored]
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.4
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/servlet-api.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/solr.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: 
java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default 
locale]
[forbidden-apis]   in org.apache.solr.cloud.OverseerTest$MockZKController 
(OverseerTest.java:128)
[forbidden-apis] Scanned 3180 (and 1946 related) class file(s) for forbidden 
API invocations (in 1.22s), 1 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:740: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:347: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:504: 
Check for forbidden API calls failed, see log.

Total time: 65 minutes 48 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Commented] (SOLR-8145) bin/solr script oom_killer arg incorrect

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8145:
--

I've always just given this special handling in my own installation.  My 
bin/solr script is edited to use a specific env var:

{code}
diff --git a/solr/bin/solr b/solr/bin/solr
index 85cd550..0e383b5 100755
--- a/solr/bin/solr
+++ b/solr/bin/solr
@@ -1315,7 +1315,8 @@ function launch_solr() {
 
   if [ "$run_in_foreground" == "true" ]; then
 echo -e "\nStarting Solr$IN_CLOUD_MODE on port $SOLR_PORT from 
$SOLR_SERVER_DIR\n"
-exec "$JAVA" "${SOLR_START_OPTS[@]}" $SOLR_ADDL_ARGS -jar start.jar 
"${SOLR_JETTY_CONFIG[@]}"
+# scottb: OOMKILLER needs super special handling
+exec "$JAVA" "${SOLR_START_OPTS[@]}" "${OOMKILLER:=-Dno.oom.killer}" 
$SOLR_ADDL_ARGS -jar start.jar "${SOLR_JETTY_CONFIG[@]}"
   else
 # run Solr in the background
 nohup "$JAVA" "${SOLR_START_OPTS[@]}" $SOLR_ADDL_ARGS -jar start.jar \
{code}

Then I just setup OOMKILLER in the calling script to be something like

{code}
'-XX:OnOutOfMemoryError=exec ' + os.path.abspath('killjava.sh')
{code}

At that point, you can get by with a super simple killjava.sh:

{code}
#!/bin/bash
kill -9 $PPID
{code}

The current scheme seems super complicated.


> bin/solr script oom_killer arg incorrect
> 
>
> Key: SOLR-8145
> URL: https://issues.apache.org/jira/browse/SOLR-8145
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.2.1
>Reporter: Nate Dire
>Priority: Minor
> Attachments: SOLR-8145.patch, SOLR-8145.patch, SOLR-8145.patch
>
>
> I noticed the oom_killer script wasn't working in our 5.2 deployment.
> In the {{bin/solr}} script, the {{OnOutOfMemoryError}} option is being passed 
> as an arg to the jar rather than to the JVM.  I moved it ahead of {{-jar}} 
> and verified it shows up in the JVM args in the UI.
> {noformat}
># run Solr in the background
> nohup "$JAVA" "${SOLR_START_OPTS[@]}" $SOLR_ADDL_ARGS -jar start.jar \
> "-XX:OnOutOfMemoryError=$SOLR_TIP/bin/oom_solr.sh $SOLR_PORT 
> $SOLR_LOGS_DIR" "${SOLR_JETTY_CONFIG[@]}" \
> {noformat}
> Also, I'm not sure what the {{SOLR_PORT}} and {{SOLR_LOGS_DIR}} args are 
> doing--they don't appear to be positional arguments to the jar.
> Attaching a patch against 5.2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8725) Invalid name error with core names with hyphens

[Jeff Wartes (JIRA)]

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

Jeff Wartes commented on SOLR-8725:
---

Well, I'm glad I haven't tried moving to 5.5 yet, this would have been an 
unpleasant migration discovery.
I use hyphens in both collection names and alias names. (although not as a 
leading character) 
Generally, I prefer to avoid using underscores anyplace that ends up in a URL.


> Invalid name error with core names with hyphens
> ---
>
> Key: SOLR-8725
> URL: https://issues.apache.org/jira/browse/SOLR-8725
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5
>Reporter: Chris Beer
>
> In SOLR-8642, hyphens are no longer considered valid identifiers for cores 
> (and collections?). Our solr instance was successfully using hyphens in our 
> core names, and our affected cores now error with:
> marc-profiler_shard1_replica1: 
> org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist 
> entirely of periods, underscores and alphanumerics
> Before starting to rename all of our collections, I wonder if this decision 
> could be revisited to be backwards compatible with previously created 
> collections.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8713) New UI points to the wiki for Query Syntax instead of the Reference Guide

[Marius Grama (JIRA)]

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

Marius Grama commented on SOLR-8713:


With the changes from SOLR-7858 the welcome-file is not anymore admin.html, but 
instead index.html .
index.html contains an older link for the solr query syntax.

> New UI points to the wiki for Query Syntax instead of the Reference Guide
> -
>
> Key: SOLR-8713
> URL: https://issues.apache.org/jira/browse/SOLR-8713
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: master
>Reporter: Tomás Fernández Löbbe
>Priority: Trivial
>  Labels: newdev
>
> Old Admin UI points to 
> https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing but 
> the new one points to http://wiki.apache.org/solr/SolrQuerySyntax



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 871 - Still Failing

[Michael McCandless]

I'll dig.

Mike McCandless

http://blog.mikemccandless.com


On Fri, Feb 26, 2016 at 12:42 PM, Apache Jenkins Server
 wrote:
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/871/
>
> 1 tests failed.
> FAILED:  
> org.apache.lucene.search.TestPointQueries.testPointInSetQueryManyEqualValues
>
> Error Message:
> expected:<5095> but was:<373>
>
> Stack Trace:
> java.lang.AssertionError: expected:<5095> but was:<373>
> at 
> __randomizedtesting.SeedInfo.seed([FA433671682A80E8:77E8F0922B60]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at 
> org.apache.lucene.search.TestPointQueries.testPointInSetQueryManyEqualValues(TestPointQueries.java:1723)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
> 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:367)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
> 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:367)
> at java.lang.Thread.run(Thread.java:745)
>
>
>
>
> Build Log:
> [...truncated 520 lines...]
>[junit4] Suite: org.apache.lucene.search.TestPointQueries
>[junit4] IGNOR/A 0.00s J2 | TestPointQueries.testRandomBinaryBig

[jira] [Commented] (LUCENE-7051) Remove the "estimate match count" optimization from point queries

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7051:


OK +1 to remove!

> Remove the "estimate match count" optimization from point queries
> -
>
> Key: LUCENE-7051
> URL: https://issues.apache.org/jira/browse/LUCENE-7051
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7051.patch
>
>
> Point queries try to estimate the number of matches in the visitor so that 
> the doc id set that they build does not have to do it by itself. However, 
> this is incorrect in the multi-valued case and does not seem to buy much (if 
> any) in terms of performance?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Mike Drob (JIRA)]

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

Mike Drob commented on LUCENE-6993:
---

Yea, Uwe understood my question. I wasn't planning on removing it, but I also 
didn't quite understand if it needed to be updated to the new Unicode. Sounds 
like I can leave it as is.

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch, LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6993:
---

bq. Uwe Schindler has written that he still recommends this tokenizer in some 
cases, so if you're asking if we should remove it, I don't think so.

I think the question was if it should also be upgraded to newer Unicode. But it 
does not rely on any unicode version the JAVA files should be identical. Please 
don't remove it!

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch, LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8738) invalid DBQ initially sent to a non-leader node will report success

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-8738:
---
Attachment: SOLR-8738.patch

The crux of why the errors are silently ignored seems to be because 
{{DUP.doFinish()}} only logs a WARN -- but does not propogate -- any error 
returned by {{cmdDistrib.getErrors();}} unless the type of Node involved in the 
request was a {{RetryNode}}.  The reason given for this being...

{code}
// else
// for now we don't error - we assume if it was added locally, we
// succeeded 
{code}

The problem aparently being that when a DBQ is forwarded to all leaders, 
{{StdNode}} is (currently) used -- but there was no local operation executed, 
only the forward to the leaders, so there is no local success/failure.



The attached patch changes the DBQ propagation logic to use {{RetryNode}} -- 
i'm still running full tests, but at a minimum it makes the new 
{{TestCloudDeleteByQuery}} in the patch start passing.

i don't fully understand the entire ramifications of this change, particularly 
as it relates to rest of the code in {{DUP.doFinish}} and things like forcing 
leader recovery, but based on the comments on the {{StdNode}} / {{RetryNode}} 
classes and the other uses of {{StdNode}} / {{RetryNode}}{{RetryNode}} 
(notably: STD->replica vs RETRY->leader) this seems like the most correct fix 
in general.

> invalid DBQ initially sent to a non-leader node will report success
> ---
>
> Key: SOLR-8738
> URL: https://issues.apache.org/jira/browse/SOLR-8738
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8738.patch, SOLR-8738.patch
>
>
> Discovered this while working on SOLR-445.
> If a Delete By Query gets sent to a node which is not hosting a leader (ie: 
> only hosts replicas, or doesn't host any cores related to the specified 
> collection) then a success will be returned, even if the DBQ is completely 
> malformed and actually failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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