[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_121) - Build # 6477 - Still Unstable!

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6477/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.handler.TestSQLHandler.doTest

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([5FFA8DDF6102295C:F8BE357B0CB93AE5]:0)
at 
org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:185)
at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:87)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
junit.framework.TestSuite.org.apache.solr.schema.TestUseDocValuesAsStored2

Error Message:
Could 

[jira] [Updated] (SOLR-10368) Randomize TestCollectionAPI to use both replication schemes

2017-03-26 Thread Ishan Chattopadhyaya (JIRA)

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

Ishan Chattopadhyaya updated SOLR-10368:

Description: 
As per SOLR-9835, the TestCollectionAPI was modified to *necessarily* use the 
new replication scheme for creating the test collection.

https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blobdiff;f=solr/core/src/test/org/apache/solr/cloud/TestCollectionAPI.java;h=8fbfee391e0f27700723a2b45a11abe987b6236d;hp=8905077e4c800c087394fd3793c0514276780718;hb=7830462d4b7da3acefff6353419e71cde62d5fee;hpb=faeb1fe8c16f9e02aa5c3bba295bc24325b94a07

{code}
+  req.setRealtimeReplicas(1);
{code}

This leaves the default replication mode with no coverage with respect to the 
collections API when replication factor is > 1 and numShards > 1. We should 
randomize the use of new and old replication schemes in this test (and any 
other test that was similarly changed). Alternatively, we can have another 
collection in the test for the default replication scheme with 
replicationFactor and numShards > 1.

  was:
As per SOLR-9835, the TestCollectionAPI was modified to *necessarily* use the 
new replication scheme for creating the test collection.

https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blobdiff;f=solr/core/src/test/org/apache/solr/cloud/TestCollectionAPI.java;h=8fbfee391e0f27700723a2b45a11abe987b6236d;hp=8905077e4c800c087394fd3793c0514276780718;hb=7830462d4b7da3acefff6353419e71cde62d5fee;hpb=faeb1fe8c16f9e02aa5c3bba295bc24325b94a07

{code}
+  req.setRealtimeReplicas(1);
{code}

This leaves the default replication mode with no coverage with respect to the 
collections API. We should randomize the use of new and old replication schemes 
in this test (and any other test that was similarly changed).


> Randomize TestCollectionAPI to use both replication schemes
> ---
>
> Key: SOLR-10368
> URL: https://issues.apache.org/jira/browse/SOLR-10368
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Cao Manh Dat
>
> As per SOLR-9835, the TestCollectionAPI was modified to *necessarily* use the 
> new replication scheme for creating the test collection.
> https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blobdiff;f=solr/core/src/test/org/apache/solr/cloud/TestCollectionAPI.java;h=8fbfee391e0f27700723a2b45a11abe987b6236d;hp=8905077e4c800c087394fd3793c0514276780718;hb=7830462d4b7da3acefff6353419e71cde62d5fee;hpb=faeb1fe8c16f9e02aa5c3bba295bc24325b94a07
> {code}
> +  req.setRealtimeReplicas(1);
> {code}
> This leaves the default replication mode with no coverage with respect to the 
> collections API when replication factor is > 1 and numShards > 1. We should 
> randomize the use of new and old replication schemes in this test (and any 
> other test that was similarly changed). Alternatively, we can have another 
> collection in the test for the default replication scheme with 
> replicationFactor and numShards > 1.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (SOLR-10368) Randomize TestCollectionAPI to use both replication schemes

2017-03-26 Thread Ishan Chattopadhyaya (JIRA)
Ishan Chattopadhyaya created SOLR-10368:
---

 Summary: Randomize TestCollectionAPI to use both replication 
schemes
 Key: SOLR-10368
 URL: https://issues.apache.org/jira/browse/SOLR-10368
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Ishan Chattopadhyaya
Assignee: Cao Manh Dat


As per SOLR-9835, the TestCollectionAPI was modified to *necessarily* use the 
new replication scheme for creating the test collection.

https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blobdiff;f=solr/core/src/test/org/apache/solr/cloud/TestCollectionAPI.java;h=8fbfee391e0f27700723a2b45a11abe987b6236d;hp=8905077e4c800c087394fd3793c0514276780718;hb=7830462d4b7da3acefff6353419e71cde62d5fee;hpb=faeb1fe8c16f9e02aa5c3bba295bc24325b94a07

{code}
+  req.setRealtimeReplicas(1);
{code}

This leaves the default replication mode with no coverage with respect to the 
collections API. We should randomize the use of new and old replication schemes 
in this test (and any other test that was similarly changed).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-10367) fl should support regular expressions for retrieval

2017-03-26 Thread Erick Erickson (JIRA)

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

Erick Erickson commented on SOLR-10367:
---

This has been on my list forever. It seems like this could be something that's 
part of this JIRA, a way to say "exclude these fields".
The use-case here is that you have a few huge fields that you usually don't 
want returned, so the default is "return all fields except X,Y,Z"
If you're going to work on this JIRA, please feel free to assign SOLR-3191 to 
yourself, it'll relieve my guilt over not getting to it for so long.

> fl should support regular expressions for retrieval
> ---
>
> Key: SOLR-10367
> URL: https://issues.apache.org/jira/browse/SOLR-10367
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Reporter: Umesh Prasad
>Priority: Minor
>
> Solr currently supports only two syntax for retrieving fields.
> fl = * (Retrieves all stored fields)
> fl = fl1, fl2, fl3, (retrieves  stored fields explicitly specified) 
> And this is insufficient for many needs. And there are additional 
> features/syntaxes that would be really handy.
> Case 1 :  Dynamic fields ( field names are prefixed/suffixed/name-spaced)
> fl=*
> fl.prefix = .*
> fl.suffix = *.
> or even better
> fl.ftype=
> Case 2:  Field Names are explicitly namespaced by user 
> fl =*
> fl =  
> Implementation wise this can be achieved by firing a LukeRequest handler to 
> resolve the fields .. We have to be carefully see its impact on document 
> cache keys and size but for starters we can just mark the feature an 
> experimental and disable the document cache for wildcard support. 
> Similarly  there are a lot of cases, where user has explicitly stored huge 
> fields for completeness sake and usually never needs it.
>   Currently we have includeOnly syntax in case of fl but something like
> fl.exclude= will be immensely useful.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Issue Comment Deleted] (SOLR-10367) fl should support regular expressions for retrieval

2017-03-26 Thread Erick Erickson (JIRA)

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

Erick Erickson updated SOLR-10367:
--
Comment: was deleted

(was: This has been on my list _forever_. It seems like this could be something 
that's part of this JIRA, a way to say "exclude these fields".

The use-case here is that you have a few huge fields that you usually don't 
want returned, so the default is "return all fields except X,Y,Z"

If you're going to work on this JIRA, please feel free to assign SOLR-3191 to 
yourself, it'll relieve my guilt over not getting to it for so long.)

> fl should support regular expressions for retrieval
> ---
>
> Key: SOLR-10367
> URL: https://issues.apache.org/jira/browse/SOLR-10367
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Reporter: Umesh Prasad
>Priority: Minor
>
> Solr currently supports only two syntax for retrieving fields.
> fl = * (Retrieves all stored fields)
> fl = fl1, fl2, fl3, (retrieves  stored fields explicitly specified) 
> And this is insufficient for many needs. And there are additional 
> features/syntaxes that would be really handy.
> Case 1 :  Dynamic fields ( field names are prefixed/suffixed/name-spaced)
> fl=*
> fl.prefix = .*
> fl.suffix = *.
> or even better
> fl.ftype=
> Case 2:  Field Names are explicitly namespaced by user 
> fl =*
> fl =  
> Implementation wise this can be achieved by firing a LukeRequest handler to 
> resolve the fields .. We have to be carefully see its impact on document 
> cache keys and size but for starters we can just mark the feature an 
> experimental and disable the document cache for wildcard support. 
> Similarly  there are a lot of cases, where user has explicitly stored huge 
> fields for completeness sake and usually never needs it.
>   Currently we have includeOnly syntax in case of fl but something like
> fl.exclude= will be immensely useful.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (SOLR-10367) fl should support regular expressions for retrieval

2017-03-26 Thread Erick Erickson (JIRA)

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

Erick Erickson commented on SOLR-10367:
---

This has been on my list _forever_. It seems like this could be something 
that's part of this JIRA, a way to say "exclude these fields".

The use-case here is that you have a few huge fields that you usually don't 
want returned, so the default is "return all fields except X,Y,Z"

If you're going to work on this JIRA, please feel free to assign SOLR-3191 to 
yourself, it'll relieve my guilt over not getting to it for so long.

> fl should support regular expressions for retrieval
> ---
>
> Key: SOLR-10367
> URL: https://issues.apache.org/jira/browse/SOLR-10367
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Reporter: Umesh Prasad
>Priority: Minor
>
> Solr currently supports only two syntax for retrieving fields.
> fl = * (Retrieves all stored fields)
> fl = fl1, fl2, fl3, (retrieves  stored fields explicitly specified) 
> And this is insufficient for many needs. And there are additional 
> features/syntaxes that would be really handy.
> Case 1 :  Dynamic fields ( field names are prefixed/suffixed/name-spaced)
> fl=*
> fl.prefix = .*
> fl.suffix = *.
> or even better
> fl.ftype=
> Case 2:  Field Names are explicitly namespaced by user 
> fl =*
> fl =  
> Implementation wise this can be achieved by firing a LukeRequest handler to 
> resolve the fields .. We have to be carefully see its impact on document 
> cache keys and size but for starters we can just mark the feature an 
> experimental and disable the document cache for wildcard support. 
> Similarly  there are a lot of cases, where user has explicitly stored huge 
> fields for completeness sake and usually never needs it.
>   Currently we have includeOnly syntax in case of fl but something like
> fl.exclude= will be immensely useful.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (SOLR-10367) fl should support regular expressions for retrieval

2017-03-26 Thread Umesh Prasad (JIRA)
Umesh Prasad created SOLR-10367:
---

 Summary: fl should support regular expressions for retrieval
 Key: SOLR-10367
 URL: https://issues.apache.org/jira/browse/SOLR-10367
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SearchComponents - other
Reporter: Umesh Prasad
Priority: Minor


Solr currently supports only two syntax for retrieving fields.
fl = * (Retrieves all stored fields)
fl = fl1, fl2, fl3, (retrieves  stored fields explicitly specified) 

And this is insufficient for many needs. And there are additional 
features/syntaxes that would be really handy.
Case 1 :  Dynamic fields ( field names are prefixed/suffixed/name-spaced)
fl=*
fl.prefix = .*
fl.suffix = *.
or even better
fl.ftype=

Case 2:  Field Names are explicitly namespaced by user 
fl =*
fl =  

Implementation wise this can be achieved by firing a LukeRequest handler to 
resolve the fields .. We have to be carefully see its impact on document cache 
keys and size but for starters we can just mark the feature an experimental and 
disable the document cache for wildcard support. 
Similarly  there are a lot of cases, where user has explicitly stored huge 
fields for completeness sake and usually never needs it.
  Currently we have includeOnly syntax in case of fl but something like
fl.exclude= will be immensely useful.





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[JENKINS] Lucene-Solr-Tests-6.5 - Build # 11 - Unstable

2017-03-26 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.5/11/

1 tests failed.
FAILED:  org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery

Error Message:
Expected a collection with one shard and two replicas null Last available 
state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/7)={
   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "core":"MissingSegmentRecoveryTest_shard1_replica1",   
"base_url":"http://127.0.0.1:43157/solr;,   
"node_name":"127.0.0.1:43157_solr",   "state":"down"}, 
"core_node2":{   "core":"MissingSegmentRecoveryTest_shard1_replica2",   
"base_url":"http://127.0.0.1:54195/solr;,   
"node_name":"127.0.0.1:54195_solr",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected a collection with one shard and two replicas
null
Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/7)={
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"MissingSegmentRecoveryTest_shard1_replica1",
  "base_url":"http://127.0.0.1:43157/solr;,
  "node_name":"127.0.0.1:43157_solr",
  "state":"down"},
"core_node2":{
  "core":"MissingSegmentRecoveryTest_shard1_replica2",
  "base_url":"http://127.0.0.1:54195/solr;,
  "node_name":"127.0.0.1:54195_solr",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([4378B1907E6BE997:132D2993274A5F8A]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:265)
at 
org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery(MissingSegmentRecoveryTest.java:105)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+162) - Build # 3158 - Still Unstable!

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3158/
Java: 32bit/jdk-9-ea+162 -client -XX:+UseSerialGC

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

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:42406/nydd/s","node_name":"127.0.0.1:42406_nydd%2Fs","state":"active","leader":"true"}];
 clusterState: 
DocCollection(c8n_1x3_lf//collections/c8n_1x3_lf/state.json/17)={   
"replicationFactor":"3",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "core":"c8n_1x3_lf_shard1_replica3",   
"base_url":"http://127.0.0.1:35143/nydd/s;,   
"node_name":"127.0.0.1:35143_nydd%2Fs",   "state":"down"}, 
"core_node2":{   "state":"down",   
"base_url":"http://127.0.0.1:41762/nydd/s;,   
"core":"c8n_1x3_lf_shard1_replica2",   
"node_name":"127.0.0.1:41762_nydd%2Fs"}, "core_node3":{   
"core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:42406/nydd/s;,   
"node_name":"127.0.0.1:42406_nydd%2Fs",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:42406/nydd/s","node_name":"127.0.0.1:42406_nydd%2Fs","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//collections/c8n_1x3_lf/state.json/17)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"c8n_1x3_lf_shard1_replica3",
  "base_url":"http://127.0.0.1:35143/nydd/s;,
  "node_name":"127.0.0.1:35143_nydd%2Fs",
  "state":"down"},
"core_node2":{
  "state":"down",
  "base_url":"http://127.0.0.1:41762/nydd/s;,
  "core":"c8n_1x3_lf_shard1_replica2",
  "node_name":"127.0.0.1:41762_nydd%2Fs"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:42406/nydd/s;,
  "node_name":"127.0.0.1:42406_nydd%2Fs",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([48D7D2C6983329B9:C083ED1C36CF4441]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:168)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:547)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)

[jira] [Commented] (SOLR-10366) SynonymGraphFilterFactory doesn't display the name correctly in the admin analysis page

2017-03-26 Thread Varun Thacker (JIRA)

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

Varun Thacker commented on SOLR-10366:
--

Hmm. I don't see it anymore. Can't seem to figure out what I had different that 
was showing this. I see "SGF" now . 

> SynonymGraphFilterFactory doesn't display the name correctly in the admin 
> analysis page
> ---
>
> Key: SOLR-10366
> URL: https://issues.apache.org/jira/browse/SOLR-10366
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.4, 6.5
>Reporter: Varun Thacker
>Priority: Minor
> Attachments: ListBasedTokenStream.png
>
>
> I was trying to play around with SynonymGraphFilterFactory in Solr 6.5 to see 
> how multi-word synonyms work. 
> Attached is a screenshot where the name of SynonymGraphFilterFactory is 
> displayed as "LBTS" which when you click on the tooltip reads 
> ListBasedTokenStream.java . We should be able to display the correct name here



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (SOLR-10366) SynonymGraphFilterFactory doesn't display the name correctly in the admin analysis page

2017-03-26 Thread Varun Thacker (JIRA)
Varun Thacker created SOLR-10366:


 Summary: SynonymGraphFilterFactory doesn't display the name 
correctly in the admin analysis page
 Key: SOLR-10366
 URL: https://issues.apache.org/jira/browse/SOLR-10366
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.4, 6.5
Reporter: Varun Thacker
Priority: Minor
 Attachments: ListBasedTokenStream.png

I was trying to play around with SynonymGraphFilterFactory in Solr 6.5 to see 
how multi-word synonyms work. 

Attached is a screenshot where the name of SynonymGraphFilterFactory is 
displayed as "LBTS" which when you click on the tooltip reads 
ListBasedTokenStream.java . We should be able to display the correct name here



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (SOLR-10366) SynonymGraphFilterFactory doesn't display the name correctly in the admin analysis page

2017-03-26 Thread Varun Thacker (JIRA)

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

Varun Thacker updated SOLR-10366:
-
Attachment: ListBasedTokenStream.png

> SynonymGraphFilterFactory doesn't display the name correctly in the admin 
> analysis page
> ---
>
> Key: SOLR-10366
> URL: https://issues.apache.org/jira/browse/SOLR-10366
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.4, 6.5
>Reporter: Varun Thacker
>Priority: Minor
> Attachments: ListBasedTokenStream.png
>
>
> I was trying to play around with SynonymGraphFilterFactory in Solr 6.5 to see 
> how multi-word synonyms work. 
> Attached is a screenshot where the name of SynonymGraphFilterFactory is 
> displayed as "LBTS" which when you click on the tooltip reads 
> ListBasedTokenStream.java . We should be able to display the correct name here



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_121) - Build # 19269 - Unstable!

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19269/
Java: 32bit/jdk1.8.0_121 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([101FCD5DAF7C5B46:9B381E8CEE7AF0C2]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:870)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:442)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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)
   

[jira] [Comment Edited] (LUCENE-4056) Japanese Tokenizer (Kuromoji) cannot build UniDic dictionary

2017-03-26 Thread Prashant Pol (JIRA)

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

Prashant Pol edited comment on LUCENE-4056 at 3/27/17 2:29 AM:
---

Hello [~rcmuir] [~cm],

I found support of UNIDIC dictionary at,
https://github.com/apache/lucene-solr/blob/53981795fd73e85aae1892c3c72344af7c57083a/lucene/analysis/kuromoji/src/tools/java/org/apache/lucene/analysis/ja/util/DictionaryBuilder.java

Its reading dictionary format as UNIDIC but later not using it while creating 
UnknownDictionaryWriter.
As a result build is failing with ArrayIndexOutOfBoundsException,
as IPADIC's unk.def is having 11 columns whereas UNIDIC's unk.def is having 10 
columns.

Any update on this ?


was (Author: prashantspol):
Hello [~rcmuir],

I found support of UNIDIC dictionary at,
https://github.com/apache/lucene-solr/blob/53981795fd73e85aae1892c3c72344af7c57083a/lucene/analysis/kuromoji/src/tools/java/org/apache/lucene/analysis/ja/util/DictionaryBuilder.java

Its reading dictionary format as UNIDIC but later not using it while creating 
UnknownDictionaryWriter.
As a result build is failing with ArrayIndexOutOfBoundsException,
as IPADIC's unk.def is having 11 columns whereas UNIDIC's unk.def is having 10 
columns.

Any update on this ?

> Japanese Tokenizer (Kuromoji) cannot build UniDic dictionary
> 
>
> Key: LUCENE-4056
> URL: https://issues.apache.org/jira/browse/LUCENE-4056
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 3.6
> Environment: Solr 3.6
> UniDic 1.3.12 for MeCab (unidic-mecab1312src.tar.gz)
>Reporter: Kazuaki Hiraga
>
> I tried to build a UniDic dictionary for using it along with Kuromoji on Solr 
> 3.6. I think UniDic is a good dictionary than IPA dictionary, so Kuromoji for 
> Lucene/Solr should support UniDic dictionary as standalone Kuromoji does.
> The following is my procedure:
> Modified build.xml under lucene/contrib/analyzers/kuromoji directory and run 
> 'ant build-dict', I got the error as the below.
> build-dict:
>  [java] dictionary builder
>  [java] 
>  [java] dictionary format: UNIDIC
>  [java] input directory: 
> /home/kazu/Work/src/solr/brunch_3_6/lucene/build/contrib/analyzers/kuromoji/unidic-mecab1312src
>  [java] output directory: 
> /home/kazu/Work/src/solr/brunch_3_6/lucene/contrib/analyzers/kuromoji/src/resources
>  [java] input encoding: utf-8
>  [java] normalize entries: false
>  [java] 
>  [java] building tokeninfo dict...
>  [java]   parse...
>  [java]   sort...
>  [java] Exception in thread "main" java.lang.AssertionError
>  [java]   encode...
>  [java]   at 
> org.apache.lucene.analysis.ja.util.BinaryDictionaryWriter.put(BinaryDictionaryWriter.java:113)
>  [java]   at 
> org.apache.lucene.analysis.ja.util.TokenInfoDictionaryBuilder.buildDictionary(TokenInfoDictionaryBuilder.java:141)
>  [java]   at 
> org.apache.lucene.analysis.ja.util.TokenInfoDictionaryBuilder.build(TokenInfoDictionaryBuilder.java:76)
>  [java]   at 
> org.apache.lucene.analysis.ja.util.DictionaryBuilder.build(DictionaryBuilder.java:37)
>  [java]   at 
> org.apache.lucene.analysis.ja.util.DictionaryBuilder.main(DictionaryBuilder.java:82)
> And the diff of build.xml:
> ===
> --- build.xml (revision 1338023)
> +++ build.xml (working copy)
> @@ -28,19 +28,31 @@
>
>  
>
> +  
>  
>
> -  
> +
> +  
> +  
> +  
> +   value="/home/kazu/Work/src/nlp/unidic/_archive"/>
> +
>
> +  
> +  
> +  
> +
>
>
>  
> @@ -58,7 +70,8 @@
>  
>
>
> - 
> + 
> +  tofile="${build.dir}/${dict.src.file}"/>
>   
>   
>



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (LUCENE-4056) Japanese Tokenizer (Kuromoji) cannot build UniDic dictionary

2017-03-26 Thread Prashant Pol (JIRA)

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

Prashant Pol commented on LUCENE-4056:
--

Hello [~rcmuir],

I found support of UNIDIC dictionary at,
https://github.com/apache/lucene-solr/blob/53981795fd73e85aae1892c3c72344af7c57083a/lucene/analysis/kuromoji/src/tools/java/org/apache/lucene/analysis/ja/util/DictionaryBuilder.java

Its reading dictionary format as UNIDIC but later not using it while creating 
UnknownDictionaryWriter.
As a result build is failing with ArrayIndexOutOfBoundsException,
as IPADIC's unk.def is having 11 columns whereas UNIDIC's unk.def is having 10 
columns.

Any update on this ?

> Japanese Tokenizer (Kuromoji) cannot build UniDic dictionary
> 
>
> Key: LUCENE-4056
> URL: https://issues.apache.org/jira/browse/LUCENE-4056
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 3.6
> Environment: Solr 3.6
> UniDic 1.3.12 for MeCab (unidic-mecab1312src.tar.gz)
>Reporter: Kazuaki Hiraga
>
> I tried to build a UniDic dictionary for using it along with Kuromoji on Solr 
> 3.6. I think UniDic is a good dictionary than IPA dictionary, so Kuromoji for 
> Lucene/Solr should support UniDic dictionary as standalone Kuromoji does.
> The following is my procedure:
> Modified build.xml under lucene/contrib/analyzers/kuromoji directory and run 
> 'ant build-dict', I got the error as the below.
> build-dict:
>  [java] dictionary builder
>  [java] 
>  [java] dictionary format: UNIDIC
>  [java] input directory: 
> /home/kazu/Work/src/solr/brunch_3_6/lucene/build/contrib/analyzers/kuromoji/unidic-mecab1312src
>  [java] output directory: 
> /home/kazu/Work/src/solr/brunch_3_6/lucene/contrib/analyzers/kuromoji/src/resources
>  [java] input encoding: utf-8
>  [java] normalize entries: false
>  [java] 
>  [java] building tokeninfo dict...
>  [java]   parse...
>  [java]   sort...
>  [java] Exception in thread "main" java.lang.AssertionError
>  [java]   encode...
>  [java]   at 
> org.apache.lucene.analysis.ja.util.BinaryDictionaryWriter.put(BinaryDictionaryWriter.java:113)
>  [java]   at 
> org.apache.lucene.analysis.ja.util.TokenInfoDictionaryBuilder.buildDictionary(TokenInfoDictionaryBuilder.java:141)
>  [java]   at 
> org.apache.lucene.analysis.ja.util.TokenInfoDictionaryBuilder.build(TokenInfoDictionaryBuilder.java:76)
>  [java]   at 
> org.apache.lucene.analysis.ja.util.DictionaryBuilder.build(DictionaryBuilder.java:37)
>  [java]   at 
> org.apache.lucene.analysis.ja.util.DictionaryBuilder.main(DictionaryBuilder.java:82)
> And the diff of build.xml:
> ===
> --- build.xml (revision 1338023)
> +++ build.xml (working copy)
> @@ -28,19 +28,31 @@
>
>  
>
> +  
>  
>
> -  
> +
> +  
> +  
> +  
> +   value="/home/kazu/Work/src/nlp/unidic/_archive"/>
> +
>
> +  
> +  
> +  
> +
>
>
>  
> @@ -58,7 +70,8 @@
>  
>
>
> - 
> + 
> +  tofile="${build.dir}/${dict.src.file}"/>
>   
>   
>



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[JENKINS] Lucene-Solr-SmokeRelease-6.x - Build # 297 - Failure

2017-03-26 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.x/297/

No tests ran.

Build Log:
[...truncated 25854 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (33.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.6.0-src.tgz...
   [smoker] 30.8 MB in 0.03 sec (1151.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.6.0.tgz...
   [smoker] 65.3 MB in 0.06 sec (1160.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.6.0.zip...
   [smoker] 75.7 MB in 0.07 sec (1162.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.6.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6248 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.6.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6248 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.6.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 229 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (256.1 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.6.0-src.tgz...
   [smoker] 39.6 MB in 0.04 sec (1081.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.6.0.tgz...
   [smoker] 136.0 MB in 0.12 sec (1123.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.6.0.zip...
   [smoker] 137.0 MB in 0.12 sec (1167.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.6.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.6.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]  
   [smoker] Started Solr server on port 8983 (pid=19772). Happy searching!
   [smoker] 
   [smoker] 

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

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1220/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.TestDistributedSearch.test

Error Message:
Expected to find shardAddress in the up shard info: 
{error=org.apache.solr.client.solrj.SolrServerException: No live SolrServers 
available to handle this 
request,trace=org.apache.solr.client.solrj.SolrServerException: No live 
SolrServers available to handle this request  at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:416)
  at 
org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:259)
  at 
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:166)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  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) ,time=3}

Stack Trace:
java.lang.AssertionError: Expected to find shardAddress in the up shard info: 
{error=org.apache.solr.client.solrj.SolrServerException: No live SolrServers 
available to handle this 
request,trace=org.apache.solr.client.solrj.SolrServerException: No live 
SolrServers available to handle this request
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:416)
at 
org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:259)
at 
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:166)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
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)
,time=3}
at 
__randomizedtesting.SeedInfo.seed([9B5979D1DEC85986:130D460B7034347E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.TestDistributedSearch.comparePartialResponses(TestDistributedSearch.java:1186)
at 
org.apache.solr.TestDistributedSearch.queryPartialResults(TestDistributedSearch.java:1127)
at 
org.apache.solr.TestDistributedSearch.test(TestDistributedSearch.java:987)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1011)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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 

[jira] [Commented] (SOLR-10329) Rebuild Solr examples

2017-03-26 Thread Alexandre Rafalovitch (JIRA)

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

Alexandre Rafalovitch commented on SOLR-10329:
--

Are you participating in the Google Summer of Code? You need to be registered 
and I believe the next step is to start doing a full proposal. Also, joining a 
Solr Users mailing list is a good idea. 

To get familiar with Solr, I would recommend you to start by running and 
exploring all its examples. There are more of them than one would think. A good 
overview of first steps is available on my blog: 
http://blog.outerthoughts.com/2015/11/learning-solr-comprehensively/

> Rebuild Solr examples
> -
>
> Key: SOLR-10329
> URL: https://issues.apache.org/jira/browse/SOLR-10329
> Project: Solr
>  Issue Type: Wish
>  Components: examples
>Reporter: Alexandre Rafalovitch
>  Labels: gsoc2017
>
> Apache Solr ships with a number of examples. They evolved from a kitchen sync 
> example and are rather large. When new Solr features are added, they are 
> often shoehorned into the most appropriate example and sometimes are not 
> represented at all. 
> Often, for new users, it is hard to tell what part of example is relevant, 
> what part is default and what part is demonstrating something completely 
> different.
> It would take significant (and very appreciated) effort to review all the 
> examples and rebuild them to provide clean way to showcase best practices 
> around base and most recent features.
> Specific issues are around kitchen sync vs. minimal examples, better approach 
> to "schemaless" mode and creating examples and datasets that allow to create 
> both "hello world" and more-advanced tutorials.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



Re: GSOC2017: Call to Solr and Tika/Nutch/Camel/NiFi/Zeppelin/etc mentors

2017-03-26 Thread Alexandre Rafalovitch
Sounds good. Let's see what happens.

Regards,
   Alex.

http://www.solr-start.com/ - Resources for Solr users, new and experienced


On 26 March 2017 at 07:27, Dmitry Kan  wrote:
> Hi Alexandre,
>
> Forwarded your call to luke's google group:
> https://groups.google.com/forum/#!topic/luke-discuss/rmZo7R3gDdc
>
> There might be a potential for solr/lucene/luke projects, like adding
> capability to open solr/lucene index in luke from a remote server:
> https://github.com/DmitryKey/luke/issues/68
>
> Good luck with SOC!
>
> Regards,
> Dmitry
> --
> Dmitry Kan
> Luke Toolbox: http://github.com/DmitryKey/luke
> Blog: http://dmitrykan.blogspot.com
> Twitter: http://twitter.com/dmitrykan
>
> On 17 March 2017 at 16:25, Alexandre Rafalovitch  wrote:
>>
>> I am mentoring in this year's Google Summer of Code (first timer!). I
>> know there is a couple of us from Solr project, but I also noticed
>> some mentors from upstream/downstream projects.
>>
>> I am proposing that we put at least a couple of integration projects
>> to improve/upgrade Solr integration with both upstream (Tika) and
>> downstream (Nutch/Camel/NiFi) projects. And maybe even propose some
>> new projects, such as Solr backend engine for Zeppelin (so we could
>> have a Python Notebook-like interface to Solr, not just via JDBC
>> bridge, we do already).
>>
>> I am not sure whose JIRAs they should go into, but the project idea
>> tag spans all ASF projects, so it is more important to figure out
>> mentor-level agreement first.
>>
>> In any case, to push this forward, if we get several students all
>> working on Solr, I could run a Solr bootcamp class for students,
>> mentors, and whoever else in the sister communities wants to
>> participate and get more familiar with Solr. We could also run a
>> parallel mini-list (or Gitter room or whatever) where multiple new
>> implementors of Solr integrations can hang out together and progress
>> together.
>>
>>
>> Regards,
>>Alex.
>> P.s. I am also working on redoing Solr examples (starting from DIH
>> ones at: SOLR-10311). If anybody has comments on what kind of examples
>> would make integrations easier, I am very receptive.
>> P.p.s. Feel free to forward this to the other mailing lists for other
>> relevant sister Apache communities.
>> 
>> http://www.solr-start.com/ - Resources for Solr users, new and experienced
>>
>> -
>> 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-6.x-Linux (32bit/jdk1.8.0_121) - Build # 3157 - Still Unstable!

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3157/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv

Error Message:
java.lang.RuntimeException: Error from server at 
http://127.0.0.1:34879/solr/test_col: Async exception during distributed 
update: Error from server at 
http://127.0.0.1:46166/solr/test_col_shard1_replica1: Server Errorrequest: 
http://127.0.0.1:46166/solr/test_col_shard1_replica1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A34879%2Fsolr%2Ftest_col_shard2_replica2%2F=javabin=2
 Remote error message: Failed synchronous update on shard StdNode: 
http://127.0.0.1:35050/solr/test_col_shard1_replica2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@11acebf

Stack Trace:
java.util.concurrent.ExecutionException: java.lang.RuntimeException: Error from 
server at http://127.0.0.1:34879/solr/test_col: Async exception during 
distributed update: Error from server at 
http://127.0.0.1:46166/solr/test_col_shard1_replica1: Server Error



request: 
http://127.0.0.1:46166/solr/test_col_shard1_replica1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A34879%2Fsolr%2Ftest_col_shard2_replica2%2F=javabin=2
Remote error message: Failed synchronous update on shard StdNode: 
http://127.0.0.1:35050/solr/test_col_shard1_replica2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@11acebf
at 
__randomizedtesting.SeedInfo.seed([72B0B386CE823E83:44A4D1C044DF0492]:0)
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:281)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:193)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 786 - Unstable!

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/786/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

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

Error Message:
Could not find collection:collection2

Stack Trace:
java.lang.AssertionError: Could not find collection:collection2
at 
__randomizedtesting.SeedInfo.seed([E27D7BAF58DEF77E:6A294475F6229A86]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:159)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:865)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:620)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3922 - Still Unstable!

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3922/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI

Error Message:
Could not find collection : implicitcoll

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : implicitcoll
at 
__randomizedtesting.SeedInfo.seed([6ABDE45BA9D1ED3:6C4A502E8707A8AB]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:194)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:245)
at 
org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:68)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 1 lines...]
   [junit4] Suite: org.apache.solr.cloud.CustomCollectionTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (LUCENE-7671) Enhance UpgradeIndexMergePolicy with additional options

2017-03-26 Thread Michael McCandless (JIRA)

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

Michael McCandless commented on LUCENE-7671:


Hi [~k317h], the latest PR looks great!  I found only a couple minor things:

Typo in this test case:

bq. testUpgradeWithExcplicitUpgrades

(the first {{c}} should be removed).

In the IndexUpgrader usage output can you explain what the 
-include-new-segments does?


> Enhance UpgradeIndexMergePolicy with additional options
> ---
>
> Key: LUCENE-7671
> URL: https://issues.apache.org/jira/browse/LUCENE-7671
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Keith Laban
>
> Enhance UpgradeIndexMergePolicy to be a MergePolicy that can be used outside 
> the scope the IndexUpgrader.
> The enhancement aims to allow the UpgradeIndexMergePolicy to:
> 1) Delegate normal force merges to the underlying merge policy
> 2) Enable a flag that will explicitly tell UpgradeIndexMergePolicy when it 
> should start looking for upgrades.
> 3) Allow new segments to be considered to be merged with old segments, 
> depending on underlying MergePolicy.
> 4) Be configurable for backwards compatibility such that only segments 
> needing an upgrade would be considered when merging, no explicit upgrades.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (LUCENE-7752) Findbugs: Array.equals is equivalent to comparing references

2017-03-26 Thread Michael McCandless (JIRA)

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

Michael McCandless commented on LUCENE-7752:


Thanks [~djelinski], that's a great catch!  Your patch looks correct; does the 
test now fail?  The way it is in trunk now (buggy) would make the assert rarely 
have a chance to trigger, but with your (correct) fix, it's actually meaningful.

> Findbugs: Array.equals is equivalent to comparing references
> 
>
> Key: LUCENE-7752
> URL: https://issues.apache.org/jira/browse/LUCENE-7752
> Project: Lucene - Core
>  Issue Type: Sub-task
>Reporter: Daniel Jelinski
>Priority: Minor
> Attachments: LUCENE-7752.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_121) - Build # 3156 - Unstable!

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3156/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
expected:<3> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([ADE5E129E4B8C618:E590959DE28BE98D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:522)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12154 lines...]
   [junit4] Suite: 

[jira] [Commented] (LUCENE-7525) ASCIIFoldingFilter.foldToASCII performance issue due to large compiled method size

2017-03-26 Thread Michael Braun (JIRA)

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

Michael Braun commented on LUCENE-7525:
---

Should a new utility Char-To-Int map be created in lucene-core utils to store 
the char->int (combined chars) map?

> ASCIIFoldingFilter.foldToASCII performance issue due to large compiled method 
> size
> --
>
> Key: LUCENE-7525
> URL: https://issues.apache.org/jira/browse/LUCENE-7525
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 6.2.1
>Reporter: Karl von Randow
> Attachments: ASCIIFoldingFilter.java, ASCIIFolding.java, 
> LUCENE-7525.patch, LUCENE-7525.patch, TestASCIIFolding.java
>
>
> The {{ASCIIFoldingFilter.foldToASCII}} method has an enormous switch 
> statement and is too large for the HotSpot compiler to compile; causing a 
> performance problem.
> The method is about 13K compiled, versus the 8KB HotSpot limit. So splitting 
> the method in half works around the problem.
> In my tests splitting the method in half resulted in a 5X performance 
> increase.
> In the test code below you can see how slow the fold method is, even when it 
> is using the shortcut when the character is less than 0x80, compared to an 
> inline implementation of the same shortcut.
> So a workaround is to split the method. I'm happy to provide a patch. It's a 
> hack, of course. Perhaps using the {{MappingCharFilterFactory}} with an input 
> file as per SOLR-2013 would be a better replacement for this method in this 
> class?
> {code:java}
> public class ASCIIFoldingFilterPerformanceTest {
>   private static final int ITERATIONS = 1_000_000;
>   @Test
>   public void testFoldShortString() {
>   char[] input = "testing".toCharArray();
>   char[] output = new char[input.length * 4];
>   for (int i = 0; i < ITERATIONS; i++) {
>   ASCIIFoldingFilter.foldToASCII(input, 0, output, 0, 
> input.length);
>   }
>   }
>   @Test
>   public void testFoldShortAccentedString() {
>   char[] input = "éúéúøßüäéúéúøßüä".toCharArray();
>   char[] output = new char[input.length * 4];
>   for (int i = 0; i < ITERATIONS; i++) {
>   ASCIIFoldingFilter.foldToASCII(input, 0, output, 0, 
> input.length);
>   }
>   }
>   @Test
>   public void testManualFoldTinyString() {
>   char[] input = "t".toCharArray();
>   char[] output = new char[input.length * 4];
>   for (int i = 0; i < ITERATIONS; i++) {
>   int k = 0;
>   for (int j = 0; j < 1; ++j) {
>   final char c = input[j];
>   if (c < '\u0080') {
>   output[k++] = c;
>   } else {
>   Assert.assertTrue(false);
>   }
>   }
>   }
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_121) - Build # 806 - Still Unstable!

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/806/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.TestDistributedSearch.test

Error Message:
Expected to find shardAddress in the up shard info

Stack Trace:
java.lang.AssertionError: Expected to find shardAddress in the up shard info
at 
__randomizedtesting.SeedInfo.seed([BA1263625F147996:32465CB8F1E8146E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.TestDistributedSearch.comparePartialResponses(TestDistributedSearch.java:1176)
at 
org.apache.solr.TestDistributedSearch.queryPartialResults(TestDistributedSearch.java:1117)
at 
org.apache.solr.TestDistributedSearch.test(TestDistributedSearch.java:977)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1018)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[jira] [Commented] (SOLR-10363) ComplexPhrase WildCard Case Sensitivy problem

2017-03-26 Thread Mikhail Khludnev (JIRA)

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

Mikhail Khludnev commented on SOLR-10363:
-

I'm in doubts. SOLR-7466 set up delegation from Lucene's CPQP to Solr's logic, 
but really.. such analysis should be done even in Lucene's CPQP, and it doesn't 
delegate *PrefixQuery. 

> ComplexPhrase WildCard Case Sensitivy problem
> -
>
> Key: SOLR-10363
> URL: https://issues.apache.org/jira/browse/SOLR-10363
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.4.1, 6.5, 6.4.2
>Reporter: Eyyub ÇİL
>  Labels: CPQP, analyzers, complexqueryparser, filterfactory, 
> wildcard
> Attachments: complexPhraseWildCardBug.zip, 
> TestComplexPhraseTurkishECIL.java, TestComplexPhraseTurkish.java
>
>
> I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.
> When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA", 
> {!complexphrase}SContent_tinx:"6* yaşında" , results is correct.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":104,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
> "parsedquery_toString":"\"6* YAŞINDa\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
> {!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
> according to  Case Sensitive condition.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":10,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
> "parsedquery_toString":"\"60 YAŞIND*\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> When I search without ComplexPhraseQueryParser, numbers of results are same 
> for +60 YAŞIND*+ and +60 yaşınd*+
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":56,
> "params":{
>   "q":"60 yaŞınd*",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "debugQuery":"on",
>   "_":"1490456571184"}},
>   "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"60 yaŞınd*",
> "querystring":"60 yaŞınd*",
> "parsedquery":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "parsedquery_toString":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "QParser":"LuceneQParser",
> "explain":{}}}
> {code}
> {code:xml}
>  positionIncrementGap="100">
>  
>
>   
>pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>
> 
>   
>   
> 
>   
>  pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Comment Edited] (SOLR-10363) ComplexPhrase WildCard Case Sensitivy problem

2017-03-26 Thread JIRA

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

Eyyub ÇİL edited comment on SOLR-10363 at 3/26/17 7:26 PM:
---

Hi Mikhail, thanks for your comment. After your comment, I did some tests on 
different releases too. These release 6.4.1, 6.4.2, 6.5.0 and Master (hash is 
013601f05396523ad900a409e67cdbea19571447). My test only pass on Master branch.  

I attached TestComplexPhraseTurkishECIL.java and test results on different 
releases.

Does anyone know which commit  solved this problem? 





was (Author: ecil):
Hi Mikhail, thanks for your comment. After your comment, I did some tests on 
different releases too. These release 6.4.1, 6.4.2, 6.5.0 and Master (hash is 
013601f05396523ad900a409e67cdbea19571447). My test only pass on Master branch.  

I attached TestComplexPhraseTurkishECIL.java and test results of different on 
different releases.

Does anyone know which commit  solved this problem? 




> ComplexPhrase WildCard Case Sensitivy problem
> -
>
> Key: SOLR-10363
> URL: https://issues.apache.org/jira/browse/SOLR-10363
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.4.1, 6.5, 6.4.2
>Reporter: Eyyub ÇİL
>  Labels: CPQP, analyzers, complexqueryparser, filterfactory, 
> wildcard
> Attachments: complexPhraseWildCardBug.zip, 
> TestComplexPhraseTurkishECIL.java, TestComplexPhraseTurkish.java
>
>
> I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.
> When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA", 
> {!complexphrase}SContent_tinx:"6* yaşında" , results is correct.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":104,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
> "parsedquery_toString":"\"6* YAŞINDa\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
> {!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
> according to  Case Sensitive condition.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":10,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
> "parsedquery_toString":"\"60 YAŞIND*\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> When I search without ComplexPhraseQueryParser, numbers of results are same 
> for +60 YAŞIND*+ and +60 yaşınd*+
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":56,
> "params":{
>   "q":"60 yaŞınd*",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "debugQuery":"on",
>   "_":"1490456571184"}},
>   "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"60 yaŞınd*",
> "querystring":"60 yaŞınd*",
> "parsedquery":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "parsedquery_toString":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "QParser":"LuceneQParser",
> "explain":{}}}
> {code}
> {code:xml}
>  positionIncrementGap="100">
>  
>
>   
>pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>
> 
>   
>   
> 
>   
>  pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_121) - Build # 6476 - Still Unstable!

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6476/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly

Error Message:
Unexpected number of elements in the group for intGSF: 6

Stack Trace:
java.lang.AssertionError: Unexpected number of elements in the group for 
intGSF: 6
at 
__randomizedtesting.SeedInfo.seed([A0F05643D837C7AB:3B4B381B956FF5F5]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:376)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11510 lines...]
   [junit4] Suite: org.apache.solr.cloud.DocValuesNotIndexedTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (LUCENE-7580) Spans tree scoring

2017-03-26 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on LUCENE-7580:


Github user PaulElschot commented on the issue:

https://github.com/apache/lucene-solr/pull/166
  
Superseded earlier today.


> Spans tree scoring
> --
>
> Key: LUCENE-7580
> URL: https://issues.apache.org/jira/browse/LUCENE-7580
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Paul Elschot
>Priority: Minor
> Fix For: 6.x
>
> Attachments: Elschot20170326Counting.pdf, LUCENE-7580.patch, 
> LUCENE-7580.patch, LUCENE-7580.patch, LUCENE-7580.patch
>
>
> Recurse the spans tree to compose a score based on the type of subqueries and 
> what matched



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[GitHub] lucene-solr issue #166: LUCENE-7580 of 8 Mar 2017.

2017-03-26 Thread PaulElschot
Github user PaulElschot commented on the issue:

https://github.com/apache/lucene-solr/pull/166
  
Superseded earlier today.


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



[GitHub] lucene-solr pull request #166: LUCENE-7580 of 8 Mar 2017.

2017-03-26 Thread PaulElschot
Github user PaulElschot closed the pull request at:

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


---
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-7580) Spans tree scoring

2017-03-26 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on LUCENE-7580:


Github user PaulElschot closed the pull request at:

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


> Spans tree scoring
> --
>
> Key: LUCENE-7580
> URL: https://issues.apache.org/jira/browse/LUCENE-7580
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Paul Elschot
>Priority: Minor
> Fix For: 6.x
>
> Attachments: Elschot20170326Counting.pdf, LUCENE-7580.patch, 
> LUCENE-7580.patch, LUCENE-7580.patch, LUCENE-7580.patch
>
>
> Recurse the spans tree to compose a score based on the type of subqueries and 
> what matched



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Comment Edited] (LUCENE-7580) Spans tree scoring

2017-03-26 Thread Paul Elschot (JIRA)

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

Paul Elschot edited comment on LUCENE-7580 at 3/26/17 6:51 PM:
---

I just pushed two branches to github, pullable as:

git pull https://github.com/PaulElschot/lucene-solr lucene7580-20170326

and

git pull https://github.com/PaulElschot/lucene-solr lucene7580report-20170326

The lucene7580-20170326 branch is an update of the previous pull request with a 
few minor improvements. Most notable is putting SpansTreeWeight into its own 
source file.

The  lucene7580report-20170326 branch is on top of the  lucene7580-20170326 
branch, with the addition of the tex sources for a report on this issue.
I'll attach the pdf shortly here.



was (Author: paul.elsc...@xs4all.nl):
I just pushed to branches to github, pullable as:

git pull https://github.com/PaulElschot/lucene-solr lucene7580-20170326

and

git pull https://github.com/PaulElschot/lucene-solr lucene7580report-20170326

The lucene7580-20170326 branch is an update of the previous pull request with a 
few minor improvements. Most notable is putting SpansTreeWeight into its own 
source file.

The  lucene7580report-20170326 branch is on top of the  lucene7580-20170326 
branch, with the addition of the tex sources for a report on this issue.
I'll attach the pdf shortly here.


> Spans tree scoring
> --
>
> Key: LUCENE-7580
> URL: https://issues.apache.org/jira/browse/LUCENE-7580
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Paul Elschot
>Priority: Minor
> Fix For: 6.x
>
> Attachments: Elschot20170326Counting.pdf, LUCENE-7580.patch, 
> LUCENE-7580.patch, LUCENE-7580.patch, LUCENE-7580.patch
>
>
> Recurse the spans tree to compose a score based on the type of subqueries and 
> what matched



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Comment Edited] (LUCENE-7580) Spans tree scoring

2017-03-26 Thread Paul Elschot (JIRA)

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

Paul Elschot edited comment on LUCENE-7580 at 3/26/17 6:51 PM:
---

I just pushed to branches to github, pullable as:

git pull https://github.com/PaulElschot/lucene-solr lucene7580-20170326

and

git pull https://github.com/PaulElschot/lucene-solr lucene7580report-20170326

The lucene7580-20170326 branch is an update of the previous pull request with a 
few minor improvements. Most notable is putting SpansTreeWeight into its own 
source file.

The  lucene7580report-20170326 branch is on top of the  lucene7580-20170326 
branch, with the addition of the tex sources for a report on this issue.
I'll attach the pdf shortly here.



was (Author: paul.elsc...@xs4all.nl):
I just pushed to branches to github, pullable as:

git pull https://github.com/PaulElschot/lucene-solr lucene7580-20170326

and

git pull https://github.com/PaulElschot/lucene-solr lucene7580report-20170326

The lucene7580-20170326 branch an update of the previous pull request with a 
few minor improvements.
Most notable is putting SpansTreeWeight into its own source file.

The  lucene7580report-20170326 is on top of the  lucene7580-20170326 branch, 
with the addition of the tex sources for a report on this issue.
I'll attach the pdf shortly here.


> Spans tree scoring
> --
>
> Key: LUCENE-7580
> URL: https://issues.apache.org/jira/browse/LUCENE-7580
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Paul Elschot
>Priority: Minor
> Fix For: 6.x
>
> Attachments: Elschot20170326Counting.pdf, LUCENE-7580.patch, 
> LUCENE-7580.patch, LUCENE-7580.patch, LUCENE-7580.patch
>
>
> Recurse the spans tree to compose a score based on the type of subqueries and 
> what matched



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (LUCENE-7580) Spans tree scoring

2017-03-26 Thread Paul Elschot (JIRA)

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

Paul Elschot updated LUCENE-7580:
-
Attachment: Elschot20170326Counting.pdf

Report of 26 March 2017, generated from the lucene7580report-20170326 branch 
and renamed to include the full date in the name.

> Spans tree scoring
> --
>
> Key: LUCENE-7580
> URL: https://issues.apache.org/jira/browse/LUCENE-7580
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Paul Elschot
>Priority: Minor
> Fix For: 6.x
>
> Attachments: Elschot20170326Counting.pdf, LUCENE-7580.patch, 
> LUCENE-7580.patch, LUCENE-7580.patch, LUCENE-7580.patch
>
>
> Recurse the spans tree to compose a score based on the type of subqueries and 
> what matched



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[JENKINS] Lucene-Solr-Tests-6.x - Build # 820 - Unstable

2017-03-26 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/820/

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

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:54078","node_name":"127.0.0.1:54078_","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/31)={   
"replicationFactor":"3",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "state":"down",   
"base_url":"http://127.0.0.1:35976;,   
"core":"c8n_1x3_lf_shard1_replica3",   "node_name":"127.0.0.1:35976_"}, 
"core_node2":{   "core":"c8n_1x3_lf_shard1_replica2",   
"base_url":"http://127.0.0.1:7;,   "node_name":"127.0.0.1:7_",  
 "state":"down"}, "core_node3":{   
"core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:54078;,   "node_name":"127.0.0.1:54078_",  
 "state":"active",   "leader":"true",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:54078","node_name":"127.0.0.1:54078_","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/31)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "state":"down",
  "base_url":"http://127.0.0.1:35976;,
  "core":"c8n_1x3_lf_shard1_replica3",
  "node_name":"127.0.0.1:35976_"},
"core_node2":{
  "core":"c8n_1x3_lf_shard1_replica2",
  "base_url":"http://127.0.0.1:7;,
  "node_name":"127.0.0.1:7_",
  "state":"down"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:54078;,
  "node_name":"127.0.0.1:54078_",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([E41E825B6651F587:6C4ABD81C8AD987F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:168)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 

[jira] [Commented] (LUCENE-7580) Spans tree scoring

2017-03-26 Thread Paul Elschot (JIRA)

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

Paul Elschot commented on LUCENE-7580:
--

I just pushed to branches to github, pullable as:

git pull https://github.com/PaulElschot/lucene-solr lucene7580-20170326

and

git pull https://github.com/PaulElschot/lucene-solr lucene7580report-20170326

The lucene7580-20170326 branch an update of the previous pull request with a 
few minor improvements.
Most notable is putting SpansTreeWeight into its own source file.

The  lucene7580report-20170326 is on top of the  lucene7580-20170326 branch, 
with the addition of the tex sources for a report on this issue.
I'll attach the pdf shortly here.


> Spans tree scoring
> --
>
> Key: LUCENE-7580
> URL: https://issues.apache.org/jira/browse/LUCENE-7580
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Paul Elschot
>Priority: Minor
> Fix For: 6.x
>
> Attachments: LUCENE-7580.patch, LUCENE-7580.patch, LUCENE-7580.patch, 
> LUCENE-7580.patch
>
>
> Recurse the spans tree to compose a score based on the type of subqueries and 
> what matched



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Comment Edited] (SOLR-10363) ComplexPhrase WildCard Case Sensitivy problem

2017-03-26 Thread JIRA

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

Eyyub ÇİL edited comment on SOLR-10363 at 3/26/17 6:20 PM:
---

Hi Mikhail, thanks for your comment. After your comment, I did some tests on 
different releases too. These release 6.4.1, 6.4.2, 6.5.0 and Master (hash is 
013601f05396523ad900a409e67cdbea19571447). My test only pass on Master branch.  

I attached TestComplexPhraseTurkishECIL.java and test results of different on 
different releases.

Does anyone know which commit  solved this problem? 





was (Author: ecil):
Hi Mikhail, thanks for your comment. After your comment, I did some tests on 
different releases too. These release 6.4.1, 6.4.2, 6.5.0 and Master (hash is 
013601f05396523ad900a409e67cdbea19571447). My test only pass on Master branch.  

I attached !TestComplexPhraseTurkishECIL.java! and test results of different on 
different releases.

Does anyone know which commit  solved this problem? 




> ComplexPhrase WildCard Case Sensitivy problem
> -
>
> Key: SOLR-10363
> URL: https://issues.apache.org/jira/browse/SOLR-10363
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.4.1, 6.5, 6.4.2
>Reporter: Eyyub ÇİL
>  Labels: CPQP, analyzers, complexqueryparser, filterfactory, 
> wildcard
> Attachments: complexPhraseWildCardBug.zip, 
> TestComplexPhraseTurkishECIL.java, TestComplexPhraseTurkish.java
>
>
> I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.
> When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA", 
> {!complexphrase}SContent_tinx:"6* yaşında" , results is correct.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":104,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
> "parsedquery_toString":"\"6* YAŞINDa\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
> {!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
> according to  Case Sensitive condition.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":10,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
> "parsedquery_toString":"\"60 YAŞIND*\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> When I search without ComplexPhraseQueryParser, numbers of results are same 
> for +60 YAŞIND*+ and +60 yaşınd*+
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":56,
> "params":{
>   "q":"60 yaŞınd*",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "debugQuery":"on",
>   "_":"1490456571184"}},
>   "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"60 yaŞınd*",
> "querystring":"60 yaŞınd*",
> "parsedquery":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "parsedquery_toString":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "QParser":"LuceneQParser",
> "explain":{}}}
> {code}
> {code:xml}
>  positionIncrementGap="100">
>  
>
>   
>pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>
> 
>   
>   
> 
>   
>  pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Comment Edited] (SOLR-10363) ComplexPhrase WildCard Case Sensitivy problem

2017-03-26 Thread JIRA

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

Eyyub ÇİL edited comment on SOLR-10363 at 3/26/17 6:20 PM:
---

Hi Mikhail, thanks for your comment. After your comment, I did some tests on 
different releases too. These release 6.4.1, 6.4.2, 6.5.0 and Master (hash is 
013601f05396523ad900a409e67cdbea19571447). My test only pass on Master branch.  

I attached !TestComplexPhraseTurkishECIL.java! and test results of different on 
different releases.

Does anyone know which commit  solved this problem? 





was (Author: ecil):
Hi Mikhail, thanks for your comment. After your comment, I did some tests on 
different releases too. These release 6.4.1, 6.4.2, 6.5.0 and Master (hash is 
013601f05396523ad900a409e67cdbea19571447). My test only pass on Master branch.  

I attached TestComplexPhraseTurkishECIL.java and test results of different on 
different releases.

Does anyone know which commit  solved this problem? 




> ComplexPhrase WildCard Case Sensitivy problem
> -
>
> Key: SOLR-10363
> URL: https://issues.apache.org/jira/browse/SOLR-10363
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.4.1, 6.5, 6.4.2
>Reporter: Eyyub ÇİL
>  Labels: CPQP, analyzers, complexqueryparser, filterfactory, 
> wildcard
> Attachments: complexPhraseWildCardBug.zip, 
> TestComplexPhraseTurkishECIL.java, TestComplexPhraseTurkish.java
>
>
> I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.
> When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA", 
> {!complexphrase}SContent_tinx:"6* yaşında" , results is correct.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":104,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
> "parsedquery_toString":"\"6* YAŞINDa\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
> {!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
> according to  Case Sensitive condition.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":10,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
> "parsedquery_toString":"\"60 YAŞIND*\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> When I search without ComplexPhraseQueryParser, numbers of results are same 
> for +60 YAŞIND*+ and +60 yaşınd*+
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":56,
> "params":{
>   "q":"60 yaŞınd*",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "debugQuery":"on",
>   "_":"1490456571184"}},
>   "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"60 yaŞınd*",
> "querystring":"60 yaŞınd*",
> "parsedquery":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "parsedquery_toString":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "QParser":"LuceneQParser",
> "explain":{}}}
> {code}
> {code:xml}
>  positionIncrementGap="100">
>  
>
>   
>pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>
> 
>   
>   
> 
>   
>  pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (SOLR-10363) ComplexPhrase WildCard Case Sensitivy problem

2017-03-26 Thread JIRA

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

Eyyub ÇİL updated SOLR-10363:
-
Affects Version/s: 6.5
   6.4.2

> ComplexPhrase WildCard Case Sensitivy problem
> -
>
> Key: SOLR-10363
> URL: https://issues.apache.org/jira/browse/SOLR-10363
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.4.1, 6.5, 6.4.2
>Reporter: Eyyub ÇİL
>  Labels: CPQP, analyzers, complexqueryparser, filterfactory, 
> wildcard
> Attachments: complexPhraseWildCardBug.zip, 
> TestComplexPhraseTurkishECIL.java, TestComplexPhraseTurkish.java
>
>
> I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.
> When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA", 
> {!complexphrase}SContent_tinx:"6* yaşında" , results is correct.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":104,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
> "parsedquery_toString":"\"6* YAŞINDa\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
> {!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
> according to  Case Sensitive condition.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":10,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
> "parsedquery_toString":"\"60 YAŞIND*\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> When I search without ComplexPhraseQueryParser, numbers of results are same 
> for +60 YAŞIND*+ and +60 yaşınd*+
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":56,
> "params":{
>   "q":"60 yaŞınd*",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "debugQuery":"on",
>   "_":"1490456571184"}},
>   "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"60 yaŞınd*",
> "querystring":"60 yaŞınd*",
> "parsedquery":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "parsedquery_toString":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "QParser":"LuceneQParser",
> "explain":{}}}
> {code}
> {code:xml}
>  positionIncrementGap="100">
>  
>
>   
>pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>
> 
>   
>   
> 
>   
>  pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (SOLR-10363) ComplexPhrase WildCard Case Sensitivy problem

2017-03-26 Thread JIRA

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

Eyyub ÇİL updated SOLR-10363:
-
Attachment: complexPhraseWildCardBug.zip
TestComplexPhraseTurkishECIL.java

Hi Mikhail, thanks for your comment. After your comment, I did some tests on 
different releases too. These release 6.4.1, 6.4.2, 6.5.0 and Master (hash is 
013601f05396523ad900a409e67cdbea19571447). My test only pass on Master branch.  

I attached TestComplexPhraseTurkishECIL.java and test results of different on 
different releases.

Does anyone know which commit  solved this problem? 




> ComplexPhrase WildCard Case Sensitivy problem
> -
>
> Key: SOLR-10363
> URL: https://issues.apache.org/jira/browse/SOLR-10363
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.4.1
>Reporter: Eyyub ÇİL
>  Labels: CPQP, analyzers, complexqueryparser, filterfactory, 
> wildcard
> Attachments: complexPhraseWildCardBug.zip, 
> TestComplexPhraseTurkishECIL.java, TestComplexPhraseTurkish.java
>
>
> I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.
> When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA", 
> {!complexphrase}SContent_tinx:"6* yaşında" , results is correct.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":104,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
> "parsedquery_toString":"\"6* YAŞINDa\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
> {!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
> according to  Case Sensitive condition.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":10,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
> "parsedquery_toString":"\"60 YAŞIND*\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> When I search without ComplexPhraseQueryParser, numbers of results are same 
> for +60 YAŞIND*+ and +60 yaşınd*+
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":56,
> "params":{
>   "q":"60 yaŞınd*",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "debugQuery":"on",
>   "_":"1490456571184"}},
>   "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"60 yaŞınd*",
> "querystring":"60 yaŞınd*",
> "parsedquery":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "parsedquery_toString":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "QParser":"LuceneQParser",
> "explain":{}}}
> {code}
> {code:xml}
>  positionIncrementGap="100">
>  
>
>   
>pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>
> 
>   
>   
> 
>   
>  pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (SOLR-10365) Collection re-creation fails if previous collection creation had failed

2017-03-26 Thread Ishan Chattopadhyaya (JIRA)

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

Ishan Chattopadhyaya updated SOLR-10365:

Attachment: SOLR-10365.patch

Here's a patch that fixes this situation.

> Collection re-creation fails if previous collection creation had failed
> ---
>
> Key: SOLR-10365
> URL: https://issues.apache.org/jira/browse/SOLR-10365
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
> Attachments: SOLR-10365.patch
>
>
> Steps to reproduce:
> # Create collection using a bad configset that has some errors, due to which 
> collection creation fails.
> # Now, create a collection using the same name, but a good configset. This 
> fails sometimes (about 25-30% of the times, according to my rough estimate).
> Here's what happens during the second step (can be seen from stacktrace 
> below):
> # In CoreContainer's create(CoreDescriptor, boolean, boolean), there's a line 
> {{zkSys.getZkController().preRegister(dcore);}}.
> # This calls ZkController's publish(), which in turn calls CoreContainer's 
> getCore() method. This call *should* return null (since previous attempt of 
> core creation didn't succeed). But, it throws the exception associated with 
> the previous failure.
> Here's the stack trace for the same.
> {code}
> Caused by: org.apache.solr.common.SolrException: SolrCore 
> 'newcollection2_shard1_replica1' is not available due to init failure: 
> blahblah
>   at org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:1312)
>   at org.apache.solr.cloud.ZkController.publish(ZkController.java:1225)
>   at 
> org.apache.solr.cloud.ZkController.preRegister(ZkController.java:1399)
>   at org.apache.solr.core.CoreContainer.create(CoreContainer.java:945)
> {code}
> While working on SOLR-6736, I ran into this (nasty?) issue. I'll try to 
> isolate this into a standalone test that demonstrates this issue. Otherwise, 
> as of now, this can be seen in the SOLR-6736's 
> testUploadWithScriptUpdateProcessor() test (which tries to re-create the 
> collection, but sometimes fails).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+162) - Build # 19266 - Unstable!

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19266/
Java: 32bit/jdk-9-ea+162 -client -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.SolrCloudExampleTest

Error Message:
ObjectTracker found 6 object(s) that were not released!!! 
[MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MockDirectoryWrapper, 
MockDirectoryWrapper, TransactionLog, SolrIndexSearcher] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:872)  at 
org.apache.solr.core.SolrCore.reload(SolrCore.java:642)  at 
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1139)  at 
org.apache.solr.core.SolrCore.lambda$getConfListener$16(SolrCore.java:2964)  at 
org.apache.solr.handler.SolrConfigHandler$Command.lambda$handleGET$0(SolrConfigHandler.java:225)
  at java.base/java.lang.Thread.run(Thread.java:844)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:92)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:747)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:931)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:849)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:950)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:886)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:88)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:370)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:388)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:747)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:728)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:509)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:202)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) 
 at java.base/java.lang.Thread.run(Thread.java:844)  

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 319 - Failure

2017-03-26 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/319/

2 tests failed.
FAILED:  org.apache.solr.update.TestInPlaceUpdatesDistrib.test

Error Message:
Timeout occured while waiting response from server at: 
https://127.0.0.1:50518/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:50518/collection1
at 
__randomizedtesting.SeedInfo.seed([37A661DCC1EDC100:BFF25E066F11ACF8]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:621)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.buildRandomIndex(TestInPlaceUpdatesDistrib.java:1127)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.docValuesUpdateTest(TestInPlaceUpdatesDistrib.java:327)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:154)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[jira] [Created] (SOLR-10365) Collection re-creation fails if previous collection creation had failed

2017-03-26 Thread Ishan Chattopadhyaya (JIRA)
Ishan Chattopadhyaya created SOLR-10365:
---

 Summary: Collection re-creation fails if previous collection 
creation had failed
 Key: SOLR-10365
 URL: https://issues.apache.org/jira/browse/SOLR-10365
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Ishan Chattopadhyaya


Steps to reproduce:
# Create collection using a bad configset that has some errors, due to which 
collection creation fails.
# Now, create a collection using the same name, but a good configset. This 
fails sometimes (about 25-30% of the times, according to my rough estimate).

Here's what happens during the second step (can be seen from stacktrace below):
# In CoreContainer's create(CoreDescriptor, boolean, boolean), there's a line 
{{zkSys.getZkController().preRegister(dcore);}}.
# This calls ZkController's publish(), which in turn calls CoreContainer's 
getCore() method. This call *should* return null (since previous attempt of 
core creation didn't succeed). But, it throws the exception associated with the 
previous failure.

Here's the stack trace for the same.
{code}
Caused by: org.apache.solr.common.SolrException: SolrCore 
'newcollection2_shard1_replica1' is not available due to init failure: blahblah
at org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:1312)
at org.apache.solr.cloud.ZkController.publish(ZkController.java:1225)
at 
org.apache.solr.cloud.ZkController.preRegister(ZkController.java:1399)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:945)
{code}

While working on SOLR-6736, I ran into this (nasty?) issue. I'll try to isolate 
this into a standalone test that demonstrates this issue. Otherwise, as of now, 
this can be seen in the SOLR-6736's testUploadWithScriptUpdateProcessor() test 
(which tries to re-create the collection, but sometimes fails).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Comment Edited] (SOLR-10363) ComplexPhrase WildCard Case Sensitivy problem

2017-03-26 Thread Mikhail Khludnev (JIRA)

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

Mikhail Khludnev edited comment on SOLR-10363 at 3/26/17 2:40 PM:
--

I did [^TestComplexPhraseTurkish.java], it pass. It isnt' clear so far.  


was (Author: mkhludnev):
I did [^TestComplexPhraseTurkish.java], it pass. It doesnt' clear so far.  

> ComplexPhrase WildCard Case Sensitivy problem
> -
>
> Key: SOLR-10363
> URL: https://issues.apache.org/jira/browse/SOLR-10363
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.4.1
>Reporter: Eyyub ÇİL
>  Labels: CPQP, analyzers, complexqueryparser, filterfactory, 
> wildcard
> Attachments: TestComplexPhraseTurkish.java
>
>
> I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.
> When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA", 
> {!complexphrase}SContent_tinx:"6* yaşında" , results is correct.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":104,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
> "parsedquery_toString":"\"6* YAŞINDa\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
> {!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
> according to  Case Sensitive condition.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":10,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
> "parsedquery_toString":"\"60 YAŞIND*\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> When I search without ComplexPhraseQueryParser, numbers of results are same 
> for +60 YAŞIND*+ and +60 yaşınd*+
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":56,
> "params":{
>   "q":"60 yaŞınd*",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "debugQuery":"on",
>   "_":"1490456571184"}},
>   "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"60 yaŞınd*",
> "querystring":"60 yaŞınd*",
> "parsedquery":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "parsedquery_toString":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "QParser":"LuceneQParser",
> "explain":{}}}
> {code}
> {code:xml}
>  positionIncrementGap="100">
>  
>
>   
>pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>
> 
>   
>   
> 
>   
>  pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (SOLR-10363) ComplexPhrase WildCard Case Sensitivy problem

2017-03-26 Thread Mikhail Khludnev (JIRA)

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

Mikhail Khludnev updated SOLR-10363:

Attachment: TestComplexPhraseTurkish.java

I did [^TestComplexPhraseTurkish.java], it pass. It doesnt' clear so far.  

> ComplexPhrase WildCard Case Sensitivy problem
> -
>
> Key: SOLR-10363
> URL: https://issues.apache.org/jira/browse/SOLR-10363
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.4.1
>Reporter: Eyyub ÇİL
>  Labels: CPQP, analyzers, complexqueryparser, filterfactory, 
> wildcard
> Attachments: TestComplexPhraseTurkish.java
>
>
> I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.
> When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA", 
> {!complexphrase}SContent_tinx:"6* yaşında" , results is correct.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":104,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
> "parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
> "parsedquery_toString":"\"6* YAŞINDa\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
> {!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
> according to  Case Sensitive condition.
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":10,
> "params":{
>   "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
>   "debug":"query",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "_":"1490456571184"}},
>   "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
> "parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
> "parsedquery_toString":"\"60 YAŞIND*\"",
> "QParser":"ComplexPhraseQParser"}}
> {code}
> When I search without ComplexPhraseQueryParser, numbers of results are same 
> for +60 YAŞIND*+ and +60 yaşınd*+
> {code}
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":56,
> "params":{
>   "q":"60 yaŞınd*",
>   "indent":"on",
>   "rows":"0",
>   "wt":"json",
>   "debugQuery":"on",
>   "_":"1490456571184"}},
>   "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
>   },
>   "debug":{
> "rawquerystring":"60 yaŞınd*",
> "querystring":"60 yaŞınd*",
> "parsedquery":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "parsedquery_toString":"SContent_tinx:60 SContent_tinx:yaşınd*",
> "QParser":"LuceneQParser",
> "explain":{}}}
> {code}
> {code:xml}
>  positionIncrementGap="100">
>  
>
>   
>pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>
> 
>   
>   
> 
>   
>  pattern="[^a-zA-Z0-9üğşçıiöâÜĞŞÇIİÖÂ@# ]" replacement=" " 
> replace="all"/>
>   
>   
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_121) - Build # 3153 - Unstable!

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3153/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth: 1) 
Thread[id=3463, name=jetty-launcher-491-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)   
 2) Thread[id=3468, name=jetty-launcher-491-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth: 
   1) Thread[id=3463, name=jetty-launcher-491-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 

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

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3921/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

7 tests failed.
FAILED:  org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test

Error Message:
Could not find collection:collection2

Stack Trace:
java.lang.AssertionError: Could not find collection:collection2
at 
__randomizedtesting.SeedInfo.seed([B64476C56CE709DD:3E10491FC21B6425]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:159)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:870)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:620)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

Re: GSOC2017: Call to Solr and Tika/Nutch/Camel/NiFi/Zeppelin/etc mentors

2017-03-26 Thread Dmitry Kan
Hi Alexandre,

Forwarded your call to luke's google group:
https://groups.google.com/forum/#!topic/luke-discuss/rmZo7R3gDdc

There might be a potential for solr/lucene/luke projects, like adding
capability to open solr/lucene index in luke from a remote server:
https://github.com/DmitryKey/luke/issues/68

Good luck with SOC!

Regards,
Dmitry
-- 
Dmitry Kan
Luke Toolbox: http://github.com/DmitryKey/luke
Blog: http://dmitrykan.blogspot.com
Twitter: http://twitter.com/dmitrykan

On 17 March 2017 at 16:25, Alexandre Rafalovitch  wrote:

> I am mentoring in this year's Google Summer of Code (first timer!). I
> know there is a couple of us from Solr project, but I also noticed
> some mentors from upstream/downstream projects.
>
> I am proposing that we put at least a couple of integration projects
> to improve/upgrade Solr integration with both upstream (Tika) and
> downstream (Nutch/Camel/NiFi) projects. And maybe even propose some
> new projects, such as Solr backend engine for Zeppelin (so we could
> have a Python Notebook-like interface to Solr, not just via JDBC
> bridge, we do already).
>
> I am not sure whose JIRAs they should go into, but the project idea
> tag spans all ASF projects, so it is more important to figure out
> mentor-level agreement first.
>
> In any case, to push this forward, if we get several students all
> working on Solr, I could run a Solr bootcamp class for students,
> mentors, and whoever else in the sister communities wants to
> participate and get more familiar with Solr. We could also run a
> parallel mini-list (or Gitter room or whatever) where multiple new
> implementors of Solr integrations can hang out together and progress
> together.
>
>
> Regards,
>Alex.
> P.s. I am also working on redoing Solr examples (starting from DIH
> ones at: SOLR-10311). If anybody has comments on what kind of examples
> would make integrations easier, I am very receptive.
> P.p.s. Feel free to forward this to the other mailing lists for other
> relevant sister Apache communities.
> 
> http://www.solr-start.com/ - Resources for Solr users, new and experienced
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1273 - Still Unstable

2017-03-26 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1273/

1 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsBasicDistributedZk2Test.test

Error Message:
expected:<1> but was:<0>

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([3C3F34DF0435EB87:B46B0B05AAC9867F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.BasicDistributedZk2Test.testUpdateAndDelete(BasicDistributedZk2Test.java:244)
at 
org.apache.solr.cloud.BasicDistributedZk2Test.test(BasicDistributedZk2Test.java:112)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_121) - Build # 805 - Unstable!

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/805/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestNRTOpen

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_7EFFE4305A045028-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_7EFFE4305A045028-001\init-core-data-001

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_7EFFE4305A045028-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_7EFFE4305A045028-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_7EFFE4305A045028-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_7EFFE4305A045028-001\init-core-data-001
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_7EFFE4305A045028-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_7EFFE4305A045028-001

at __randomizedtesting.SeedInfo.seed([7EFFE4305A045028]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:323)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11172 lines...]
   [junit4] Suite: org.apache.solr.core.TestNRTOpen
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_7EFFE4305A045028-001\init-core-data-001
   [junit4]   2> 299035 WARN  
(SUITE-TestNRTOpen-seed#[7EFFE4305A045028]-worker) [] o.a.s.SolrTestCaseJ4 
startTrackingSearchers: numOpens=2 numCloses=2
   [junit4]   2> 299035 INFO  
(SUITE-TestNRTOpen-seed#[7EFFE4305A045028]-worker) [] o.a.s.SolrTestCaseJ4 
Using TrieFields
   [junit4]   2> 299066 INFO  
(SUITE-TestNRTOpen-seed#[7EFFE4305A045028]-worker) [] o.a.s.SolrTestCaseJ4 
Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 299069 INFO  
(SUITE-TestNRTOpen-seed#[7EFFE4305A045028]-worker) [] o.a.s.SolrTestCaseJ4 
initCore
   [junit4]   2> 299078 INFO  
(SUITE-TestNRTOpen-seed#[7EFFE4305A045028]-worker) [] 
o.a.s.c.SolrResourceLoader [null] Added 2 libs to classloader, from paths: 
[/C:/Users/jenkins/workspace/Lucene-Solr-6.x-Windows/solr/core/src/test-files/solr/collection1/lib,
 
/C:/Users/jenkins/workspace/Lucene-Solr-6.x-Windows/solr/core/src/test-files/solr/collection1/lib/classes]
   [junit4]   2> 299218 WARN  
(SUITE-TestNRTOpen-seed#[7EFFE4305A045028]-worker) [] o.a.s.c.Config 
Beginning with Solr 5.5,  is deprecated, use  
instead.
   [junit4]   2> 299219 INFO  
(SUITE-TestNRTOpen-seed#[7EFFE4305A045028]-worker) [] o.a.s.c.SolrConfig 
Using Lucene MatchVersion: 6.6.0
   [junit4]   2> 299233 INFO  
(SUITE-TestNRTOpen-seed#[7EFFE4305A045028]-worker) [] o.a.s.s.IndexSchema 
[null] Schema name=minimal
   [junit4]   2> 299239 WARN  
(SUITE-TestNRTOpen-seed#[7EFFE4305A045028]-worker) [] o.a.s.s.IndexSchema 
no uniqueKey specified in schema.
   [junit4]   2> 299239 INFO  
(SUITE-TestNRTOpen-seed#[7EFFE4305A045028]-worker) [] o.a.s.s.IndexSchema 
Loaded schema minimal/1.1 with uniqueid field 

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_121) - Build # 6475 - Unstable!

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6475/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.update.TestInPlaceUpdatesDistrib.test

Error Message:
This doc was supposed to have been deleted, but was: SolrDocument{id=0, 
title_s=title0, id_i=0, inplace_updatable_float=1.0, 
_version_=1562915455799132160, inplace_updatable_int_with_default=666, 
inplace_updatable_float_with_default=42.0}

Stack Trace:
java.lang.AssertionError: This doc was supposed to have been deleted, but was: 
SolrDocument{id=0, title_s=title0, id_i=0, inplace_updatable_float=1.0, 
_version_=1562915455799132160, inplace_updatable_int_with_default=666, 
inplace_updatable_float_with_default=42.0}
at 
__randomizedtesting.SeedInfo.seed([B3D8CB6BC5B671ED:3B8CF4B16B4A1C15]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.reorderedDeletesTest(TestInPlaceUpdatesDistrib.java:732)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:168)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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)

[jira] [Created] (SOLR-10364) Solr bean binding only support List and Map?

2017-03-26 Thread Huaping Gu (JIRA)
Huaping Gu created SOLR-10364:
-

 Summary: Solr bean binding only support List and Map?
 Key: SOLR-10364
 URL: https://issues.apache.org/jira/browse/SOLR-10364
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrJ
Affects Versions: 6.4.2, 4.10.4
Reporter: Huaping Gu
 Fix For: 4.10.4


In class DocumentObjectBinder.java, when jnject a value from doc to bean class, 
seems it only support List and Map, and not support Set. In Cassandra the 
collection types includes "set" which Cassandra Java Driver treat it as 
LinkedHashSet. 

I have a column defined type set. And in the Java Pojo, I set it as 
Set.

It will success in Cassandra binding, but fail in Solr with following error:
Caused by: java.lang.IllegalArgumentException: Can not set java.util.Set field 
com.xxx. to java.util.ArrayList

But If I set it Pojo to List, Solr binding will success, but Cassandra 
will fail and give me error as bellow:
argument type mismatch - had objects of type "java.util.LinkedHashSet" but 
expected signature "java.util.List"

I believe following code may need an update? Which only care about List and Map.

 void inject(T obj, SolrDocument sdoc) {
  Object val = getFieldValue(sdoc);
  if(val == null) {
return;
  }

  if (isArray && !isContainedInMap) {
List list;
if (val.getClass().isArray()) {
  set(obj, val);
  return;
} else if (val instanceof List) {
  list = (List) val;
} else {
  list = new ArrayList();
  list.add(val);
}
set(obj, list.toArray((Object[]) Array.newInstance(type, list.size(;
  } else if (isList && !isContainedInMap) {
if (!(val instanceof List)) {
  List list = new ArrayList();
  list.add(val);
  val =  list;
}
set(obj, val);
  } else if (isContainedInMap) {
if (val instanceof Map) {
  set(obj,  val);
}
  } else {
set(obj, val);
  }

}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (SOLR-10363) ComplexPhrase WildCard Case Sensitivy problem

2017-03-26 Thread JIRA

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

Eyyub ÇİL updated SOLR-10363:
-
Description: 
I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.

When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA", 

{!complexphrase}SContent_tinx:"6* yaşında" , results is correct.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":104,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
"parsedquery_toString":"\"6* YAŞINDa\"",
"QParser":"ComplexPhraseQParser"}}
{code}

But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
{!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
according to  Case Sensitive condition.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":10,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
"parsedquery_toString":"\"60 YAŞIND*\"",
"QParser":"ComplexPhraseQParser"}}
{code}


When I search without ComplexPhraseQueryParser, numbers of results are same for 
+60 YAŞIND*+ and +60 yaşınd*+


{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":56,
"params":{
  "q":"60 yaŞınd*",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "debugQuery":"on",
  "_":"1490456571184"}},
  "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
  },
  "debug":{
"rawquerystring":"60 yaŞınd*",
"querystring":"60 yaŞınd*",
"parsedquery":"SContent_tinx:60 SContent_tinx:yaşınd*",
"parsedquery_toString":"SContent_tinx:60 SContent_tinx:yaşınd*",
"QParser":"LuceneQParser",
"explain":{}}}
{code}

{code:xml}

 
   




 


  




  
  

{code}

  was:
I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.

When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA", 

{!complexphrase}SContent_tinx:"6* yaşında", results is correct.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":104,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
"parsedquery_toString":"\"6* YAŞINDa\"",
"QParser":"ComplexPhraseQParser"}}
{code}

But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
{!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
according to  Case Sensitive condition.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":10,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
"parsedquery_toString":"\"60 YAŞIND*\"",
"QParser":"ComplexPhraseQParser"}}
{code}


When I search without ComplexPhraseQueryParser, numbers of results are same for 
+60 YAŞIND*+ and +60 yaşınd*+


{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":56,
"params":{
  "q":"60 yaŞınd*",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "debugQuery":"on",
  "_":"1490456571184"}},
  "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
  },
  "debug":{
"rawquerystring":"60 yaŞınd*",
"querystring":"60 yaŞınd*",
"parsedquery":"SContent_tinx:60 

[jira] [Updated] (SOLR-10363) ComplexPhrase WildCard Case Sensitivy problem

2017-03-26 Thread JIRA

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

Eyyub ÇİL updated SOLR-10363:
-
Description: 
I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.

When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA", 
{!complexphrase}SContent_tinx:"6* yaşında", results is correct.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":104,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
"parsedquery_toString":"\"6* YAŞINDa\"",
"QParser":"ComplexPhraseQParser"}}
{code}

But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
{!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
according to  Case Sensitive condition.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":10,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
"parsedquery_toString":"\"60 YAŞIND*\"",
"QParser":"ComplexPhraseQParser"}}
{code}


When I search without ComplexPhraseQueryParser, numbers of results are same for 
+60 YAŞIND*+ and +60 yaşınd*+


{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":56,
"params":{
  "q":"60 yaŞınd*",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "debugQuery":"on",
  "_":"1490456571184"}},
  "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
  },
  "debug":{
"rawquerystring":"60 yaŞınd*",
"querystring":"60 yaŞınd*",
"parsedquery":"SContent_tinx:60 SContent_tinx:yaşınd*",
"parsedquery_toString":"SContent_tinx:60 SContent_tinx:yaşınd*",
"QParser":"LuceneQParser",
"explain":{}}}
{code}

{code:xml}

 
   




 


  




  
  

{code}

  was:
I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.

When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA",
{!complexphrase}SContent_tinx:"6* yaşında", results is correct.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":104,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
"parsedquery_toString":"\"6* YAŞINDa\"",
"QParser":"ComplexPhraseQParser"}}
{code}

But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
{!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
according to  Case Sensitive condition.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":10,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
"parsedquery_toString":"\"60 YAŞIND*\"",
"QParser":"ComplexPhraseQParser"}}
{code}


When I search without ComplexPhraseQueryParser, numbers of results are same for 
+60 YAŞIND*+ and +60 yaşınd*+


{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":56,
"params":{
  "q":"60 yaŞınd*",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "debugQuery":"on",
  "_":"1490456571184"}},
  "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
  },
  "debug":{
"rawquerystring":"60 yaŞınd*",
"querystring":"60 yaŞınd*",
"parsedquery":"SContent_tinx:60 

[jira] [Updated] (SOLR-10363) ComplexPhrase WildCard Case Sensitivy problem

2017-03-26 Thread JIRA

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

Eyyub ÇİL updated SOLR-10363:
-
Description: 
I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.

When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA", 

{!complexphrase}SContent_tinx:"6* yaşında", results is correct.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":104,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
"parsedquery_toString":"\"6* YAŞINDa\"",
"QParser":"ComplexPhraseQParser"}}
{code}

But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
{!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
according to  Case Sensitive condition.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":10,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
"parsedquery_toString":"\"60 YAŞIND*\"",
"QParser":"ComplexPhraseQParser"}}
{code}


When I search without ComplexPhraseQueryParser, numbers of results are same for 
+60 YAŞIND*+ and +60 yaşınd*+


{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":56,
"params":{
  "q":"60 yaŞınd*",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "debugQuery":"on",
  "_":"1490456571184"}},
  "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
  },
  "debug":{
"rawquerystring":"60 yaŞınd*",
"querystring":"60 yaŞınd*",
"parsedquery":"SContent_tinx:60 SContent_tinx:yaşınd*",
"parsedquery_toString":"SContent_tinx:60 SContent_tinx:yaşınd*",
"QParser":"LuceneQParser",
"explain":{}}}
{code}

{code:xml}

 
   




 


  




  
  

{code}

  was:
I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.

When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA", 
{!complexphrase}SContent_tinx:"6* yaşında", results is correct.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":104,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
"parsedquery_toString":"\"6* YAŞINDa\"",
"QParser":"ComplexPhraseQParser"}}
{code}

But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
{!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
according to  Case Sensitive condition.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":10,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
"parsedquery_toString":"\"60 YAŞIND*\"",
"QParser":"ComplexPhraseQParser"}}
{code}


When I search without ComplexPhraseQueryParser, numbers of results are same for 
+60 YAŞIND*+ and +60 yaşınd*+


{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":56,
"params":{
  "q":"60 yaŞınd*",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "debugQuery":"on",
  "_":"1490456571184"}},
  "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
  },
  "debug":{
"rawquerystring":"60 yaŞınd*",
"querystring":"60 yaŞınd*",
"parsedquery":"SContent_tinx:60 

[jira] [Updated] (SOLR-10363) ComplexPhrase WildCard Case Sensitivy problem

2017-03-26 Thread JIRA

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

Eyyub ÇİL updated SOLR-10363:
-
Description: 
I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.

When I search like {!complexphrase}SContent_tinx:"6* YAŞINDA",
{!complexphrase}SContent_tinx:"6* yaşında", results is correct.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":104,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
"parsedquery_toString":"\"6* YAŞINDa\"",
"QParser":"ComplexPhraseQParser"}}
{code}

But If I want to search like {!complexphrase}SContent_tinx:"60 YAŞIND*" or 
{!complexphrase}SContent_tinx:"60 yaşınd*", NumFound is 0 or result changes 
according to  Case Sensitive condition.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":10,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
"parsedquery_toString":"\"60 YAŞIND*\"",
"QParser":"ComplexPhraseQParser"}}
{code}


When I search without ComplexPhraseQueryParser, numbers of results are same for 
+60 YAŞIND*+ and +60 yaşınd*+


{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":56,
"params":{
  "q":"60 yaŞınd*",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "debugQuery":"on",
  "_":"1490456571184"}},
  "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
  },
  "debug":{
"rawquerystring":"60 yaŞınd*",
"querystring":"60 yaŞınd*",
"parsedquery":"SContent_tinx:60 SContent_tinx:yaşınd*",
"parsedquery_toString":"SContent_tinx:60 SContent_tinx:yaşınd*",
"QParser":"LuceneQParser",
"explain":{}}}
{code}

{code:xml}

 
   




 


  




  
  

{code}

  was:
I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.

When I search like +{!complexphrase}SContent_tinx:"6* YAŞINDA"+,
+{!complexphrase}SContent_tinx:"6* yaşında"+, results is correct.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":104,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
"parsedquery_toString":"\"6* YAŞINDa\"",
"QParser":"ComplexPhraseQParser"}}
{code}

But If I want to search like +{!complexphrase}SContent_tinx:"60 YAŞIND*"+ or + 
{!complexphrase}SContent_tinx:"60 yaşınd*"+, NumFound is 0 or result changes 
according to  Case Sensitive condition.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":10,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
"parsedquery_toString":"\"60 YAŞIND*\"",
"QParser":"ComplexPhraseQParser"}}
{code}


When I search without ComplexPhraseQueryParser, numbers of results are same for 
+60 YAŞIND*+ and +60 yaşınd*+


{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":56,
"params":{
  "q":"60 yaŞınd*",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "debugQuery":"on",
  "_":"1490456571184"}},
  "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
  },
  "debug":{
"rawquerystring":"60 yaŞınd*",
"querystring":"60 yaŞınd*",

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+162) - Build # 19262 - Unstable!

2017-03-26 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19262/
Java: 64bit/jdk-9-ea+162 -XX:+UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.SolrCloudExampleTest

Error Message:
ObjectTracker found 6 object(s) that were not released!!! [TransactionLog, 
MockDirectoryWrapper, MockDirectoryWrapper, SolrIndexSearcher, 
MockDirectoryWrapper, MDCAwareThreadPoolExecutor] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.TransactionLog  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.update.TransactionLog.(TransactionLog.java:190)  at 
org.apache.solr.update.UpdateLog.newTransactionLog(UpdateLog.java:438)  at 
org.apache.solr.update.UpdateLog.ensureLog(UpdateLog.java:1250)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:524)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:509)  at 
org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:335)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:254)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:204)
  at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:992)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1208)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:754)
  at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:336)
  at 
org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:98)  
at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:187)
  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:143)
  at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:313) 
 at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:258)  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:129)
  at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:278) 
 at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:258)  at 
org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:180)  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:194)
  at 
org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:108)
  at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:55)  
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
  at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2464)  at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:722)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:528)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 

[jira] [Created] (SOLR-10363) ComplexPhrase WildCard Case Sensitivy problem

2017-03-26 Thread JIRA
Eyyub ÇİL created SOLR-10363:


 Summary: ComplexPhrase WildCard Case Sensitivy problem
 Key: SOLR-10363
 URL: https://issues.apache.org/jira/browse/SOLR-10363
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: query parsers
Affects Versions: 6.4.1
Reporter: Eyyub ÇİL


I encounter a problem with ComplexPhrase and TurkishLowerCaseFilterFactory.

When I search like +{!complexphrase}SContent_tinx:"6* YAŞINDA"+,
+{!complexphrase}SContent_tinx:"6* yaşında"+, results is correct.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":104,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":15,"start":0,"maxScore":5972.9,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"querystring":"{!complexphrase}SContent_tinx:\"6* YAŞINDa\"",
"parsedquery":"ComplexPhraseQuery(\"6* YAŞINDa\")",
"parsedquery_toString":"\"6* YAŞINDa\"",
"QParser":"ComplexPhraseQParser"}}
{code}

But If I want to search like +{!complexphrase}SContent_tinx:"60 YAŞIND*"+ or + 
{!complexphrase}SContent_tinx:"60 yaşınd*"+, NumFound is 0 or result changes 
according to  Case Sensitive condition.
{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":10,
"params":{
  "q":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
  "debug":"query",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "_":"1490456571184"}},
  "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
  },
  "debug":{
"rawquerystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"querystring":"{!complexphrase}SContent_tinx:\"60 YAŞIND*\"",
"parsedquery":"ComplexPhraseQuery(\"60 YAŞIND*\")",
"parsedquery_toString":"\"60 YAŞIND*\"",
"QParser":"ComplexPhraseQParser"}}
{code}


When I search without ComplexPhraseQueryParser, numbers of results are same for 
+60 YAŞIND*+ and +60 yaşınd*+


{code}
{
  "responseHeader":{
"zkConnected":true,
"status":0,
"QTime":56,
"params":{
  "q":"60 yaŞınd*",
  "indent":"on",
  "rows":"0",
  "wt":"json",
  "debugQuery":"on",
  "_":"1490456571184"}},
  "response":{"numFound":776,"start":0,"maxScore":7.633286,"docs":[]
  },
  "debug":{
"rawquerystring":"60 yaŞınd*",
"querystring":"60 yaŞınd*",
"parsedquery":"SContent_tinx:60 SContent_tinx:yaşınd*",
"parsedquery_toString":"SContent_tinx:60 SContent_tinx:yaşınd*",
"QParser":"LuceneQParser",
"explain":{}}}
{code}

{code:xml}

 
   




 


  




  
  

{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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