[jira] [Created] (SOLR-9373) Add the constructor with no argument to SolrInputDocument

[Minoru Osuka (JIRA)]

Minoru Osuka created SOLR-9373:
--

 Summary: Add the constructor with no argument to SolrInputDocument
 Key: SOLR-9373
 URL: https://issues.apache.org/jira/browse/SOLR-9373
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrJ
Affects Versions: 6.1
Reporter: Minoru Osuka


I'm working on create a patch to upgrade Solr 6.0.1 for Flume.

Issue : https://issues.apache.org/jira/browse/FLUME-2919

Since Solr 6.1.0 has been released, I'm trying to create a patch to upgrade 
6.1.0 again.
But, java.lang.NoSuchMethodError occurs at compile time owing to the 
constructor with no argument has been removed from the SolrInputDocument by 
SOLR-9065.

{noformat}
Caused by: java.lang.NoSuchMethodError: 
org.apache.solr.common.SolrInputDocument: method ()V not found
  at 
org.apache.solr.handler.extraction.SolrContentHandler.(SolrContentHandler.java:90)
  at 
org.apache.solr.morphlines.cell.TrimSolrContentHandlerFactory$TrimSolrContentHandler.(TrimSolrContentHandlerFactory.java:50)
  at 
org.apache.solr.morphlines.cell.TrimSolrContentHandlerFactory.createSolrContentHandler(TrimSolrContentHandlerFactory.java:40)
  at 
org.apache.solr.morphlines.cell.SolrCellBuilder$SolrCell.doProcess(SolrCellBuilder.java:232)
  at 
org.kitesdk.morphline.stdio.AbstractParser.doProcess(AbstractParser.java:96)
  at 
org.kitesdk.morphline.base.AbstractCommand.process(AbstractCommand.java:156)
  at org.kitesdk.morphline.base.Connector.process(Connector.java:64)
  at 
org.kitesdk.morphline.base.AbstractCommand.doProcess(AbstractCommand.java:181)
  at org.kitesdk.morphline.stdlib.LogCommand.doProcess(LogCommand.java:56)
  at 
org.kitesdk.morphline.stdlib.LogDebugBuilder$LogDebug.doProcess(LogDebugBuilder.java:56)
  at 
org.kitesdk.morphline.base.AbstractCommand.process(AbstractCommand.java:156)
  at 
org.kitesdk.morphline.stdlib.TryRulesBuilder$TryRules.doProcess(TryRulesBuilder.java:115)
  at 
org.kitesdk.morphline.base.AbstractCommand.process(AbstractCommand.java:156)
  at org.kitesdk.morphline.base.Connector.process(Connector.java:64)
  at 
org.kitesdk.morphline.base.AbstractCommand.doProcess(AbstractCommand.java:181)
  at 
org.kitesdk.morphline.tika.DetectMimeTypeBuilder$DetectMimeType.doProcess(DetectMimeTypeBuilder.java:166)
  at 
org.kitesdk.morphline.base.AbstractCommand.process(AbstractCommand.java:156)
  at org.kitesdk.morphline.base.Connector.process(Connector.java:64)
  at 
org.kitesdk.morphline.scriptengine.java.scripts.MyJavaClass6.eval(MyJavaClass6.java:15)
  ... 69 more
{noformat}

It could not invoke the constructor with variable arguments using java 
reflection. Please restore the no arguments constructor to SolrInputDocument.




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

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

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9310:
---

Yeah, it was better before. Except for the fact that it didn't work. 

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: PeerSync_Experiment.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1352/
Java: 32bit/jdk-9-ea+129 -client -XX:+UseSerialGC

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

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:36487/f_v/f/c8n_1x3_lf_shard1_replica3]

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: No live 
SolrServers available to handle this 
request:[http://127.0.0.1:36487/f_v/f/c8n_1x3_lf_shard1_replica3]
at 
__randomizedtesting.SeedInfo.seed([4BF62F05F56A804C:C3A210DF5B96EDB4]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:592)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:578)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:174)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_102) - Build # 6024 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6024/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
java.lang.NullPointerException

Stack Trace:
com.google.common.util.concurrent.UncheckedExecutionException: 
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([EADD8743D450719D]:0)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2263)
at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
at 
com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
at org.apache.hadoop.security.Groups.getGroups(Groups.java:182)
at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.getUsersFirstGroup(TestSolrCloudWithSecureImpersonation.java:60)
at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.getImpersonatorSettings(TestSolrCloudWithSecureImpersonation.java:74)
at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.startup(TestSolrCloudWithSecureImpersonation.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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1012)
at org.apache.hadoop.util.Shell.runCommand(Shell.java:483)
at org.apache.hadoop.util.Shell.run(Shell.java:456)
at 
org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:722)
at org.apache.hadoop.util.Shell.execCommand(Shell.java:815)
at org.apache.hadoop.util.Shell.execCommand(Shell.java:798)
at 
org.apache.hadoop.security.ShellBasedUnixGroupsMapping.getUnixGroups(ShellBasedUnixGroupsMapping.java:84)
at 
org.apache.hadoop.security.ShellBasedUnixGroupsMapping.getGroups(ShellBasedUnixGroupsMapping.java:52)
at 
org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback.getGroups(JniBasedUnixGroupsMappingWithFallback.java:51)
at 
org.apache.hadoop.security.Groups$GroupCacheLoader.fetchGroupList(Groups.java:239)
at 
org.apache.hadoop.security.Groups$GroupCacheLoader.load(Groups.java:220)
at 
org.apache.hadoop.security.Groups$GroupCacheLoader.load(Groups.java:208)
at 
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
at 
com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17445/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.cloud.DistributedQueueTest.testPeekElements

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([9A1372CD3FC0BCB1:673DC8ECEFF9E8AC]: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.DistributedQueueTest.testPeekElements(DistributedQueueTest.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.testProxyValidateHost

Error Message:
Error from server at 

[jira] [Updated] (SOLR-9252) Feature selection and logistic regression on text

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-9252:
---
Attachment: SOLR-9252.patch

Updated patch which correct the test for textLogitStream.

[~joel.bernstein] In this patch, the testRecord is built from string.

> Feature selection and logistic regression on text
> -
>
> Key: SOLR-9252
> URL: https://issues.apache.org/jira/browse/SOLR-9252
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Joel Bernstein
> Attachments: SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, enron1.zip
>
>
> SOLR-9186 come up with a challenges that for each iterative we have to 
> rebuild the tf-idf vector for each documents. It is costly computation if we 
> represent doc by a lot of terms. Features selection can help reducing the 
> computation.
> Due to its computational efficiency and simple interpretation, information 
> gain is one of the most popular feature selection methods. It is used to 
> measure the dependence between features and labels and calculates the 
> information gain between the i-th feature and the class labels 
> (http://www.jiliang.xyz/publication/feature_selection_for_classification.pdf).
> I confirmed that by running logistics regressions on enron mail dataset (in 
> which each email is represented by top 100 terms that have highest 
> information gain) and got the accuracy by 92% and precision by 82%.
> This ticket will create two new streaming expression. Both of them use the 
> same *parallel iterative framework* as SOLR-8492.
> {code}
> featuresSelection(collection1, q="*:*",  field="tv_text", outcome="out_i", 
> positiveLabel=1, numTerms=100)
> {code}
> featuresSelection will emit top terms that have highest information gain 
> scores. It can be combined with new tlogit stream.
> {code}
> tlogit(collection1, q="*:*",
>  featuresSelection(collection1, 
>   q="*:*",  
>   field="tv_text", 
>   outcome="out_i", 
>   positiveLabel=1, 
>   numTerms=100),
>  field="tv_text",
>  outcome="out_i",
>  maxIterations=100)
> {code}
> In the iteration n, the text logistics regression will emit nth model, and 
> compute the error of (n-1)th model. Because the error will be wrong if we 
> compute the error dynamically in each iteration. 
> In each iteration tlogit will change learning rate based on error of previous 
> iteration. It will increase the learning rate by 5% if error is going down 
> and It will decrease the learning rate by 50% if error is going up.
> This will support use cases such as building models for spam detection, 
> sentiment analysis and threat detection. 



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/306/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

4 tests failed.
FAILED:  org.apache.solr.cloud.TestReplicaProperties.test

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:37899 within 3 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:37899 within 3 ms
at 
__randomizedtesting.SeedInfo.seed([DF45F7F35B955D02:5711C829F56930FA]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:181)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:115)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:110)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:97)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.printLayout(AbstractDistribZkTestBase.java:295)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.distribTearDown(AbstractFullDistribZkTestBase.java:1500)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:969)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.concurrent.TimeoutException: Could not connect to 
ZooKeeper 127.0.0.1:37899 within 3 ms
at 
org.apache.solr.common.cloud.ConnectionManager.waitForConnected(ConnectionManager.java:235)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:173)
... 37 more


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

Error 

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 134 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/134/

3 tests failed.
FAILED:  org.apache.solr.cloud.TestRandomRequestDistribution.test

Error Message:
Shard a1x2_shard1_replica1 received all 10 requests

Stack Trace:
java.lang.AssertionError: Shard a1x2_shard1_replica1 received all 10 requests
at 
__randomizedtesting.SeedInfo.seed([146FB096C07DA498:9C3B8F4C6E81C960]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking(TestRandomRequestDistribution.java:121)
at 
org.apache.solr.cloud.TestRandomRequestDistribution.test(TestRandomRequestDistribution.java:65)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (SOLR-9314) Add all known transformers to TestRandomFlRTGCloud and fix any bugs found

[Hoss Man (JIRA)]

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

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

Updated patch to include a "testCoverage" that compares what validators we have 
with {{TransformerFactory.defaultFactories}} and a new RawFieldValueValidator 
for testing the {{\[json\]}} and {{\[xml\]}} transformers (backed by 
RawValueTransformerFactory)

There's currently test failures related to RawFieldValueValidator -- i haven't 
dug in in depth, but it doesn't look like a test bug, it might be an actual bug 
in RawValueTransformerFactory when dealing with uncommited docs -- need to do 
some manual testing to sanity check.  (I skimmed teh code in 
RawValueTransformerFactory but nothing jumped out at me)

> Add all known transformers to TestRandomFlRTGCloud and fix any bugs found
> -
>
> Key: SOLR-9314
> URL: https://issues.apache.org/jira/browse/SOLR-9314
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-9314.patch, SOLR-9314.patch
>
>
> SOLR-9285 is/has added a new TestRandomFlRTGCloud for testing out random 
> permutations of {{fl}} params in RTG requests.
> simple field names, field renames, field globs, and ValueSources/functions 
> are already tested -- adding additional DocTransformers is fairly straight 
> forward by implementing a simple FlValidator.
> This issue is being filed to track the work needed to:
> * review the list of all DocTransformers in solr and add test coverage of 
> them in this method
> * file any blocker issues if new bugs are found in this process
> * once all DocTransformers are accounted for, update TestRandomFlRTGCloud to 
> programatically compare the list of FlValidator's it knows about with the 
> list of all DocTransformers (similar to how 
> QueryEqualityTest.testParserCoverage works) to fail the test if anyone adds a 
> DocTransformer w/o adding corisponding test coverage to this class.



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/757/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

5 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:39068 within 3 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:39068 within 3 ms
at 
__randomizedtesting.SeedInfo.seed([5632931F0444CE97:DE66ACC5AAB8A36F]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:181)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:115)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:110)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:97)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.printLayout(AbstractDistribZkTestBase.java:295)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.distribTearDown(AbstractFullDistribZkTestBase.java:1500)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:962)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.concurrent.TimeoutException: Could not connect to 
ZooKeeper 127.0.0.1:39068 within 3 ms
at 
org.apache.solr.common.cloud.ConnectionManager.waitForConnected(ConnectionManager.java:235)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:173)
... 37 more


FAILED:  

[jira] [Updated] (SOLR-9252) Feature selection and logistic regression on text

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9252:
-
Attachment: SOLR-9252.patch

New patch that asserts the order of terms in the feature selection test.

Also removes the terms parameter from the TextLogitStream and requires a 
features stream.

> Feature selection and logistic regression on text
> -
>
> Key: SOLR-9252
> URL: https://issues.apache.org/jira/browse/SOLR-9252
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Joel Bernstein
> Attachments: SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, SOLR-9252.patch, enron1.zip
>
>
> SOLR-9186 come up with a challenges that for each iterative we have to 
> rebuild the tf-idf vector for each documents. It is costly computation if we 
> represent doc by a lot of terms. Features selection can help reducing the 
> computation.
> Due to its computational efficiency and simple interpretation, information 
> gain is one of the most popular feature selection methods. It is used to 
> measure the dependence between features and labels and calculates the 
> information gain between the i-th feature and the class labels 
> (http://www.jiliang.xyz/publication/feature_selection_for_classification.pdf).
> I confirmed that by running logistics regressions on enron mail dataset (in 
> which each email is represented by top 100 terms that have highest 
> information gain) and got the accuracy by 92% and precision by 82%.
> This ticket will create two new streaming expression. Both of them use the 
> same *parallel iterative framework* as SOLR-8492.
> {code}
> featuresSelection(collection1, q="*:*",  field="tv_text", outcome="out_i", 
> positiveLabel=1, numTerms=100)
> {code}
> featuresSelection will emit top terms that have highest information gain 
> scores. It can be combined with new tlogit stream.
> {code}
> tlogit(collection1, q="*:*",
>  featuresSelection(collection1, 
>   q="*:*",  
>   field="tv_text", 
>   outcome="out_i", 
>   positiveLabel=1, 
>   numTerms=100),
>  field="tv_text",
>  outcome="out_i",
>  maxIterations=100)
> {code}
> In the iteration n, the text logistics regression will emit nth model, and 
> compute the error of (n-1)th model. Because the error will be wrong if we 
> compute the error dynamically in each iteration. 
> In each iteration tlogit will change learning rate based on error of previous 
> iteration. It will increase the learning rate by 5% if error is going down 
> and It will decrease the learning rate by 50% if error is going up.
> This will support use cases such as building models for spam detection, 
> sentiment analysis and threat detection. 



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17444/
Java: 64bit/jdk-9-ea+129 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.testProxyValidateHost

Error Message:
Error from server at https://127.0.0.1:36761/solr: Expected mime type 
application/octet-stream but got application/json. {   "RemoteException" : {
 "message" : "Unauthorized connection for super-user: localHostAnyGroup from IP 
localhost.localdomain", "exception" : "AuthorizationException", 
"javaClassName" : "org.apache.hadoop.security.authorize.AuthorizationException" 
  } }

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:36761/solr: Expected mime type 
application/octet-stream but got application/json. {
  "RemoteException" : {
"message" : "Unauthorized connection for super-user: localHostAnyGroup from 
IP localhost.localdomain",
"exception" : "AuthorizationException",
"javaClassName" : 
"org.apache.hadoop.security.authorize.AuthorizationException"
  }
}
at 
__randomizedtesting.SeedInfo.seed([30B88F3112F16917:D5464FC017B63DA0]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:576)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.testProxyValidateHost(TestSolrCloudWithSecureImpersonation.java:260)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (SOLR-9372) Different data types returned depending on the aggregation mode used to execute a SQL statement

[Timothy Potter (JIRA)]

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

Timothy Potter updated SOLR-9372:
-
Component/s: Parallell SQL

> Different data types returned depending on the aggregation mode used to 
> execute a SQL statement
> ---
>
> Key: SOLR-9372
> URL: https://issues.apache.org/jira/browse/SOLR-9372
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallell SQL
>Affects Versions: 6.1
>Reporter: Timothy Potter
>  Labels: sql
>
> The type of aggregation fields returned differs based on the aggregation 
> mode. Here's an example:
> {code}
> curl --data-urlencode 'stmt=SELECT movie_id, COUNT(*) as agg_count, 
> avg(rating) as avg_rating, sum(rating) as sum_rating, min(rating) as 
> min_rating, max(rating) as max_rating FROM movielens_ratings GROUP BY 
> movie_id ORDER BY movie_id asc' 
> "http://localhost:8984/solr/movielens_ratings/sql?aggregationMode=facet;
> {"result-set":{"docs":[
> {"min_rating":1.0,"avg_rating":3.8783185840707963,"sum_rating":1753.0,"movie_id":"1","agg_count":452,"max_rating":5.0},
> {"min_rating":1.0,"avg_rating":3.831460674157303,"sum_rating":341.0,"movie_id":"10","agg_count":89,"max_rating":5.0},
> {"min_rating":1.0,"avg_rating":4.155511811023622,"sum_rating":2111.0,"movie_id":"100","agg_count":508,"max_rating":5.0},
> {"min_rating":2.0,"avg_rating":3.0,"sum_rating":30.0,"movie_id":"1000","agg_count":10,"max_rating":4.0},
> {"min_rating":1.0,"avg_rating":2.0,"sum_rating":34.0,"movie_id":"1001","agg_count":17,"max_rating":5.0},
> {"min_rating":1.0,"avg_rating":1.875,"sum_rating":15.0,"movie_id":"1002","agg_count":8,"max_rating":4.0},
> {"min_rating":1.0,"avg_rating":2.25,"sum_rating":18.0,"movie_id":"1003","agg_count":8,"max_rating":4.0},
> ...
> {code}
> {code}
> curl --data-urlencode 'stmt=SELECT movie_id, COUNT(*) as agg_count, 
> avg(rating) as avg_rating, sum(rating) as sum_rating, min(rating) as 
> min_rating, max(rating) as max_rating FROM movielens_ratings GROUP BY 
> movie_id ORDER BY movie_id asc' 
> "http://localhost:8984/solr/movielens_ratings/sql?aggregationMode=map_reduce;
> {"result-set":{"docs":[
> {"min_rating":1,"avg_rating":3.8783185840707963,"sum_rating":1753,"movie_id":"1","agg_count":452,"max_rating":5},
> {"min_rating":1,"avg_rating":3.831460674157303,"sum_rating":341,"movie_id":"10","agg_count":89,"max_rating":5},
> {"min_rating":1,"avg_rating":4.155511811023622,"sum_rating":2111,"movie_id":"100","agg_count":508,"max_rating":5},
> {"min_rating":2,"avg_rating":3.0,"sum_rating":30,"movie_id":"1000","agg_count":10,"max_rating":4},
> {"min_rating":1,"avg_rating":2.0,"sum_rating":34,"movie_id":"1001","agg_count":17,"max_rating":5},
> {"min_rating":1,"avg_rating":1.875,"sum_rating":15,"movie_id":"1002","agg_count":8,"max_rating":4},
> {"min_rating":1,"avg_rating":2.25,"sum_rating":18,"movie_id":"1003","agg_count":8,"max_rating":4},
> {"min_rating":1,"avg_rating":3.111,"sum_rating":28,"movie_id":"1004","agg_count":9,"max_rating":4},
> {"min_rating":1,"avg_rating":3.6818181818181817,"sum_rating":81,"movie_id":"1005","agg_count":22,"max_rating":5},
> {code}
> The rating field is an integer in Solr (TrieIntField) so one would expect the 
> sum, min, max functions to return Long type but when using 
> aggregationMode=facet, we get back doubles. Data types should be consistent 
> so client applications don't have to account for this weirdness.



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

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

[jira] [Created] (SOLR-9372) Different data types returned depending on the aggregation mode used to execute a SQL statement

[Timothy Potter (JIRA)]

Timothy Potter created SOLR-9372:


 Summary: Different data types returned depending on the 
aggregation mode used to execute a SQL statement
 Key: SOLR-9372
 URL: https://issues.apache.org/jira/browse/SOLR-9372
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.1
Reporter: Timothy Potter


The type of aggregation fields returned differs based on the aggregation mode. 
Here's an example:

{code}
curl --data-urlencode 'stmt=SELECT movie_id, COUNT(*) as agg_count, avg(rating) 
as avg_rating, sum(rating) as sum_rating, min(rating) as min_rating, 
max(rating) as max_rating FROM movielens_ratings GROUP BY movie_id ORDER BY 
movie_id asc' 
"http://localhost:8984/solr/movielens_ratings/sql?aggregationMode=facet;
{"result-set":{"docs":[
{"min_rating":1.0,"avg_rating":3.8783185840707963,"sum_rating":1753.0,"movie_id":"1","agg_count":452,"max_rating":5.0},
{"min_rating":1.0,"avg_rating":3.831460674157303,"sum_rating":341.0,"movie_id":"10","agg_count":89,"max_rating":5.0},
{"min_rating":1.0,"avg_rating":4.155511811023622,"sum_rating":2111.0,"movie_id":"100","agg_count":508,"max_rating":5.0},
{"min_rating":2.0,"avg_rating":3.0,"sum_rating":30.0,"movie_id":"1000","agg_count":10,"max_rating":4.0},
{"min_rating":1.0,"avg_rating":2.0,"sum_rating":34.0,"movie_id":"1001","agg_count":17,"max_rating":5.0},
{"min_rating":1.0,"avg_rating":1.875,"sum_rating":15.0,"movie_id":"1002","agg_count":8,"max_rating":4.0},
{"min_rating":1.0,"avg_rating":2.25,"sum_rating":18.0,"movie_id":"1003","agg_count":8,"max_rating":4.0},
...
{code}

{code}
curl --data-urlencode 'stmt=SELECT movie_id, COUNT(*) as agg_count, avg(rating) 
as avg_rating, sum(rating) as sum_rating, min(rating) as min_rating, 
max(rating) as max_rating FROM movielens_ratings GROUP BY movie_id ORDER BY 
movie_id asc' 
"http://localhost:8984/solr/movielens_ratings/sql?aggregationMode=map_reduce;
{"result-set":{"docs":[
{"min_rating":1,"avg_rating":3.8783185840707963,"sum_rating":1753,"movie_id":"1","agg_count":452,"max_rating":5},
{"min_rating":1,"avg_rating":3.831460674157303,"sum_rating":341,"movie_id":"10","agg_count":89,"max_rating":5},
{"min_rating":1,"avg_rating":4.155511811023622,"sum_rating":2111,"movie_id":"100","agg_count":508,"max_rating":5},
{"min_rating":2,"avg_rating":3.0,"sum_rating":30,"movie_id":"1000","agg_count":10,"max_rating":4},
{"min_rating":1,"avg_rating":2.0,"sum_rating":34,"movie_id":"1001","agg_count":17,"max_rating":5},
{"min_rating":1,"avg_rating":1.875,"sum_rating":15,"movie_id":"1002","agg_count":8,"max_rating":4},
{"min_rating":1,"avg_rating":2.25,"sum_rating":18,"movie_id":"1003","agg_count":8,"max_rating":4},
{"min_rating":1,"avg_rating":3.111,"sum_rating":28,"movie_id":"1004","agg_count":9,"max_rating":4},
{"min_rating":1,"avg_rating":3.6818181818181817,"sum_rating":81,"movie_id":"1005","agg_count":22,"max_rating":5},
{code}

The rating field is an integer in Solr (TrieIntField) so one would expect the 
sum, min, max functions to return Long type but when using 
aggregationMode=facet, we get back doubles. Data types should be consistent so 
client applications don't have to account for this weirdness.



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

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

[jira] [Commented] (SOLR-9324) Support Secure Impersonation / Proxy User for solr authentication

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9324: Fix jira number in CHANGES.txt


> Support Secure Impersonation / Proxy User for solr authentication
> -
>
> Key: SOLR-9324
> URL: https://issues.apache.org/jira/browse/SOLR-9324
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Attachments: SOLR-9324.patch, SOLR-9324.patch, SOLR-9324.patch, 
> SOLR-9324_branch_6x.patch
>
>
> Solr should support Proxy User / Secure Impersonation for authentication, as 
> supported by hadoop 
> (http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Superusers.html)
>  and supported by the hadoop AuthenticationFilter (which we use for the 
> KerberosPlugin).
> There are a number of use cases, but a common one is this:
> There is a front end for searches (say, Hue http://gethue.com/) that supports 
> its own login mechanisms.  If the cluster uses kerberos for authentication, 
> hue must have kerberos credentials for each user, which is a pain to manage.  
> Instead, hue can be allowed to impersonate known users from known machines so 
> it only needs its own kerberos credentials.



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

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

[jira] [Commented] (SOLR-9324) Support Secure Impersonation / Proxy User for solr authentication

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9324: Support Secure Impersonation / Proxy User for solr authentication


> Support Secure Impersonation / Proxy User for solr authentication
> -
>
> Key: SOLR-9324
> URL: https://issues.apache.org/jira/browse/SOLR-9324
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Attachments: SOLR-9324.patch, SOLR-9324.patch, SOLR-9324.patch, 
> SOLR-9324_branch_6x.patch
>
>
> Solr should support Proxy User / Secure Impersonation for authentication, as 
> supported by hadoop 
> (http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Superusers.html)
>  and supported by the hadoop AuthenticationFilter (which we use for the 
> KerberosPlugin).
> There are a number of use cases, but a common one is this:
> There is a front end for searches (say, Hue http://gethue.com/) that supports 
> its own login mechanisms.  If the cluster uses kerberos for authentication, 
> hue must have kerberos credentials for each user, which is a pain to manage.  
> Instead, hue can be allowed to impersonate known users from known machines so 
> it only needs its own kerberos credentials.



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17443/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:38677/i/a/forceleader_test_collection_shard1_replica2]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:38677/i/a/forceleader_test_collection_shard1_replica2]
at 
__randomizedtesting.SeedInfo.seed([510D3CF25ECEC155:B79A0832674C3834]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:774)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
at 
org.apache.solr.cloud.ForceLeaderTest.assertSendDocFails(ForceLeaderTest.java:315)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:110)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1349/
Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseParallelGC

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([B726ADD1EEFDF30:83265507B013B2C8]: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:1162)
at 
org.apache.solr.TestDistributedSearch.queryPartialResults(TestDistributedSearch.java:1103)
at 
org.apache.solr.TestDistributedSearch.test(TestDistributedSearch.java:963)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Commented] (SOLR-9269) Ability to create/delete/list snapshots for a solr core

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9269:


[~dsmiley] sorry for late reply. Let me take a look.

> Ability to create/delete/list snapshots for a solr core
> ---
>
> Key: SOLR-9269
> URL: https://issues.apache.org/jira/browse/SOLR-9269
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>Assignee: David Smiley
> Fix For: 6.2
>
> Attachments: SOLR-9269.patch, SOLR-9269.patch
>
>
> Support snapshot create/delete/list functionality @ the Solr core level. 
> Please refer to parent JIRA for more details.



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

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

[jira] [Updated] (LUCENE-7398) Nested Span Queries are buggy

[Alan Woodward (JIRA)]

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

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

Patch against master.

> Nested Span Queries are buggy
> -
>
> Key: LUCENE-7398
> URL: https://issues.apache.org/jira/browse/LUCENE-7398
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5, 6.x
>Reporter: Christoph Goller
>Assignee: Alan Woodward
>Priority: Critical
> Attachments: LUCENE-7398.patch, LUCENE-7398.patch, 
> TestSpanCollection.java
>
>
> Example for a nested SpanQuery that is not working:
> Document: Human Genome Organization , HUGO , is trying to coordinate gene 
> mapping research worldwide.
> Query: spanNear([body:coordinate, spanOr([spanNear([body:gene, body:mapping], 
> 0, true), body:gene]), body:research], 0, true)
> The query should match "coordinate gene mapping research" as well as 
> "coordinate gene research". It does not match  "coordinate gene mapping 
> research" with Lucene 5.5 or 6.1, it did however match with Lucene 4.10.4. It 
> probably stopped working with the changes on SpanQueries in 5.3. I will 
> attach a unit test that shows the problem.



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

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

[jira] [Commented] (LUCENE-7398) Nested Span Queries are buggy

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-7398:
---

Ah, looks like I made the patch against 6x, will re-up against master.

The specific problem here isn't to do with look-aheads, it's with overlapping 
Spans within a SpanOr when it's not the leading Span for a near query.  If two 
clauses start at the same position, but one is longer than the other, then we 
need to check the longer Span first, as it will cover both cases; if the 
shorter Span is checked first and fails, then the leading Span will be 
incremented, rather than the Or.

> Nested Span Queries are buggy
> -
>
> Key: LUCENE-7398
> URL: https://issues.apache.org/jira/browse/LUCENE-7398
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5, 6.x
>Reporter: Christoph Goller
>Assignee: Alan Woodward
>Priority: Critical
> Attachments: LUCENE-7398.patch, TestSpanCollection.java
>
>
> Example for a nested SpanQuery that is not working:
> Document: Human Genome Organization , HUGO , is trying to coordinate gene 
> mapping research worldwide.
> Query: spanNear([body:coordinate, spanOr([spanNear([body:gene, body:mapping], 
> 0, true), body:gene]), body:research], 0, true)
> The query should match "coordinate gene mapping research" as well as 
> "coordinate gene research". It does not match  "coordinate gene mapping 
> research" with Lucene 5.5 or 6.1, it did however match with Lucene 4.10.4. It 
> probably stopped working with the changes on SpanQueries in 5.3. I will 
> attach a unit test that shows the problem.



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17442/
Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([FD71692690BE8787:752556FC3E42EA7F]:0)
at 
org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test(TestSolrConfigHandlerConcurrent.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

Error Message:
IOException occured when talking to server at: 

[jira] [Commented] (LUCENE-7398) Nested Span Queries are buggy

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-7398:
--

I applied the patch to master commit b3505298a5bef76ff83b269bf87a179d027da849 .
With the patch applied, TestSpanCollection does not compile, there is no 
applicable createWeight() method a few times.
Probably there was a recent conflict there, so I could not actually verify the 
patch.


> Nested Span Queries are buggy
> -
>
> Key: LUCENE-7398
> URL: https://issues.apache.org/jira/browse/LUCENE-7398
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5, 6.x
>Reporter: Christoph Goller
>Assignee: Alan Woodward
>Priority: Critical
> Attachments: LUCENE-7398.patch, TestSpanCollection.java
>
>
> Example for a nested SpanQuery that is not working:
> Document: Human Genome Organization , HUGO , is trying to coordinate gene 
> mapping research worldwide.
> Query: spanNear([body:coordinate, spanOr([spanNear([body:gene, body:mapping], 
> 0, true), body:gene]), body:research], 0, true)
> The query should match "coordinate gene mapping research" as well as 
> "coordinate gene research". It does not match  "coordinate gene mapping 
> research" with Lucene 5.5 or 6.1, it did however match with Lucene 4.10.4. It 
> probably stopped working with the changes on SpanQueries in 5.3. I will 
> attach a unit test that shows the problem.



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

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

[jira] [Comment Edited] (LUCENE-7398) Nested Span Queries are buggy

[Paul Elschot (JIRA)]

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

Paul Elschot edited comment on LUCENE-7398 at 8/2/16 8:17 PM:
--

The patch changes the order in SpanPositionQueue which is used by SpanOr.
This works to pass the test case, and it does not increase complexity.

I think the problem is in NearSpansOrdered.stretchToOrder() which only does 
this:
{code}matchEnd = subSpans[subSpans.length - 1].endPosition();{code}
What is should also do is lookahead to see whether there is an ordered match 
with a smaller slop.

It could be that there still is a failing case with a nested SpanOr, possibly 
containing another nested SpanNear, but I'm not sure, this is tricky.

Since looking ahead increases the complexity (normal case runtime) I'd prefer 
to have the patch applied now, and see what the future brings.



was (Author: paul.elsc...@xs4all.nl):
The patch changes the order in SpanPositionQueue which is used by SpanOr.
This works to pass the test case, and it does not increase complexity.

I think the problem is in NearSpansOrdered.stretchToOrder() which only does 
this:
{code}matchEnd = subSpans[subSpans.length - 1].endPosition();{code}
What is should also do is lookahead to see whether there is an ordered match 
with a smaller slop.

It could be that there still is a failing case with a nested SpanOr, possibly 
over containing another nested SpanNear, but I'm not sure, this is tricky.

Since looking ahead increases the complexity (normal case runtime) I'd prefer 
to have the patch applied now, and see what the future brings.


> Nested Span Queries are buggy
> -
>
> Key: LUCENE-7398
> URL: https://issues.apache.org/jira/browse/LUCENE-7398
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5, 6.x
>Reporter: Christoph Goller
>Assignee: Alan Woodward
>Priority: Critical
> Attachments: LUCENE-7398.patch, TestSpanCollection.java
>
>
> Example for a nested SpanQuery that is not working:
> Document: Human Genome Organization , HUGO , is trying to coordinate gene 
> mapping research worldwide.
> Query: spanNear([body:coordinate, spanOr([spanNear([body:gene, body:mapping], 
> 0, true), body:gene]), body:research], 0, true)
> The query should match "coordinate gene mapping research" as well as 
> "coordinate gene research". It does not match  "coordinate gene mapping 
> research" with Lucene 5.5 or 6.1, it did however match with Lucene 4.10.4. It 
> probably stopped working with the changes on SpanQueries in 5.3. I will 
> attach a unit test that shows the problem.



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

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

[jira] [Commented] (LUCENE-7398) Nested Span Queries are buggy

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-7398:
--

The patch changes the order in SpanPositionQueue which is used by SpanOr.
This works to pass the test case, and it does not increase complexity.

I think the problem is in NearSpansOrdered.stretchToOrder() which only does 
this:
{code}matchEnd = subSpans[subSpans.length - 1].endPosition();{code}
What is should also do is lookahead to see whether there is an ordered match 
with a smaller slop.

It could be that there still is a failing case with a nested SpanOr, possibly 
over containing another nested SpanNear, but I'm not sure, this is tricky.

Since looking ahead increases the complexity (normal case runtime) I'd prefer 
to have the patch applied now, and see what the future brings.


> Nested Span Queries are buggy
> -
>
> Key: LUCENE-7398
> URL: https://issues.apache.org/jira/browse/LUCENE-7398
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5, 6.x
>Reporter: Christoph Goller
>Assignee: Alan Woodward
>Priority: Critical
> Attachments: LUCENE-7398.patch, TestSpanCollection.java
>
>
> Example for a nested SpanQuery that is not working:
> Document: Human Genome Organization , HUGO , is trying to coordinate gene 
> mapping research worldwide.
> Query: spanNear([body:coordinate, spanOr([spanNear([body:gene, body:mapping], 
> 0, true), body:gene]), body:research], 0, true)
> The query should match "coordinate gene mapping research" as well as 
> "coordinate gene research". It does not match  "coordinate gene mapping 
> research" with Lucene 5.5 or 6.1, it did however match with Lucene 4.10.4. It 
> probably stopped working with the changes on SpanQueries in 5.3. I will 
> attach a unit test that shows the problem.



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

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

[jira] [Updated] (SOLR-9324) Support Secure Impersonation / Proxy User for solr authentication

[Gregory Chanan (JIRA)]

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

Gregory Chanan updated SOLR-9324:
-
Attachment: SOLR-9324_branch_6x.patch

Here's a branch 6 patch.

> Support Secure Impersonation / Proxy User for solr authentication
> -
>
> Key: SOLR-9324
> URL: https://issues.apache.org/jira/browse/SOLR-9324
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Attachments: SOLR-9324.patch, SOLR-9324.patch, SOLR-9324.patch, 
> SOLR-9324_branch_6x.patch
>
>
> Solr should support Proxy User / Secure Impersonation for authentication, as 
> supported by hadoop 
> (http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Superusers.html)
>  and supported by the hadoop AuthenticationFilter (which we use for the 
> KerberosPlugin).
> There are a number of use cases, but a common one is this:
> There is a front end for searches (say, Hue http://gethue.com/) that supports 
> its own login mechanisms.  If the cluster uses kerberos for authentication, 
> hue must have kerberos credentials for each user, which is a pain to manage.  
> Instead, hue can be allowed to impersonate known users from known machines so 
> it only needs its own kerberos credentials.



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

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

[jira] [Updated] (SOLR-9324) Support Secure Impersonation / Proxy User for solr authentication

[Gregory Chanan (JIRA)]

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

Gregory Chanan updated SOLR-9324:
-
Attachment: SOLR-9324.patch

Latest changes caused a failure in delegation token tests -- this should 
address that.

> Support Secure Impersonation / Proxy User for solr authentication
> -
>
> Key: SOLR-9324
> URL: https://issues.apache.org/jira/browse/SOLR-9324
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Attachments: SOLR-9324.patch, SOLR-9324.patch, SOLR-9324.patch
>
>
> Solr should support Proxy User / Secure Impersonation for authentication, as 
> supported by hadoop 
> (http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Superusers.html)
>  and supported by the hadoop AuthenticationFilter (which we use for the 
> KerberosPlugin).
> There are a number of use cases, but a common one is this:
> There is a front end for searches (say, Hue http://gethue.com/) that supports 
> its own login mechanisms.  If the cluster uses kerberos for authentication, 
> hue must have kerberos credentials for each user, which is a pain to manage.  
> Instead, hue can be allowed to impersonate known users from known machines so 
> it only needs its own kerberos credentials.



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

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

[jira] [Resolved] (SOLR-9289) SolrCloud RTG: fl=[docid] silently ignored for all docs

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-9289.

   Resolution: Fixed
 Assignee: Hoss Man
Fix Version/s: master (7.0)
   6.2

> SolrCloud RTG: fl=[docid] silently ignored for all docs
> ---
>
> Key: SOLR-9289
> URL: https://issues.apache.org/jira/browse/SOLR-9289
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.2, master (7.0)
>
>
> Found in SOLR-9180 testing.
> In SolrCloud mode, the {{\[docid\]}} transformer is completely ignored when 
> used in a RTG request (even for commited docs) ... this is inconsistent with 
> single node solr behavior.



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

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

[jira] [Resolved] (SOLR-9286) SolrCloud RTG: psuedo-fields (like ValueSourceAugmenter, [shard], etc...) silently fails (even for committed doc)

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-9286.

   Resolution: Fixed
 Assignee: Hoss Man
Fix Version/s: master (7.0)
   6.2

> SolrCloud RTG: psuedo-fields (like ValueSourceAugmenter, [shard], etc...) 
> silently fails (even for committed doc)
> -
>
> Key: SOLR-9286
> URL: https://issues.apache.org/jira/browse/SOLR-9286
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.2, master (7.0)
>
>
> Found in SOLR-9180 testing.
> when using RTG with ValueSourceAugmenter (ie: field aliasing or functions in 
> the fl) in SolrCloud, the request can succeed w/o actually performing the 
> field aliasing and/or ValueSourceAugmenter additions.
> This is inconsistent with single-node solr installs (at least as far as 
> committed docs go, see SOLR-9285 regarding uncommitted docs)



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

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

[jira] [Resolved] (SOLR-9308) SolrCloud RTG doesn't forward any params to shards, causes fqs & non-default fl params to be ignored

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-9308.

   Resolution: Fixed
 Assignee: Hoss Man
Fix Version/s: master (7.0)
   6.2

> SolrCloud RTG doesn't forward any params to shards, causes fqs & non-default 
> fl params to be ignored
> 
>
> Key: SOLR-9308
> URL: https://issues.apache.org/jira/browse/SOLR-9308
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9308.patch, SOLR-9308.patch, SOLR-9308.patch
>
>
> While working on a robust randomized test for SOLR-9285, I can't seem to get 
> filter queries on RTG to work at all -- even when the docs are fully 
> committed.
> steps to reproduce to follow in comment...



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

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

[jira] [Commented] (SOLR-9308) SolrCloud RTG doesn't forward any params to shards, causes fqs & non-default fl params to be ignored

[ASF subversion and git services (JIRA)]

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

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

Commit b3505298a5bef76ff83b269bf87a179d027da849 in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b350529 ]

SOLR-9308: Fix distributed RTG to forward request params, fixes fq and 
non-default fl params


> SolrCloud RTG doesn't forward any params to shards, causes fqs & non-default 
> fl params to be ignored
> 
>
> Key: SOLR-9308
> URL: https://issues.apache.org/jira/browse/SOLR-9308
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9308.patch, SOLR-9308.patch, SOLR-9308.patch
>
>
> While working on a robust randomized test for SOLR-9285, I can't seem to get 
> filter queries on RTG to work at all -- even when the docs are fully 
> committed.
> steps to reproduce to follow in comment...



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

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

[jira] [Commented] (SOLR-9308) SolrCloud RTG doesn't forward any params to shards, causes fqs & non-default fl params to be ignored

[ASF subversion and git services (JIRA)]

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

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

Commit 72750167a20558789d07a1ff5eca35ea8eec3c6e in lucene-solr's branch 
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7275016 ]

SOLR-9308: Fix distributed RTG to forward request params, fixes fq and 
non-default fl params

(cherry picked from commit b3505298a5bef76ff83b269bf87a179d027da849)

Conflicts:

solr/core/src/java/org/apache/solr/handler/component/RealTimeGetComponent.java


> SolrCloud RTG doesn't forward any params to shards, causes fqs & non-default 
> fl params to be ignored
> 
>
> Key: SOLR-9308
> URL: https://issues.apache.org/jira/browse/SOLR-9308
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9308.patch, SOLR-9308.patch, SOLR-9308.patch
>
>
> While working on a robust randomized test for SOLR-9285, I can't seem to get 
> filter queries on RTG to work at all -- even when the docs are fully 
> committed.
> steps to reproduce to follow in comment...



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

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

[jira] [Updated] (LUCENE-7398) Nested Span Queries are buggy

[Alan Woodward (JIRA)]

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

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

Patch with fix, incorporating Christoph's test - will commit tomorrow.

> Nested Span Queries are buggy
> -
>
> Key: LUCENE-7398
> URL: https://issues.apache.org/jira/browse/LUCENE-7398
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5, 6.x
>Reporter: Christoph Goller
>Assignee: Alan Woodward
>Priority: Critical
> Attachments: LUCENE-7398.patch, TestSpanCollection.java
>
>
> Example for a nested SpanQuery that is not working:
> Document: Human Genome Organization , HUGO , is trying to coordinate gene 
> mapping research worldwide.
> Query: spanNear([body:coordinate, spanOr([spanNear([body:gene, body:mapping], 
> 0, true), body:gene]), body:research], 0, true)
> The query should match "coordinate gene mapping research" as well as 
> "coordinate gene research". It does not match  "coordinate gene mapping 
> research" with Lucene 5.5 or 6.1, it did however match with Lucene 4.10.4. It 
> probably stopped working with the changes on SpanQueries in 5.3. I will 
> attach a unit test that shows the problem.



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6023/
Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseSerialGC

3 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail

Error Message:
expected:<200> but was:<404>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([8ED6F3CAB93C4D34:E669C6E069A65FD8]: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.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:140)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:285)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-9371) Fix bin/solr script calculations - start/stop wait time and RMI_PORT

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-9371:


Yeah, that occurred to me... but the name I came up with at first 
(SOLR_START_STOP_WAIT_TIME) was so long that I changed it back.  SOLR_WAIT_TIME 
could work.

Windows is going to be a bit harder, because I'm not as familiar with batch 
mehods as I am shell script.  Any ideas are welcome.

> Fix bin/solr script calculations - start/stop wait time and RMI_PORT
> 
>
> Key: SOLR-9371
> URL: https://issues.apache.org/jira/browse/SOLR-9371
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9371.patch, SOLR-9371.patch
>
>
> The bin/solr script doesn't wait long enough for Solr to stop before it sends 
> the KILL signal to the process.  The start could use a longer wait too.
> Also, the RMI_PORT is calculated by simply prefixing the port number with a 
> "1" instead of adding 1.  If the solr port has five digits, then the rmi 
> port will be invalid, because it will be greater than 65535.



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

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

[jira] [Commented] (SOLR-9252) Feature selection and logistic regression on text

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9252:
--

[~caomanhdat], a couple questions about the tests:

1) In the feature selection test there isn't an assertion for the order of 
terms. But it would seem like there could be because the results are ordered by 
score and the score seems to be deterministic. Should we add an assert on the 
order of the terms?

2) In text logit stream test, how did you choose the values for test records:
{code}
  // first feature is bias value
Double[] testRecord = {1.0, 1.17, 0.691, 0.0, 0.0};
double d = sum(multiply(testRecord, lastWeightsArray));
double prob = sigmoid(d);
assertEquals(prob, 1.0, 0.1);

// first feature is bias value
Double[] testRecord2 = {1.0, 0.0, 0.0, 1.17, 0.691};
d = sum(multiply(testRecord2, lastWeightsArray));
prob = sigmoid(d);
assertEquals(prob, 0, 0.1);
{code}

It would probably be good to document the values for the test records.

> Feature selection and logistic regression on text
> -
>
> Key: SOLR-9252
> URL: https://issues.apache.org/jira/browse/SOLR-9252
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Joel Bernstein
> Attachments: SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, enron1.zip
>
>
> SOLR-9186 come up with a challenges that for each iterative we have to 
> rebuild the tf-idf vector for each documents. It is costly computation if we 
> represent doc by a lot of terms. Features selection can help reducing the 
> computation.
> Due to its computational efficiency and simple interpretation, information 
> gain is one of the most popular feature selection methods. It is used to 
> measure the dependence between features and labels and calculates the 
> information gain between the i-th feature and the class labels 
> (http://www.jiliang.xyz/publication/feature_selection_for_classification.pdf).
> I confirmed that by running logistics regressions on enron mail dataset (in 
> which each email is represented by top 100 terms that have highest 
> information gain) and got the accuracy by 92% and precision by 82%.
> This ticket will create two new streaming expression. Both of them use the 
> same *parallel iterative framework* as SOLR-8492.
> {code}
> featuresSelection(collection1, q="*:*",  field="tv_text", outcome="out_i", 
> positiveLabel=1, numTerms=100)
> {code}
> featuresSelection will emit top terms that have highest information gain 
> scores. It can be combined with new tlogit stream.
> {code}
> tlogit(collection1, q="*:*",
>  featuresSelection(collection1, 
>   q="*:*",  
>   field="tv_text", 
>   outcome="out_i", 
>   positiveLabel=1, 
>   numTerms=100),
>  field="tv_text",
>  outcome="out_i",
>  maxIterations=100)
> {code}
> In the iteration n, the text logistics regression will emit nth model, and 
> compute the error of (n-1)th model. Because the error will be wrong if we 
> compute the error dynamically in each iteration. 
> In each iteration tlogit will change learning rate based on error of previous 
> iteration. It will increase the learning rate by 5% if error is going down 
> and It will decrease the learning rate by 50% if error is going up.
> This will support use cases such as building models for spam detection, 
> sentiment analysis and threat detection. 



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

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

[jira] [Comment Edited] (SOLR-9252) Feature selection and logistic regression on text

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-9252 at 8/2/16 6:46 PM:
--

[~caomanhdat], a couple of questions about the tests:

1) In the feature selection test there isn't an assertion for the order of 
terms. But it would seem like there could be because the results are ordered by 
score and the score seems to be deterministic. Should we add an assert on the 
order of the terms?

2) In text logit stream test, how did you choose the values for test records:
{code}
  // first feature is bias value
Double[] testRecord = {1.0, 1.17, 0.691, 0.0, 0.0};
double d = sum(multiply(testRecord, lastWeightsArray));
double prob = sigmoid(d);
assertEquals(prob, 1.0, 0.1);

// first feature is bias value
Double[] testRecord2 = {1.0, 0.0, 0.0, 1.17, 0.691};
d = sum(multiply(testRecord2, lastWeightsArray));
prob = sigmoid(d);
assertEquals(prob, 0, 0.1);
{code}

It would probably be good to document the values for the test records.


was (Author: joel.bernstein):
[~caomanhdat], a couple questions about the tests:

1) In the feature selection test there isn't an assertion for the order of 
terms. But it would seem like there could be because the results are ordered by 
score and the score seems to be deterministic. Should we add an assert on the 
order of the terms?

2) In text logit stream test, how did you choose the values for test records:
{code}
  // first feature is bias value
Double[] testRecord = {1.0, 1.17, 0.691, 0.0, 0.0};
double d = sum(multiply(testRecord, lastWeightsArray));
double prob = sigmoid(d);
assertEquals(prob, 1.0, 0.1);

// first feature is bias value
Double[] testRecord2 = {1.0, 0.0, 0.0, 1.17, 0.691};
d = sum(multiply(testRecord2, lastWeightsArray));
prob = sigmoid(d);
assertEquals(prob, 0, 0.1);
{code}

It would probably be good to document the values for the test records.

> Feature selection and logistic regression on text
> -
>
> Key: SOLR-9252
> URL: https://issues.apache.org/jira/browse/SOLR-9252
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Joel Bernstein
> Attachments: SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, SOLR-9252.patch, 
> SOLR-9252.patch, enron1.zip
>
>
> SOLR-9186 come up with a challenges that for each iterative we have to 
> rebuild the tf-idf vector for each documents. It is costly computation if we 
> represent doc by a lot of terms. Features selection can help reducing the 
> computation.
> Due to its computational efficiency and simple interpretation, information 
> gain is one of the most popular feature selection methods. It is used to 
> measure the dependence between features and labels and calculates the 
> information gain between the i-th feature and the class labels 
> (http://www.jiliang.xyz/publication/feature_selection_for_classification.pdf).
> I confirmed that by running logistics regressions on enron mail dataset (in 
> which each email is represented by top 100 terms that have highest 
> information gain) and got the accuracy by 92% and precision by 82%.
> This ticket will create two new streaming expression. Both of them use the 
> same *parallel iterative framework* as SOLR-8492.
> {code}
> featuresSelection(collection1, q="*:*",  field="tv_text", outcome="out_i", 
> positiveLabel=1, numTerms=100)
> {code}
> featuresSelection will emit top terms that have highest information gain 
> scores. It can be combined with new tlogit stream.
> {code}
> tlogit(collection1, q="*:*",
>  featuresSelection(collection1, 
>   q="*:*",  
>   field="tv_text", 
>   outcome="out_i", 
>   positiveLabel=1, 
>   numTerms=100),
>  field="tv_text",
>  outcome="out_i",
>  maxIterations=100)
> {code}
> In the iteration n, the text logistics regression will emit nth model, and 
> compute the error of (n-1)th model. Because the error will be wrong if we 
> compute the error dynamically in each iteration. 
> In each iteration tlogit will change learning rate based on error of previous 
> iteration. It will increase the learning rate by 5% if error is going down 
> and It will decrease the learning rate by 50% if error is going up.
> This will support use cases such as building models for spam detection, 
> sentiment analysis and threat detection. 



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

[jira] [Updated] (SOLR-9367) TestInjection's use of a static Random means that sequences of events can be diff for the same test seed depending on wether individual methods are run, or entire test cla

[Hoss Man (JIRA)]

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

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

attaching my strawman proposed fix...  anybody else have a better suggestion?

> TestInjection's use of a static Random means that sequences of events can be 
> diff for the same test seed depending on wether individual methods are run, 
> or entire test classes, or multiple classes in the same slave JVM
> --
>
> Key: SOLR-9367
> URL: https://issues.apache.org/jira/browse/SOLR-9367
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-9367.patch
>
>
> While digging through SOLR-9363, I realized that the reason the failures 
> reproduced when running the entire {{-Dtestcase}} but not the individual 
> {{-Dtests.method}} was because TestInjection was behaving differently in 
> those cases.
> This is because TestInjection uses a static Random instance -- allthough it 
> is initialized based on the {{tests.seed}} sysprop to _try_ to be 
> reproducible, it's behavior still very much depends on how many testcases are 
> run in that slave JVM, and/or how many test methods are run.



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

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

[jira] [Resolved] (SOLR-9363) TestStressCloudBlindAtomicUpdates.test_dv_stored() failure

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-9363.

   Resolution: Fixed
Fix Version/s: master (7.0)
   6.2

> TestStressCloudBlindAtomicUpdates.test_dv_stored() failure
> --
>
> Key: SOLR-9363
> URL: https://issues.apache.org/jira/browse/SOLR-9363
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Hoss Man
> Fix For: 6.2, master (7.0)
>
> Attachments: Lucene-Solr-Nightly-master.271.log.gz, SOLR-9363.patch
>
>
> My Jenkins found a reproducing seed - though note that in order to reproduce 
> I had to a) run the test at the same SHA as the one listed, and b) leave off 
> {{-Dtests.method=test_dv_stored}}; under those conditions it failed both 
> times I ran it:
> {noformat}
> Checking out Revision 53a34b312e78ce6f56c0bb41304ac834b28b9534 
> (refs/remotes/origin/master)
> [...]
>   [junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestStressCloudBlindAtomicUpdates -Dtests.method=test_dv_stored 
> -Dtests.seed=60C9AAFC94FD8921 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=id -Dtests.timezone=America/Puerto_Rico -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 9.09s J0 | 
> TestStressCloudBlindAtomicUpdates.test_dv_stored <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<332> but 
> was:<205>
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([60C9AAFC94FD8921:F2F5CB7828BAB4F9]:0)
>[junit4]>at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:253)
>[junit4]>at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv_stored(TestStressCloudBlindAtomicUpdates.java:192)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

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

[jira] [Updated] (SOLR-9324) Support Secure Impersonation / Proxy User for solr authentication

[Gregory Chanan (JIRA)]

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

Gregory Chanan updated SOLR-9324:
-
Attachment: SOLR-9324.patch

> Support Secure Impersonation / Proxy User for solr authentication
> -
>
> Key: SOLR-9324
> URL: https://issues.apache.org/jira/browse/SOLR-9324
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Attachments: SOLR-9324.patch, SOLR-9324.patch
>
>
> Solr should support Proxy User / Secure Impersonation for authentication, as 
> supported by hadoop 
> (http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Superusers.html)
>  and supported by the hadoop AuthenticationFilter (which we use for the 
> KerberosPlugin).
> There are a number of use cases, but a common one is this:
> There is a front end for searches (say, Hue http://gethue.com/) that supports 
> its own login mechanisms.  If the cluster uses kerberos for authentication, 
> hue must have kerberos credentials for each user, which is a pain to manage.  
> Instead, hue can be allowed to impersonate known users from known machines so 
> it only needs its own kerberos credentials.



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17441/
Java: 64bit/jdk-9-ea+129 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail

Error Message:
expected:<200> but was:<404>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([DEE1B094D042D56E:B65E85BE00D8C782]: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.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:140)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:295)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Commented] (LUCENE-7398) Nested Span Queries are buggy

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-7398:
---

I think this is a bug in SpanPositionQueue, where longer Spans should be sorted 
before shorter ones at the same position - will dig and see if I can get a fix 
in shortly.

> Nested Span Queries are buggy
> -
>
> Key: LUCENE-7398
> URL: https://issues.apache.org/jira/browse/LUCENE-7398
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5, 6.x
>Reporter: Christoph Goller
>Assignee: Alan Woodward
>Priority: Critical
> Attachments: TestSpanCollection.java
>
>
> Example for a nested SpanQuery that is not working:
> Document: Human Genome Organization , HUGO , is trying to coordinate gene 
> mapping research worldwide.
> Query: spanNear([body:coordinate, spanOr([spanNear([body:gene, body:mapping], 
> 0, true), body:gene]), body:research], 0, true)
> The query should match "coordinate gene mapping research" as well as 
> "coordinate gene research". It does not match  "coordinate gene mapping 
> research" with Lucene 5.5 or 6.1, it did however match with Lucene 4.10.4. It 
> probably stopped working with the changes on SpanQueries in 5.3. I will 
> attach a unit test that shows the problem.



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

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

[jira] [Assigned] (LUCENE-7398) Nested Span Queries are buggy

[Alan Woodward (JIRA)]

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

Alan Woodward reassigned LUCENE-7398:
-

Assignee: Alan Woodward

> Nested Span Queries are buggy
> -
>
> Key: LUCENE-7398
> URL: https://issues.apache.org/jira/browse/LUCENE-7398
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5, 6.x
>Reporter: Christoph Goller
>Assignee: Alan Woodward
>Priority: Critical
> Attachments: TestSpanCollection.java
>
>
> Example for a nested SpanQuery that is not working:
> Document: Human Genome Organization , HUGO , is trying to coordinate gene 
> mapping research worldwide.
> Query: spanNear([body:coordinate, spanOr([spanNear([body:gene, body:mapping], 
> 0, true), body:gene]), body:research], 0, true)
> The query should match "coordinate gene mapping research" as well as 
> "coordinate gene research". It does not match  "coordinate gene mapping 
> research" with Lucene 5.5 or 6.1, it did however match with Lucene 4.10.4. It 
> probably stopped working with the changes on SpanQueries in 5.3. I will 
> attach a unit test that shows the problem.



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

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

[jira] [Commented] (SOLR-9320) A REPLACENODE command to decommission an existing node with another new node

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9320:
--

The best we can do is pass an extra parameter to speed up the execution (say 
parallel=true). But the real risk of screwing up the node/network exists

> A REPLACENODE command to decommission an existing node with another new node
> 
>
> Key: SOLR-9320
> URL: https://issues.apache.org/jira/browse/SOLR-9320
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DELETENODE.jpeg, REPLACENODE_After.jpeg, 
> REPLACENODE_Before.jpeg, REPLACENODE_call_response.jpeg, SOLR-9320.patch, 
> SOLR-9320.patch
>
>
> The command should accept a source node and target node. recreate the 
> replicas in source node in the target and do a DLETENODE of source node



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

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

[jira] [Commented] (SOLR-9320) A REPLACENODE command to decommission an existing node with another new node

[Nitin Sharma (JIRA)]

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

Nitin Sharma commented on SOLR-9320:


Would be good to establish context on when this command should/can be run. In 
our current version of rebalance, we use this to switch serving nodes in 
production and hence the time taken to migrate a node is limited (time bound). 
If this is considered an offline process, then may be serial works just fine. 

I agree with Erick on throttling but we can do that at a system level (unix 
traffic shaping tc etc). That will leave the bandwidth management outside the 
responsibility of solr. The same node serving solr can be used to run other 
services in some production setups. Keeping that outside solr will put that 
onus on the maintainer.  Just my $0.02

> A REPLACENODE command to decommission an existing node with another new node
> 
>
> Key: SOLR-9320
> URL: https://issues.apache.org/jira/browse/SOLR-9320
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DELETENODE.jpeg, REPLACENODE_After.jpeg, 
> REPLACENODE_Before.jpeg, REPLACENODE_call_response.jpeg, SOLR-9320.patch, 
> SOLR-9320.patch
>
>
> The command should accept a source node and target node. recreate the 
> replicas in source node in the target and do a DLETENODE of source node



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

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

[jira] [Updated] (SOLR-8396) Add support for PointFields in Solr

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-8396:

Summary: Add support for PointFields in Solr  (was: Investigate PointField 
to replace NumericField types)

Updated title to reflect the discussion and the work being done

> Add support for PointFields in Solr
> ---
>
> Key: SOLR-8396
> URL: https://issues.apache.org/jira/browse/SOLR-8396
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
> Attachments: SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, 
> SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch
>
>
> In LUCENE-6917, [~mikemccand] mentioned that DimensionalValues are better 
> than NumericFields in most respects. We should explore the benefits of using 
> it in Solr and hence, if appropriate, switch over to using them.



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

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

[jira] [Comment Edited] (SOLR-9371) Fix bin/solr script calculations - start/stop wait time and RMI_PORT

[Shawn Heisey (JIRA)]

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

Shawn Heisey edited comment on SOLR-9371 at 8/2/16 5:40 PM:


I looked into the Windows start script.  It just uses a plain "wait" sort of 
timeout.  The "wait briefly and check PID" loop might be adaptable to the 
"stop" action in Windows by somebody who really knows the batch syntax.

Question for the peanut gallery:  What's the earliest Windows version we will 
support?  One command that I found for doing silent pauses won't work on XP, 
and probably doesn't work on 2003 either.  Both of these versions are end of 
life ... so do we need to support them?



was (Author: elyograg):
I looked into the Windows start script.  It just uses a plain "wait" sort of 
timeout.  The "wait briefly and check PID" loop might be adaptable to the 
"stop" action in Windows by somebody who really knows the batch syntax.

Question for the peanut gallery:  What's the earliest Windows version we will 
support?  One command that I found for doing silent pauses won't work on XP.  
XP is end of life ... so do we need to support it?


> Fix bin/solr script calculations - start/stop wait time and RMI_PORT
> 
>
> Key: SOLR-9371
> URL: https://issues.apache.org/jira/browse/SOLR-9371
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9371.patch, SOLR-9371.patch
>
>
> The bin/solr script doesn't wait long enough for Solr to stop before it sends 
> the KILL signal to the process.  The start could use a longer wait too.
> Also, the RMI_PORT is calculated by simply prefixing the port number with a 
> "1" instead of adding 1.  If the solr port has five digits, then the rmi 
> port will be invalid, because it will be greater than 65535.



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

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

[jira] [Commented] (SOLR-9371) Fix bin/solr script calculations - start/stop wait time and RMI_PORT

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-9371:


I looked into the Windows start script.  It just uses a plain "wait" sort of 
timeout.  The "wait briefly and check PID" loop might be adaptable to the 
"stop" action in Windows by somebody who really knows the batch syntax.

Question for the peanut gallery:  What's the earliest Windows version we will 
support?  One command that I found for doing silent pauses won't work on XP.  
XP is end of life ... so do we need to support it?


> Fix bin/solr script calculations - start/stop wait time and RMI_PORT
> 
>
> Key: SOLR-9371
> URL: https://issues.apache.org/jira/browse/SOLR-9371
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9371.patch, SOLR-9371.patch
>
>
> The bin/solr script doesn't wait long enough for Solr to stop before it sends 
> the KILL signal to the process.  The start could use a longer wait too.
> Also, the RMI_PORT is calculated by simply prefixing the port number with a 
> "1" instead of adding 1.  If the solr port has five digits, then the rmi 
> port will be invalid, because it will be greater than 65535.



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

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

[jira] [Commented] (SOLR-9320) A REPLACENODE command to decommission an existing node with another new node

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9320:
--

bq.And doing one after the other could still be throttled by maxWriteMBPerSec

The problem is, we can't do that from the {{REPLACENODE}} command. The 
downloads happen in a different thread from the target node 

> A REPLACENODE command to decommission an existing node with another new node
> 
>
> Key: SOLR-9320
> URL: https://issues.apache.org/jira/browse/SOLR-9320
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DELETENODE.jpeg, REPLACENODE_After.jpeg, 
> REPLACENODE_Before.jpeg, REPLACENODE_call_response.jpeg, SOLR-9320.patch, 
> SOLR-9320.patch
>
>
> The command should accept a source node and target node. recreate the 
> replicas in source node in the target and do a DLETENODE of source node



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

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

[jira] [Commented] (SOLR-9320) A REPLACENODE command to decommission an existing node with another new node

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9320:
--

[~noble.paul] That certainly works. My goal was just to be sure bandwidth 
figured in to the design if people wanted to multi-thread.

And doing one after the other could still be throttled by maxWriteMBPerSec if a 
single node overwhelmed the network or disks (I've actually seen this in the 
wild FWIW).



> A REPLACENODE command to decommission an existing node with another new node
> 
>
> Key: SOLR-9320
> URL: https://issues.apache.org/jira/browse/SOLR-9320
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DELETENODE.jpeg, REPLACENODE_After.jpeg, 
> REPLACENODE_Before.jpeg, REPLACENODE_call_response.jpeg, SOLR-9320.patch, 
> SOLR-9320.patch
>
>
> The command should accept a source node and target node. recreate the 
> replicas in source node in the target and do a DLETENODE of source node



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1347/
Java: 32bit/jdk-9-ea+129 -client -XX:+UseSerialGC

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

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:40765/c8n_1x3_lf_shard1_replica2]

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: No live 
SolrServers available to handle this 
request:[http://127.0.0.1:40765/c8n_1x3_lf_shard1_replica2]
at 
__randomizedtesting.SeedInfo.seed([6D6D70EB2DF55F21:E5394F31830932D9]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:592)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:578)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:174)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 305 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/305/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

No tests ran.

Build Log:
[...truncated 1432 lines...]
   [junit4] Suite: org.apache.lucene.index.TestAllFilesCheckIndexHeader
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestAllFilesCheckIndexHeader -Dtests.method=test 
-Dtests.seed=2E0418A659C57B7A -Dtests.slow=true -Dtests.locale=sr 
-Dtests.timezone=ART -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   0.21s J0 | TestAllFilesCheckIndexHeader.test <<<
   [junit4]> Throwable #1: java.io.IOException: file "segments_h" was 
already written to
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([2E0418A659C57B7A:A650277CF7391682]:0)
   [junit4]>at 
org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:654)
   [junit4]>at 
org.apache.lucene.index.TestAllFilesCheckIndexHeader.checkOneFile(TestAllFilesCheckIndexHeader.java:106)
   [junit4]>at 
org.apache.lucene.index.TestAllFilesCheckIndexHeader.checkIndexHeader(TestAllFilesCheckIndexHeader.java:81)
   [junit4]>at 
org.apache.lucene.index.TestAllFilesCheckIndexHeader.test(TestAllFilesCheckIndexHeader.java:74)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): {}, 
docValues:{}, maxPointsInLeafNode=584, maxMBSortInHeap=7.177520307448994, 
sim=RandomSimilarity(queryNorm=false,coord=yes): {titleTokenized=DFR 
I(n)3(800.0), body=DFR I(ne)L2}, locale=sr, timezone=ART
   [junit4]   2> NOTE: SunOS 5.11 amd64/Oracle Corporation 1.8.0_102 
(64-bit)/cpus=3,threads=1,free=158399008,total=341835776
   [junit4]   2> NOTE: All tests run in this JVM: [TestSimpleFSLockFactory, 
TestMultiTermQueryRewrites, TestGrowableByteArrayDataOutput, TestGeoUtils, 
TestNRTCachingDirectory, TestFilterDirectory, TestNGramPhraseQuery, 
TestTermsEnum, TestStopFilter, TestField, TestFilterLeafReader, 
TestMergeRateLimiter, TestPrefixRandom, TestIndexWriterWithThreads, 
TestDocIdsWriter, TestDuelingCodecsAtNight, TestRegexpRandom, TestScorerPerf, 
Test2BPagedBytes, TestRAMDirectory, TestRollingBuffer, TestFilterWeight, 
TestDocValuesRewriteMethod, TestBagOfPostings, TestShardSearching, 
Test2BBKDPoints, TestDeterminism, TestSpanSearchEquivalence, 
TestBlendedTermQuery, TestBlockPostingsFormat2, Test2BBinaryDocValues, 
TestSimpleExplanationsWithFillerDocs, Test2BSortedDocValuesFixedSorted, 
TestDirectPacked, TestPayloadsOnVectors, TestMaxPosition, 
TestCodecHoldsOpenFiles, TestBytesRef, TestFlushByRamOrCountsPolicy, 
TestIndexWriterExceptions, TestNearSpansOrdered, TestTimeLimitingCollector, 
Test2BPostingsBytes, TestSpansEnum, TestBufferedIndexInput, 
TestRamUsageEstimator, TestMinimize, Test2BNumericDocValues, 
TestIndexWriterOutOfFileDescriptors, TestIndexWriter, TestSpanExplanations, 
TestIndexWriterMerging, TestTryDelete, TestFixedBitSet, TestArrayUtil, 
TestOmitPositions, TestSearchAfter, TestMinShouldMatch2, 
TestFieldMaskingSpanQuery, TestForceMergeForever, TestDuelingCodecs, 
TestDirectoryReader, TestFieldCacheRewriteMethod, TestMSBRadixSorter, 
TestIndexWriterDelete, TestNorms, TestTermScorer, TestCharArrayMap, 
TestCharTermAttributeImpl, TestDemoParallelLeafReader, TestIndexInput, 
TestFieldType, TestBinaryDocument, TestFSTs, TestNumericUtils, TestNot, 
TestTerms, TestSpanCollection, TestNumericDocValuesUpdates, 
TestDocInverterPerFieldErrorInfo, TestSubScorerFreqs, 
TestAutomatonQueryUnicode, LimitedFiniteStringsIteratorTest, 
TestLucene50StoredFieldsFormatHighCompression, TestSimilarity, TestSumDocFreq, 
TestPagedBytes, TestTopDocsCollector, TestMultiDocValues, TestNoMergePolicy, 
TestIsCurrent, TestVersion, TestThreadedForceMerge, 
TestBooleanQueryVisitSubscorers, TestForUtil, TestLSBRadixSorter, 
TestDisjunctionMaxQuery, TestFlex, TestPhrasePrefixQuery, TestSegmentTermDocs, 
TestReaderWrapperDVTypeCheck, TestPostingsOffsets, TestConjunctionDISI, 
TestRoaringDocIdSet, TestOperations, TestTermdocPerf, TestSleepingLockWrapper, 
TestBM25Similarity, TestTopDocsMerge, TestRegexpRandom2, TestExternalCodecs, 
TestNRTThreads, TestPersistentSnapshotDeletionPolicy, TestStressAdvance, 
TestDirectoryReaderReopen, TestHighCompressionMode, TestNeverDelete, 
TestStressIndexing, TestRollingUpdates, TestNRTReaderWithThreads, 
TestIndexWriterForceMerge, TestByteSlices, TestConsistentFieldNumbers, 
TestSimpleExplanations, TestSegmentMerger, TestPhraseQuery, TestCollectionUtil, 
TestFastDecompressionMode, TestTransactions, TestMultiThreadTermVectors, 
TestSimpleSearchEquivalence, TestCustomSearcherSort, TestHugeRamFile, 
TestIndexWriterOnDiskFull, TestCustomNorms, TestStressIndexing2, 
TestDocsAndPositions, TestTermVectorsWriter, TestCodecs, TestBytesRefHash, 
TestLiveFieldValues, TestPayloads, TestWildcard, TestPerSegmentDeletes, 
TestIntBlockPool, TestUniqueTermCount, TestComplexExplanationsOfNonMatches, 

[jira] [Updated] (SOLR-8396) Investigate PointField to replace NumericField types

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-8396:

Attachment: SOLR-8396.patch

Minor improvement. Modified also schema11.xml to use point fields, since it's 
used by many tests. Tests are passing reliably in general. Exceptions are 
grouping and ExpandComponent. Since those different use cases and code paths 
I'm not going to tackle them in this Jira. My plan now is to add other field 
types

> Investigate PointField to replace NumericField types
> 
>
> Key: SOLR-8396
> URL: https://issues.apache.org/jira/browse/SOLR-8396
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
> Attachments: SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, 
> SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch
>
>
> In LUCENE-6917, [~mikemccand] mentioned that DimensionalValues are better 
> than NumericFields in most respects. We should explore the benefits of using 
> it in Solr and hence, if appropriate, switch over to using them.



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

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

[jira] [Commented] (SOLR-9320) A REPLACENODE command to decommission an existing node with another new node

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9320:
--

[~erickerickson] I'm inclined to create cores one after another. Even if takes 
some time, it is better to ensure that we don't overload that one node. This is 
an admin command which is issued asynchronously. So, there is no harm even if 
it takes a while.

> A REPLACENODE command to decommission an existing node with another new node
> 
>
> Key: SOLR-9320
> URL: https://issues.apache.org/jira/browse/SOLR-9320
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DELETENODE.jpeg, REPLACENODE_After.jpeg, 
> REPLACENODE_Before.jpeg, REPLACENODE_call_response.jpeg, SOLR-9320.patch, 
> SOLR-9320.patch
>
>
> The command should accept a source node and target node. recreate the 
> replicas in source node in the target and do a DLETENODE of source node



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

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

[jira] [Resolved] (SOLR-9200) Add Delegation Token Support to Solr

[Gregory Chanan (JIRA)]

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

Gregory Chanan resolved SOLR-9200.
--
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.2

> Add Delegation Token Support to Solr
> 
>
> Key: SOLR-9200
> URL: https://issues.apache.org/jira/browse/SOLR-9200
> Project: Solr
>  Issue Type: New Feature
>  Components: security
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9200.patch, SOLR-9200.patch, SOLR-9200.patch, 
> SOLR-9200.patch, SOLR-9200.patch, SOLR-9200_branch_6x.patch, 
> SOLR-9200_branch_6x.patch, SOLR-9200_branch_6x.patch
>
>
> SOLR-7468 added support for kerberos authentication via the hadoop 
> authentication filter.  Hadoop also has support for an authentication filter 
> that supports delegation tokens, which allow authenticated users the ability 
> to grab/renew/delete a token that can be used to bypass the normal 
> authentication path for a time.  This is useful in a variety of use cases:
> 1) distributed clients (e.g. MapReduce) where each client may not have access 
> to the user's kerberos credentials.  Instead, the job runner can grab a 
> delegation token and use that during task execution.
> 2) If the load on the kerberos server is too high, delegation tokens can 
> avoid hitting the kerberos server after the first request
> 3) If requests/permissions need to be delegated to another user: the more 
> privileged user can request a delegation token that can be passed to the less 
> privileged user.
> Note to self:
> In 
> https://issues.apache.org/jira/browse/SOLR-7468?focusedCommentId=14579636=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14579636
>  I made the following comment which I need to investigate further, since I 
> don't know if anything changed in this area:
> {quote}3) I'm a little concerned with the "NoContext" code in KerberosPlugin 
> moving forward (I understand this is more a generic auth question than 
> kerberos specific). For example, in the latest version of the filter we are 
> using at Cloudera, we play around with the ServletContext in order to pass 
> information around 
> (https://github.com/cloudera/lucene-solr/blob/cdh5-4.10.3_5.4.2/solr/core/src/java/org/apache/solr/servlet/SolrHadoopAuthenticationFilter.java#L106).
>  Is there any way we can get the actual ServletContext in a plugin?{quote}



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

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

[jira] [Commented] (SOLR-9200) Add Delegation Token Support to Solr

[ASF subversion and git services (JIRA)]

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

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

Commit 6cfec0bd7a56f7e70046093c603e6f5982c83c69 in lucene-solr's branch 
refs/heads/branch_6x from [~gchanan]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6cfec0b ]

SOLR-9200: Add Delegation Token Support to Solr


> Add Delegation Token Support to Solr
> 
>
> Key: SOLR-9200
> URL: https://issues.apache.org/jira/browse/SOLR-9200
> Project: Solr
>  Issue Type: New Feature
>  Components: security
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Attachments: SOLR-9200.patch, SOLR-9200.patch, SOLR-9200.patch, 
> SOLR-9200.patch, SOLR-9200.patch, SOLR-9200_branch_6x.patch, 
> SOLR-9200_branch_6x.patch, SOLR-9200_branch_6x.patch
>
>
> SOLR-7468 added support for kerberos authentication via the hadoop 
> authentication filter.  Hadoop also has support for an authentication filter 
> that supports delegation tokens, which allow authenticated users the ability 
> to grab/renew/delete a token that can be used to bypass the normal 
> authentication path for a time.  This is useful in a variety of use cases:
> 1) distributed clients (e.g. MapReduce) where each client may not have access 
> to the user's kerberos credentials.  Instead, the job runner can grab a 
> delegation token and use that during task execution.
> 2) If the load on the kerberos server is too high, delegation tokens can 
> avoid hitting the kerberos server after the first request
> 3) If requests/permissions need to be delegated to another user: the more 
> privileged user can request a delegation token that can be passed to the less 
> privileged user.
> Note to self:
> In 
> https://issues.apache.org/jira/browse/SOLR-7468?focusedCommentId=14579636=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14579636
>  I made the following comment which I need to investigate further, since I 
> don't know if anything changed in this area:
> {quote}3) I'm a little concerned with the "NoContext" code in KerberosPlugin 
> moving forward (I understand this is more a generic auth question than 
> kerberos specific). For example, in the latest version of the filter we are 
> using at Cloudera, we play around with the ServletContext in order to pass 
> information around 
> (https://github.com/cloudera/lucene-solr/blob/cdh5-4.10.3_5.4.2/solr/core/src/java/org/apache/solr/servlet/SolrHadoopAuthenticationFilter.java#L106).
>  Is there any way we can get the actual ServletContext in a plugin?{quote}



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

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

[jira] [Commented] (SOLR-9320) A REPLACENODE command to decommission an existing node with another new node

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9320:
--

If we're going to take advantage of multithreading we need to take some care to 
throttle replication. If we try to copy 500 cores' indexes to some other node 
all at once with 500 separate threads I'd worry about network bandwidth issues. 
I've seen saturated I/O cause nodes to go into recovery and the like. Not to 
mention beating up the disks on both machines.

The number of replace operations to carry out in parallel is probably the 
easiest. I can think of two tuning parameters, max # of simultaneous threads 
and max bandwidth consumption. 

Thinking about it for a bit, though, the bandwidth parameter seems like it's 
difficult to do well. There'd have to be some kind of cross-copy communications 
I should think. And other ugliness. I suppose one could get this behavior on a 
case-by-case basis by 
1> specifying the max # of replace ops
2> specifying ${maxWriteMbPerSec:10} in 
the replication handler and overriding with a sys var when doing a 
REPLACENODE



> A REPLACENODE command to decommission an existing node with another new node
> 
>
> Key: SOLR-9320
> URL: https://issues.apache.org/jira/browse/SOLR-9320
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DELETENODE.jpeg, REPLACENODE_After.jpeg, 
> REPLACENODE_Before.jpeg, REPLACENODE_call_response.jpeg, SOLR-9320.patch, 
> SOLR-9320.patch
>
>
> The command should accept a source node and target node. recreate the 
> replicas in source node in the target and do a DLETENODE of source node



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17440/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseG1GC

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([32152EAC19CE0613:BA411176B7326BEB]: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:1172)
at 
org.apache.solr.TestDistributedSearch.queryPartialResults(TestDistributedSearch.java:1113)
at 
org.apache.solr.TestDistributedSearch.test(TestDistributedSearch.java:973)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Commented] (SOLR-9367) TestInjection's use of a static Random means that sequences of events can be diff for the same test seed depending on wether individual methods are run, or entire test c

[ASF subversion and git services (JIRA)]

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

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

Commit c17605b4a9978311b6b231f202d70dd800e473e6 in lucene-solr's branch 
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c17605b ]

SOLR-9363: tweak test to work around SOLR-9366 + SOLR-9367 since those issues 
are not key to what's being tested here

(cherry picked from commit 04321c401c6584395c76c509f8513c5e5e4730ee)


> TestInjection's use of a static Random means that sequences of events can be 
> diff for the same test seed depending on wether individual methods are run, 
> or entire test classes, or multiple classes in the same slave JVM
> --
>
> Key: SOLR-9367
> URL: https://issues.apache.org/jira/browse/SOLR-9367
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> While digging through SOLR-9363, I realized that the reason the failures 
> reproduced when running the entire {{-Dtestcase}} but not the individual 
> {{-Dtests.method}} was because TestInjection was behaving differently in 
> those cases.
> This is because TestInjection uses a static Random instance -- allthough it 
> is initialized based on the {{tests.seed}} sysprop to _try_ to be 
> reproducible, it's behavior still very much depends on how many testcases are 
> run in that slave JVM, and/or how many test methods are run.



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

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

[jira] [Commented] (SOLR-9363) TestStressCloudBlindAtomicUpdates.test_dv_stored() failure

[ASF subversion and git services (JIRA)]

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

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

Commit 04321c401c6584395c76c509f8513c5e5e4730ee in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=04321c4 ]

SOLR-9363: tweak test to work around SOLR-9366 + SOLR-9367 since those issues 
are not key to what's being tested here


> TestStressCloudBlindAtomicUpdates.test_dv_stored() failure
> --
>
> Key: SOLR-9363
> URL: https://issues.apache.org/jira/browse/SOLR-9363
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Hoss Man
> Attachments: Lucene-Solr-Nightly-master.271.log.gz, SOLR-9363.patch
>
>
> My Jenkins found a reproducing seed - though note that in order to reproduce 
> I had to a) run the test at the same SHA as the one listed, and b) leave off 
> {{-Dtests.method=test_dv_stored}}; under those conditions it failed both 
> times I ran it:
> {noformat}
> Checking out Revision 53a34b312e78ce6f56c0bb41304ac834b28b9534 
> (refs/remotes/origin/master)
> [...]
>   [junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestStressCloudBlindAtomicUpdates -Dtests.method=test_dv_stored 
> -Dtests.seed=60C9AAFC94FD8921 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=id -Dtests.timezone=America/Puerto_Rico -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 9.09s J0 | 
> TestStressCloudBlindAtomicUpdates.test_dv_stored <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<332> but 
> was:<205>
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([60C9AAFC94FD8921:F2F5CB7828BAB4F9]:0)
>[junit4]>at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:253)
>[junit4]>at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv_stored(TestStressCloudBlindAtomicUpdates.java:192)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

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

[jira] [Commented] (SOLR-9367) TestInjection's use of a static Random means that sequences of events can be diff for the same test seed depending on wether individual methods are run, or entire test c

[ASF subversion and git services (JIRA)]

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

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

Commit 04321c401c6584395c76c509f8513c5e5e4730ee in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=04321c4 ]

SOLR-9363: tweak test to work around SOLR-9366 + SOLR-9367 since those issues 
are not key to what's being tested here


> TestInjection's use of a static Random means that sequences of events can be 
> diff for the same test seed depending on wether individual methods are run, 
> or entire test classes, or multiple classes in the same slave JVM
> --
>
> Key: SOLR-9367
> URL: https://issues.apache.org/jira/browse/SOLR-9367
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> While digging through SOLR-9363, I realized that the reason the failures 
> reproduced when running the entire {{-Dtestcase}} but not the individual 
> {{-Dtests.method}} was because TestInjection was behaving differently in 
> those cases.
> This is because TestInjection uses a static Random instance -- allthough it 
> is initialized based on the {{tests.seed}} sysprop to _try_ to be 
> reproducible, it's behavior still very much depends on how many testcases are 
> run in that slave JVM, and/or how many test methods are run.



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

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

[jira] [Commented] (SOLR-9366) replicas in LIR seem to still be participating in search requests

[ASF subversion and git services (JIRA)]

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

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

Commit c17605b4a9978311b6b231f202d70dd800e473e6 in lucene-solr's branch 
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c17605b ]

SOLR-9363: tweak test to work around SOLR-9366 + SOLR-9367 since those issues 
are not key to what's being tested here

(cherry picked from commit 04321c401c6584395c76c509f8513c5e5e4730ee)


> replicas in LIR seem to still be participating in search requests
> -
>
> Key: SOLR-9366
> URL: https://issues.apache.org/jira/browse/SOLR-9366
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-9366.txt.gz
>
>
> Spinning this off from SOLR-9363 where sarowe's jenkins encountered a strange 
> test failure when TestInjection is used causing replicas to return errors on 
> some requests.
> Reading over the logs it appears that when this happens, and the replicas are 
> put into LIR they then ignore an explicit user requested commit (ie: 
> {{Ignoring commit while not ACTIVE - state: BUFFERING replay: false}}) but 
> still participate in queries -- apparently before they finish recovery (or at 
> the very least before / with-out doing the commit/openSearcher that they 
> previously ignored.
> Details and logs to follow...



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

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

[jira] [Commented] (SOLR-9366) replicas in LIR seem to still be participating in search requests

[ASF subversion and git services (JIRA)]

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

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

Commit 04321c401c6584395c76c509f8513c5e5e4730ee in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=04321c4 ]

SOLR-9363: tweak test to work around SOLR-9366 + SOLR-9367 since those issues 
are not key to what's being tested here


> replicas in LIR seem to still be participating in search requests
> -
>
> Key: SOLR-9366
> URL: https://issues.apache.org/jira/browse/SOLR-9366
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-9366.txt.gz
>
>
> Spinning this off from SOLR-9363 where sarowe's jenkins encountered a strange 
> test failure when TestInjection is used causing replicas to return errors on 
> some requests.
> Reading over the logs it appears that when this happens, and the replicas are 
> put into LIR they then ignore an explicit user requested commit (ie: 
> {{Ignoring commit while not ACTIVE - state: BUFFERING replay: false}}) but 
> still participate in queries -- apparently before they finish recovery (or at 
> the very least before / with-out doing the commit/openSearcher that they 
> previously ignored.
> Details and logs to follow...



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

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

[jira] [Commented] (SOLR-9363) TestStressCloudBlindAtomicUpdates.test_dv_stored() failure

[ASF subversion and git services (JIRA)]

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

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

Commit c17605b4a9978311b6b231f202d70dd800e473e6 in lucene-solr's branch 
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c17605b ]

SOLR-9363: tweak test to work around SOLR-9366 + SOLR-9367 since those issues 
are not key to what's being tested here

(cherry picked from commit 04321c401c6584395c76c509f8513c5e5e4730ee)


> TestStressCloudBlindAtomicUpdates.test_dv_stored() failure
> --
>
> Key: SOLR-9363
> URL: https://issues.apache.org/jira/browse/SOLR-9363
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Hoss Man
> Attachments: Lucene-Solr-Nightly-master.271.log.gz, SOLR-9363.patch
>
>
> My Jenkins found a reproducing seed - though note that in order to reproduce 
> I had to a) run the test at the same SHA as the one listed, and b) leave off 
> {{-Dtests.method=test_dv_stored}}; under those conditions it failed both 
> times I ran it:
> {noformat}
> Checking out Revision 53a34b312e78ce6f56c0bb41304ac834b28b9534 
> (refs/remotes/origin/master)
> [...]
>   [junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestStressCloudBlindAtomicUpdates -Dtests.method=test_dv_stored 
> -Dtests.seed=60C9AAFC94FD8921 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=id -Dtests.timezone=America/Puerto_Rico -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 9.09s J0 | 
> TestStressCloudBlindAtomicUpdates.test_dv_stored <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<332> but 
> was:<205>
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([60C9AAFC94FD8921:F2F5CB7828BAB4F9]:0)
>[junit4]>at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:253)
>[junit4]>at 
> org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv_stored(TestStressCloudBlindAtomicUpdates.java:192)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

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

[jira] [Commented] (SOLR-9371) Fix bin/solr script calculations - start/stop wait time and RMI_PORT

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9371:
--

Oh please commit this!

May I suggest the variable be renamed to SOLR_WAIT_TIME? Or maybe 
SOLR_STOP_WAIT? At any rate prefix it with SOLR I think...

Second, whatever the name, it should also be added to the solr.in.cmd for 
Windows users...


> Fix bin/solr script calculations - start/stop wait time and RMI_PORT
> 
>
> Key: SOLR-9371
> URL: https://issues.apache.org/jira/browse/SOLR-9371
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9371.patch, SOLR-9371.patch
>
>
> The bin/solr script doesn't wait long enough for Solr to stop before it sends 
> the KILL signal to the process.  The start could use a longer wait too.
> Also, the RMI_PORT is calculated by simply prefixing the port number with a 
> "1" instead of adding 1.  If the solr port has five digits, then the rmi 
> port will be invalid, because it will be greater than 65535.



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

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

[jira] [Updated] (SOLR-9200) Add Delegation Token Support to Solr

[Gregory Chanan (JIRA)]

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

Gregory Chanan updated SOLR-9200:
-
Attachment: SOLR-9200_branch_6x.patch

> Add Delegation Token Support to Solr
> 
>
> Key: SOLR-9200
> URL: https://issues.apache.org/jira/browse/SOLR-9200
> Project: Solr
>  Issue Type: New Feature
>  Components: security
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Attachments: SOLR-9200.patch, SOLR-9200.patch, SOLR-9200.patch, 
> SOLR-9200.patch, SOLR-9200.patch, SOLR-9200_branch_6x.patch, 
> SOLR-9200_branch_6x.patch, SOLR-9200_branch_6x.patch
>
>
> SOLR-7468 added support for kerberos authentication via the hadoop 
> authentication filter.  Hadoop also has support for an authentication filter 
> that supports delegation tokens, which allow authenticated users the ability 
> to grab/renew/delete a token that can be used to bypass the normal 
> authentication path for a time.  This is useful in a variety of use cases:
> 1) distributed clients (e.g. MapReduce) where each client may not have access 
> to the user's kerberos credentials.  Instead, the job runner can grab a 
> delegation token and use that during task execution.
> 2) If the load on the kerberos server is too high, delegation tokens can 
> avoid hitting the kerberos server after the first request
> 3) If requests/permissions need to be delegated to another user: the more 
> privileged user can request a delegation token that can be passed to the less 
> privileged user.
> Note to self:
> In 
> https://issues.apache.org/jira/browse/SOLR-7468?focusedCommentId=14579636=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14579636
>  I made the following comment which I need to investigate further, since I 
> don't know if anything changed in this area:
> {quote}3) I'm a little concerned with the "NoContext" code in KerberosPlugin 
> moving forward (I understand this is more a generic auth question than 
> kerberos specific). For example, in the latest version of the filter we are 
> using at Cloudera, we play around with the ServletContext in order to pass 
> information around 
> (https://github.com/cloudera/lucene-solr/blob/cdh5-4.10.3_5.4.2/solr/core/src/java/org/apache/solr/servlet/SolrHadoopAuthenticationFilter.java#L106).
>  Is there any way we can get the actual ServletContext in a plugin?{quote}



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

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

[jira] [Commented] (SOLR-9200) Add Delegation Token Support to Solr

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9200: Prepare Locale before starting MiniKdc


> Add Delegation Token Support to Solr
> 
>
> Key: SOLR-9200
> URL: https://issues.apache.org/jira/browse/SOLR-9200
> Project: Solr
>  Issue Type: New Feature
>  Components: security
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Attachments: SOLR-9200.patch, SOLR-9200.patch, SOLR-9200.patch, 
> SOLR-9200.patch, SOLR-9200.patch, SOLR-9200_branch_6x.patch, 
> SOLR-9200_branch_6x.patch
>
>
> SOLR-7468 added support for kerberos authentication via the hadoop 
> authentication filter.  Hadoop also has support for an authentication filter 
> that supports delegation tokens, which allow authenticated users the ability 
> to grab/renew/delete a token that can be used to bypass the normal 
> authentication path for a time.  This is useful in a variety of use cases:
> 1) distributed clients (e.g. MapReduce) where each client may not have access 
> to the user's kerberos credentials.  Instead, the job runner can grab a 
> delegation token and use that during task execution.
> 2) If the load on the kerberos server is too high, delegation tokens can 
> avoid hitting the kerberos server after the first request
> 3) If requests/permissions need to be delegated to another user: the more 
> privileged user can request a delegation token that can be passed to the less 
> privileged user.
> Note to self:
> In 
> https://issues.apache.org/jira/browse/SOLR-7468?focusedCommentId=14579636=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14579636
>  I made the following comment which I need to investigate further, since I 
> don't know if anything changed in this area:
> {quote}3) I'm a little concerned with the "NoContext" code in KerberosPlugin 
> moving forward (I understand this is more a generic auth question than 
> kerberos specific). For example, in the latest version of the filter we are 
> using at Cloudera, we play around with the ServletContext in order to pass 
> information around 
> (https://github.com/cloudera/lucene-solr/blob/cdh5-4.10.3_5.4.2/solr/core/src/java/org/apache/solr/servlet/SolrHadoopAuthenticationFilter.java#L106).
>  Is there any way we can get the actual ServletContext in a plugin?{quote}



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/756/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail

Error Message:
expected:<200> but was:<404>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([DD4D787FE82DC3EA:B5F24D5538B7D106]: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.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:140)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:295)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (SOLR-9371) Fix bin/solr script calculations - start/stop wait time and RMI_PORT

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-9371:
---
Attachment: SOLR-9371.patch

Updated patch.  Commented config section in solr.in.sh for configuring 
WAIT_TIME.

> Fix bin/solr script calculations - start/stop wait time and RMI_PORT
> 
>
> Key: SOLR-9371
> URL: https://issues.apache.org/jira/browse/SOLR-9371
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9371.patch, SOLR-9371.patch
>
>
> The bin/solr script doesn't wait long enough for Solr to stop before it sends 
> the KILL signal to the process.  The start could use a longer wait too.
> Also, the RMI_PORT is calculated by simply prefixing the port number with a 
> "1" instead of adding 1.  If the solr port has five digits, then the rmi 
> port will be invalid, because it will be greater than 65535.



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

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

[jira] [Commented] (SOLR-9371) Fix bin/solr script calculations - start/stop wait time and RMI_PORT

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-9371:


The wait time is configurable in solr.in.sh ... I should probably put a 
commented example in there.

> Fix bin/solr script calculations - start/stop wait time and RMI_PORT
> 
>
> Key: SOLR-9371
> URL: https://issues.apache.org/jira/browse/SOLR-9371
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9371.patch
>
>
> The bin/solr script doesn't wait long enough for Solr to stop before it sends 
> the KILL signal to the process.  The start could use a longer wait too.
> Also, the RMI_PORT is calculated by simply prefixing the port number with a 
> "1" instead of adding 1.  If the solr port has five digits, then the rmi 
> port will be invalid, because it will be greater than 65535.



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

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

[jira] [Updated] (SOLR-9371) Fix bin/solr script calculations - start/stop wait time and RMI_PORT

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-9371:
---
Summary: Fix bin/solr script calculations - start/stop wait time and 
RMI_PORT  (was: Fix script calculations - start/stop wait time and RMI_PORT)

> Fix bin/solr script calculations - start/stop wait time and RMI_PORT
> 
>
> Key: SOLR-9371
> URL: https://issues.apache.org/jira/browse/SOLR-9371
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9371.patch
>
>
> The bin/solr script doesn't wait long enough for Solr to stop before it sends 
> the KILL signal to the process.  The start could use a longer wait too.
> Also, the RMI_PORT is calculated by simply prefixing the port number with a 
> "1" instead of adding 1.  If the solr port has five digits, then the rmi 
> port will be invalid, because it will be greater than 65535.



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

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

[jira] [Updated] (SOLR-9371) Fix script calculations - start/stop wait time and RMI_PORT

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-9371:
---
Attachment: SOLR-9371.patch

Patch.

> Fix script calculations - start/stop wait time and RMI_PORT
> ---
>
> Key: SOLR-9371
> URL: https://issues.apache.org/jira/browse/SOLR-9371
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9371.patch
>
>
> The bin/solr script doesn't wait long enough for Solr to stop before it sends 
> the KILL signal to the process.  The start could use a longer wait too.
> Also, the RMI_PORT is calculated by simply prefixing the port number with a 
> "1" instead of adding 1.  If the solr port has five digits, then the rmi 
> port will be invalid, because it will be greater than 65535.



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

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

[jira] [Created] (SOLR-9371) Fix script calculations - start/stop wait time and RMI_PORT

[Shawn Heisey (JIRA)]

Shawn Heisey created SOLR-9371:
--

 Summary: Fix script calculations - start/stop wait time and 
RMI_PORT
 Key: SOLR-9371
 URL: https://issues.apache.org/jira/browse/SOLR-9371
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: scripts and tools
Affects Versions: 6.1
Reporter: Shawn Heisey
Assignee: Shawn Heisey
Priority: Minor
 Fix For: 6.2, master (7.0)


The bin/solr script doesn't wait long enough for Solr to stop before it sends 
the KILL signal to the process.  The start could use a longer wait too.

Also, the RMI_PORT is calculated by simply prefixing the port number with a "1" 
instead of adding 1.  If the solr port has five digits, then the rmi port 
will be invalid, because it will be greater than 65535.



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

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

[jira] [Commented] (SOLR-9368) FileDictionaryFactory does not treat lines beginning with '#' as comments

[John Iacona (JIRA)]

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

John Iacona commented on SOLR-9368:
---

Great, thanks!

> FileDictionaryFactory does not treat lines beginning with '#' as comments
> -
>
> Key: SOLR-9368
> URL: https://issues.apache.org/jira/browse/SOLR-9368
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 6.1
>Reporter: John Iacona
>Priority: Minor
>
> The documentation for FileDictionaryFactory states that "Blank lines and 
> lines that start with a '#' are ignored". This is not the case. When loading 
> a dictionary file with '#' prefixed lines, they just get interpreted as terms 
> and show up in suggestion results. 
> This causes additional confusion when trying to use payloads. As stated in 
> https://lucene.apache.org/core/6_1_0/suggest/org/apache/lucene/search/suggest/FileDictionary.html
>  : "In order to have payload enabled, the first entry has to have a payload". 
> However, if you happen to have a "comment" as the first line in a dictionary 
> file (that doesn't happen to have two instances of the fieldDelimiter in 
> it...), payloads are disabled.



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

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

[jira] [Commented] (SOLR-9353) factor out ReRankQParserPlugin.ReRankQueryRescorer private class

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-9353:
---

[~joel.bernstein] and everyone, would you have any thoughts on this small 
proposed refactor? Hoping to commit it later this week or early next week 
ideally. Thank you.

> factor out ReRankQParserPlugin.ReRankQueryRescorer private class
> 
>
> Key: SOLR-9353
> URL: https://issues.apache.org/jira/browse/SOLR-9353
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9353.patch
>
>
> To reduce the number of rescorer objects potentially created and also towards 
> (more) code sharing with SOLR-8542.



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

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

[jira] [Resolved] (SOLR-9368) FileDictionaryFactory does not treat lines beginning with '#' as comments

[JIRA]

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

Jan Høydahl resolved SOLR-9368.
---
Resolution: Not A Bug

Resolving as not a bug. I updated the text in 
https://cwiki.apache.org/confluence/display/solr/Suggester#Suggester-FileDictionaryFactory
 to be in line with the actual code, also removing the claim that blank lines 
are allowed. I also updated the example, replacing literal \t with a tab 
character.

> FileDictionaryFactory does not treat lines beginning with '#' as comments
> -
>
> Key: SOLR-9368
> URL: https://issues.apache.org/jira/browse/SOLR-9368
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 6.1
>Reporter: John Iacona
>Priority: Minor
>
> The documentation for FileDictionaryFactory states that "Blank lines and 
> lines that start with a '#' are ignored". This is not the case. When loading 
> a dictionary file with '#' prefixed lines, they just get interpreted as terms 
> and show up in suggestion results. 
> This causes additional confusion when trying to use payloads. As stated in 
> https://lucene.apache.org/core/6_1_0/suggest/org/apache/lucene/search/suggest/FileDictionary.html
>  : "In order to have payload enabled, the first entry has to have a payload". 
> However, if you happen to have a "comment" as the first line in a dictionary 
> file (that doesn't happen to have two instances of the fieldDelimiter in 
> it...), payloads are disabled.



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

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

[jira] [Commented] (SOLR-9368) FileDictionaryFactory does not treat lines beginning with '#' as comments

[John Iacona (JIRA)]

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

John Iacona commented on SOLR-9368:
---

I think updating the documentation is a fine fix. For me it was more a case of 
really confusing side effects than needing comments in a dictionary file.

> FileDictionaryFactory does not treat lines beginning with '#' as comments
> -
>
> Key: SOLR-9368
> URL: https://issues.apache.org/jira/browse/SOLR-9368
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 6.1
>Reporter: John Iacona
>Priority: Minor
>
> The documentation for FileDictionaryFactory states that "Blank lines and 
> lines that start with a '#' are ignored". This is not the case. When loading 
> a dictionary file with '#' prefixed lines, they just get interpreted as terms 
> and show up in suggestion results. 
> This causes additional confusion when trying to use payloads. As stated in 
> https://lucene.apache.org/core/6_1_0/suggest/org/apache/lucene/search/suggest/FileDictionary.html
>  : "In order to have payload enabled, the first entry has to have a payload". 
> However, if you happen to have a "comment" as the first line in a dictionary 
> file (that doesn't happen to have two instances of the fieldDelimiter in 
> it...), payloads are disabled.



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

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

[jira] [Commented] (SOLR-2499) Index-time boosts for multivalue fields are consolidated

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-2499:


bq.  (e.g. index the value twice)

Sure, and that's an easy way to do it albeit resulting in a stored-value 
potentially very large if you need to repeat tokens a lot.  A custom analyzer 
(i.e. analysis components generally) would allow you to parse custom syntax 
like {{cat|600 feline|100}}. You might take the code for 
DelimitedPayloadTokenFilter and modify it substantially to do what we're 
talking about here, and not use payloads.

> Index-time boosts for multivalue fields are consolidated
> 
>
> Key: SOLR-2499
> URL: https://issues.apache.org/jira/browse/SOLR-2499
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 3.1, 3.2, 4.0-ALPHA
>Reporter: Neil Hooey
>  Labels: boost, multivalue, multivalued
>
> Currently, if you boost a value in a multivalue field during index time, the 
> boosts are consolidated for every field, and the individual values are lost.
> So, for example, given a list of photos with a multivalue field "keywords", 
> and a boost for a keyword assigned to a photo corresponds to the number of 
> times that photo was downloaded after searching for that particular keyword, 
> we have documents like this:
> {code}
> photo1: Photo of a cat by itself
> keywords: [ cat:600 feline:100 ]
> => boost total = 700
> photo2: Photo of a cat driving a truck
> keywords: [ cat:100 feline:90 animal:80 truck:1000 ]
> => boost total = 1270
> {code}
> If you search for "cat feline", photo2 will rank higher, since the boost of 
> "cat-like" words was consolidated with the "truck" boost anomaly. Whereas 
> photo1, which has more downloads for "cat" and "feline", ranks lower with a 
> lower consolidated boost, even though the total boost for the relevant 
> keywords is higher than for photo1.
> *Intuitively, the boosts should be separate, so only the boosts for the terms 
> searched will be counted.*
> Given the current behaviour, you are forced to do one of the following:
> 1. Assemble all of the multi-values into a string, and use payloads in place 
> of boosts.
> 2. Use dynamic fields, such as keyword_*, and boost them independently.
> Neither of these solutions are ideal, as using payloads requires writing your 
> own BoostingTermQuery, and defining a new dynamic field per multi-value makes 
> searching more difficult than with multivalue fields.
> There's a blog entry that describes the current behaviour:
> http://blog.kapilchhabra.com/2008/01/solr-index-time-boost-facts-2



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17439/
Java: 64bit/jdk-9-ea+129 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  'X val' for path 'x' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{"wt":"json"},   
"context":{ "webapp":"", "path":"/test1", "httpMethod":"GET"},   
"class":"org.apache.solr.core.BlobStoreTestRequestHandler",   "x":null},  from 
server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'X val' for path 'x' 
full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"",
"path":"/test1",
"httpMethod":"GET"},
  "class":"org.apache.solr.core.BlobStoreTestRequestHandler",
  "x":null},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([241E962E0A044BF6:FC53BB79FDD9EE56]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:481)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:232)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Created] (SOLR-9370) Add sample code snippet to confluence documentaion for Basic Authentication

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-9370:
---

 Summary: Add sample code snippet to confluence documentaion for 
Basic Authentication
 Key: SOLR-9370
 URL: https://issues.apache.org/jira/browse/SOLR-9370
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: documentation
Reporter: Susheel Kumar
Priority: Minor


Please add below code snippet to under "Using BasicAuth with SolrJ"  as current 
code "snippet" doesn't give visibility on how basic authentication can be set 
when querying


How to set credentials when querying using SolrJ - Basic Authentication
=

SolrQuery query = new SolrQuery();
query.setQuery("*:*");
// Do any other query setup needed.

SolrRequest req = new QueryRequest(query);
req.setBasicAuthCredentials(userName, password); 

QueryResponse rsp = req.process(solrClient, collection);



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

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

[jira] [Commented] (SOLR-9179) Error Initializing Schema

[Colvin Cowie (JIRA)]

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

Colvin Cowie commented on SOLR-9179:


Yeah, that looks good.

> Error Initializing Schema 
> --
>
> Key: SOLR-9179
> URL: https://issues.apache.org/jira/browse/SOLR-9179
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 6.0.1
> Environment: SOLR 6.0.1 running under Tomcat 8.0.35 on IBM System I
>Reporter: Andrew Bennison
>Assignee: Noble Paul
> Attachments: SOLR-9179.patch, solr.log
>
>
> After upgrade from 6.0.0 to 6.0.1 am getting Schema Initialization Errors.
> If I switch from ClassicSchema to Managed the Core will load first time, 
> however subsequent loads will fail.
> Error received is :
> org.apache.solr.common.SolrException: java.lang.ExceptionInInitializerError
>   at org.apache.solr.core.SolrCore.(SolrCore.java:771)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:642)
>   at org.apache.solr.core.CoreContainer.create(CoreContainer.java:817)
>   at org.apache.solr.core.CoreContainer.access$000(CoreContainer.java:88)
>   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:468)
>   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:459)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:277)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$1.948BC950.run(Unknown
>  Source)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.BootstrapMethodError: 
> java.lang.ExceptionInInitializerError
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps$Handler.(IndexSchema.java:1392)
>   at org.apache.solr.handler.SchemaHandler.(SchemaHandler.java:62)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:343)
>   at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:530)
>   at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:467)
>   at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:565)
>   at org.apache.solr.core.PluginBag.createPlugin(PluginBag.java:121)
>   at org.apache.solr.core.PluginBag.init(PluginBag.java:221)
>   at 
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:130)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:727)
>   ... 11 more
> Caused by: java.lang.ExceptionInInitializerError
>   at java.lang.J9VMInternals.ensureError(J9VMInternals.java:137)
>   at 
> java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:126)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:343)
>   at 
> java.lang.invoke.MethodType.nonPrimitiveClassFromString(MethodType.java:311)
>   at java.lang.invoke.MethodType.parseIntoClasses(MethodType.java:373)
>   at 
> java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:286)
>   at 
> java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:961)
>   at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
>   at 
> java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:852)
>   ... 22 more
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps$Handler.values(IndexSchema.java:1391)
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps.(IndexSchema.java:1503)
>   ... 30 more



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

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

[jira] [Created] (SOLR-9369) SolrCloud should not compare commitTimeMSec to see if replicas are in sync

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-9369:
---

 Summary: SolrCloud should not compare commitTimeMSec to see if 
replicas are in sync
 Key: SOLR-9369
 URL: https://issues.apache.org/jira/browse/SOLR-9369
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker


Today the replication code we compare if two replicas are in sync by checking 
the commit timestamp ( "commitTimeMSec" ) 

This made sense for master slave but I don't think is useful for SolrCloud 
since different replicas will commit at different times. We should not check 
for this in SolrCloud mode.

Ramkumar noted this on SOLR-7859 as well.



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

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

[jira] [Assigned] (SOLR-9179) Error Initializing Schema

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-9179:


Assignee: Noble Paul

> Error Initializing Schema 
> --
>
> Key: SOLR-9179
> URL: https://issues.apache.org/jira/browse/SOLR-9179
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 6.0.1
> Environment: SOLR 6.0.1 running under Tomcat 8.0.35 on IBM System I
>Reporter: Andrew Bennison
>Assignee: Noble Paul
> Attachments: SOLR-9179.patch, solr.log
>
>
> After upgrade from 6.0.0 to 6.0.1 am getting Schema Initialization Errors.
> If I switch from ClassicSchema to Managed the Core will load first time, 
> however subsequent loads will fail.
> Error received is :
> org.apache.solr.common.SolrException: java.lang.ExceptionInInitializerError
>   at org.apache.solr.core.SolrCore.(SolrCore.java:771)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:642)
>   at org.apache.solr.core.CoreContainer.create(CoreContainer.java:817)
>   at org.apache.solr.core.CoreContainer.access$000(CoreContainer.java:88)
>   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:468)
>   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:459)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:277)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$1.948BC950.run(Unknown
>  Source)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.BootstrapMethodError: 
> java.lang.ExceptionInInitializerError
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps$Handler.(IndexSchema.java:1392)
>   at org.apache.solr.handler.SchemaHandler.(SchemaHandler.java:62)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:343)
>   at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:530)
>   at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:467)
>   at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:565)
>   at org.apache.solr.core.PluginBag.createPlugin(PluginBag.java:121)
>   at org.apache.solr.core.PluginBag.init(PluginBag.java:221)
>   at 
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:130)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:727)
>   ... 11 more
> Caused by: java.lang.ExceptionInInitializerError
>   at java.lang.J9VMInternals.ensureError(J9VMInternals.java:137)
>   at 
> java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:126)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:343)
>   at 
> java.lang.invoke.MethodType.nonPrimitiveClassFromString(MethodType.java:311)
>   at java.lang.invoke.MethodType.parseIntoClasses(MethodType.java:373)
>   at 
> java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:286)
>   at 
> java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:961)
>   at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
>   at 
> java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:852)
>   ... 22 more
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps$Handler.values(IndexSchema.java:1391)
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps.(IndexSchema.java:1503)
>   ... 30 more



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

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

[jira] [Updated] (SOLR-9179) Error Initializing Schema

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9179:
-
Attachment: SOLR-9179.patch

[~cjcowie] Is this correct?

> Error Initializing Schema 
> --
>
> Key: SOLR-9179
> URL: https://issues.apache.org/jira/browse/SOLR-9179
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 6.0.1
> Environment: SOLR 6.0.1 running under Tomcat 8.0.35 on IBM System I
>Reporter: Andrew Bennison
> Attachments: SOLR-9179.patch, solr.log
>
>
> After upgrade from 6.0.0 to 6.0.1 am getting Schema Initialization Errors.
> If I switch from ClassicSchema to Managed the Core will load first time, 
> however subsequent loads will fail.
> Error received is :
> org.apache.solr.common.SolrException: java.lang.ExceptionInInitializerError
>   at org.apache.solr.core.SolrCore.(SolrCore.java:771)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:642)
>   at org.apache.solr.core.CoreContainer.create(CoreContainer.java:817)
>   at org.apache.solr.core.CoreContainer.access$000(CoreContainer.java:88)
>   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:468)
>   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:459)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:277)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$1.948BC950.run(Unknown
>  Source)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.BootstrapMethodError: 
> java.lang.ExceptionInInitializerError
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps$Handler.(IndexSchema.java:1392)
>   at org.apache.solr.handler.SchemaHandler.(SchemaHandler.java:62)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:343)
>   at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:530)
>   at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:467)
>   at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:565)
>   at org.apache.solr.core.PluginBag.createPlugin(PluginBag.java:121)
>   at org.apache.solr.core.PluginBag.init(PluginBag.java:221)
>   at 
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:130)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:727)
>   ... 11 more
> Caused by: java.lang.ExceptionInInitializerError
>   at java.lang.J9VMInternals.ensureError(J9VMInternals.java:137)
>   at 
> java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:126)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:343)
>   at 
> java.lang.invoke.MethodType.nonPrimitiveClassFromString(MethodType.java:311)
>   at java.lang.invoke.MethodType.parseIntoClasses(MethodType.java:373)
>   at 
> java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:286)
>   at 
> java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:961)
>   at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
>   at 
> java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:852)
>   ... 22 more
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps$Handler.values(IndexSchema.java:1391)
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps.(IndexSchema.java:1503)
>   ... 30 more



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

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

[jira] [Commented] (SOLR-9368) FileDictionaryFactory does not treat lines beginning with '#' as comments

[JIRA]

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

Jan Høydahl commented on SOLR-9368:
---

FileDictionary.java does not mention the support for comment lines and does not 
implement it either. So the easiest is to treat this as a documentation bug in 
the RefGuide: 
https://cwiki.apache.org/confluence/display/solr/Suggester#Suggester-FileDictionaryFactory
 and change that.

If not, this should be changed into a LUCENE issue for code changes, but then 
it must be a feature request and not a Bug, since the Lucene documentation 
(Javadoc) is fully in line with the code...

> FileDictionaryFactory does not treat lines beginning with '#' as comments
> -
>
> Key: SOLR-9368
> URL: https://issues.apache.org/jira/browse/SOLR-9368
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 6.1
>Reporter: John Iacona
>Priority: Minor
>
> The documentation for FileDictionaryFactory states that "Blank lines and 
> lines that start with a '#' are ignored". This is not the case. When loading 
> a dictionary file with '#' prefixed lines, they just get interpreted as terms 
> and show up in suggestion results. 
> This causes additional confusion when trying to use payloads. As stated in 
> https://lucene.apache.org/core/6_1_0/suggest/org/apache/lucene/search/suggest/FileDictionary.html
>  : "In order to have payload enabled, the first entry has to have a payload". 
> However, if you happen to have a "comment" as the first line in a dictionary 
> file (that doesn't happen to have two instances of the fieldDelimiter in 
> it...), payloads are disabled.



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

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

[jira] [Commented] (SOLR-9256) Solr 6.x DataImportHandler fails with postgreSQL dataSource with multiple joined entities

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9209,SOLR-9256: extracting
JdbcDataSource.createResultSetIterator(), adding a test for
ResultSetIterator.hasNext() 

> Solr 6.x DataImportHandler fails with postgreSQL dataSource with multiple 
> joined entities
> -
>
> Key: SOLR-9256
> URL: https://issues.apache.org/jira/browse/SOLR-9256
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Affects Versions: 6.0, 6.0.1
> Environment: Solr 6.0, 6.0.1 Single Instance or SolrCloud with 
> postgreSQL 9.4 Server on Java Version 1.8.0_91 runtime
>Reporter: Benjamin Richter
> Fix For: 6.0.2, 6.1, 6.1.1, 6.2, master (7.0)
>
> Attachments: SOLR-9256.patch
>
>
> h1. solr-data-config.xml
> {code:xml}
> 
>url="jdbc:postgresql://host:5432/database" user="username" 
> password="password" readOnly="true" autoCommit="false" />
>   
> 
>   
>   
>   
>  cacheKey="a_id" cacheLookup="outer.id" 
> cacheImpl="SortedMapBackedCache">
>   
>   
>   
>  cacheKey="a_id" cacheLookup="outer.id" 
> join="zipper">
>   
>   
>   
>   
> 
> {code}
> This works up to SOLR 5.5.2 (latest 5.x) but fails in SOLR 6.x.
> Exception:
> org.apache.solr.handler.dataimport.DataImportHandlerException: 
> org.postgresql.util.PSQLException: Dieses ResultSet ist geschlossen.
> at 
> org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:61)
> at 
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:434)
> at 
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator$1.hasNext(JdbcDataSource.java:350)
> at 
> com.google.common.collect.Iterators$PeekingImpl.hasNext(Iterators.java:1216)
> at 
> org.apache.solr.handler.dataimport.Zipper.supplyNextChild(Zipper.java:65)
> at 
> org.apache.solr.handler.dataimport.EntityProcessorBase.getNext(EntityProcessorBase.java:127)
> at 
> org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:75)
> at 
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:244)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:475)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:514)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:414)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:329)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:232)
> at 
> org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:416)
> at 
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:480)
> at 
> org.apache.solr.handler.dataimport.DataImportHandler.handleRequestBody(DataImportHandler.java:200)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2053)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> 

[jira] [Commented] (SOLR-9209) DIH JdbcDataSource - improve extensibility part 2

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9209,SOLR-9256: extracting
JdbcDataSource.createResultSetIterator(), adding a test for
ResultSetIterator.hasNext() 

> DIH JdbcDataSource - improve extensibility part 2
> -
>
> Key: SOLR-9209
> URL: https://issues.apache.org/jira/browse/SOLR-9209
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Attachments: SOLR-9209.patch, SOLR-9209.patch
>
>
> This is a follow up to SOLR-8616. Due to changes in SOLR-8612 it's now no 
> longer possible without additional modifications to use a different 
> {{ResultSetIterator}} class. The attached patch solves this.



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

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

[jira] [Comment Edited] (SOLR-9179) Error Initializing Schema

[Colvin Cowie (JIRA)]

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

Colvin Cowie edited comment on SOLR-9179 at 8/2/16 12:13 PM:
-

So, in {{org.apache.solr.schema.IndexSchema}} it's a case of moving line 1503 
below 1505. i.e. move {{nameMapping}} out of {{SchemaProps}} and into 
{{IndexSchema}} itself.

The other 2 changes are just to just to fix the knock on effects, which Eclipse 
will show up readily - update the references to {{Handler}} in the 
{{nameMapping}} definition and the reference to {{nameMapping}} in 
{{org.apache.solr.schema.IndexSchema.SchemaProps}}.



was (Author: cjcowie):
So, in org.apache.solr.schema.IndexSchema it's a case of moving line 1503 below 
1505. i.e. move nameMapping out of SchemaProps and into IndexSchema itself.

The other 2 changes are just to just to fix the knock on effects, which Eclipse 
will show up readily - update the references to Handler in the nameMapping 
definition and the reference to nameMapping in 
org.apache.solr.schema.IndexSchema.SchemaProps.


> Error Initializing Schema 
> --
>
> Key: SOLR-9179
> URL: https://issues.apache.org/jira/browse/SOLR-9179
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 6.0.1
> Environment: SOLR 6.0.1 running under Tomcat 8.0.35 on IBM System I
>Reporter: Andrew Bennison
> Attachments: solr.log
>
>
> After upgrade from 6.0.0 to 6.0.1 am getting Schema Initialization Errors.
> If I switch from ClassicSchema to Managed the Core will load first time, 
> however subsequent loads will fail.
> Error received is :
> org.apache.solr.common.SolrException: java.lang.ExceptionInInitializerError
>   at org.apache.solr.core.SolrCore.(SolrCore.java:771)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:642)
>   at org.apache.solr.core.CoreContainer.create(CoreContainer.java:817)
>   at org.apache.solr.core.CoreContainer.access$000(CoreContainer.java:88)
>   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:468)
>   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:459)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:277)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$1.948BC950.run(Unknown
>  Source)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.BootstrapMethodError: 
> java.lang.ExceptionInInitializerError
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps$Handler.(IndexSchema.java:1392)
>   at org.apache.solr.handler.SchemaHandler.(SchemaHandler.java:62)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:343)
>   at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:530)
>   at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:467)
>   at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:565)
>   at org.apache.solr.core.PluginBag.createPlugin(PluginBag.java:121)
>   at org.apache.solr.core.PluginBag.init(PluginBag.java:221)
>   at 
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:130)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:727)
>   ... 11 more
> Caused by: java.lang.ExceptionInInitializerError
>   at java.lang.J9VMInternals.ensureError(J9VMInternals.java:137)
>   at 
> java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:126)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:343)
>   at 
> java.lang.invoke.MethodType.nonPrimitiveClassFromString(MethodType.java:311)
>   at java.lang.invoke.MethodType.parseIntoClasses(MethodType.java:373)
>   at 
> java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:286)
>   at 
> java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:961)
>   at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
>   at 
> java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:852)
>   ... 22 more
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps$Handler.values(IndexSchema.java:1391)
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps.(IndexSchema.java:1503)
>   ... 30 more



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

[jira] [Commented] (SOLR-9179) Error Initializing Schema

[Colvin Cowie (JIRA)]

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

Colvin Cowie commented on SOLR-9179:


So, in org.apache.solr.schema.IndexSchema it's a case of moving line 1503 below 
1505. i.e. move nameMapping out of SchemaProps and into IndexSchema itself.

The other 2 changes are just to just to fix the knock on effects, which Eclipse 
will show up readily - update the references to Handler in the nameMapping 
definition and the reference to nameMapping in 
org.apache.solr.schema.IndexSchema.SchemaProps.


> Error Initializing Schema 
> --
>
> Key: SOLR-9179
> URL: https://issues.apache.org/jira/browse/SOLR-9179
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 6.0.1
> Environment: SOLR 6.0.1 running under Tomcat 8.0.35 on IBM System I
>Reporter: Andrew Bennison
> Attachments: solr.log
>
>
> After upgrade from 6.0.0 to 6.0.1 am getting Schema Initialization Errors.
> If I switch from ClassicSchema to Managed the Core will load first time, 
> however subsequent loads will fail.
> Error received is :
> org.apache.solr.common.SolrException: java.lang.ExceptionInInitializerError
>   at org.apache.solr.core.SolrCore.(SolrCore.java:771)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:642)
>   at org.apache.solr.core.CoreContainer.create(CoreContainer.java:817)
>   at org.apache.solr.core.CoreContainer.access$000(CoreContainer.java:88)
>   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:468)
>   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:459)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:277)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$1.948BC950.run(Unknown
>  Source)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.BootstrapMethodError: 
> java.lang.ExceptionInInitializerError
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps$Handler.(IndexSchema.java:1392)
>   at org.apache.solr.handler.SchemaHandler.(SchemaHandler.java:62)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:343)
>   at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:530)
>   at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:467)
>   at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:565)
>   at org.apache.solr.core.PluginBag.createPlugin(PluginBag.java:121)
>   at org.apache.solr.core.PluginBag.init(PluginBag.java:221)
>   at 
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:130)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:727)
>   ... 11 more
> Caused by: java.lang.ExceptionInInitializerError
>   at java.lang.J9VMInternals.ensureError(J9VMInternals.java:137)
>   at 
> java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:126)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:343)
>   at 
> java.lang.invoke.MethodType.nonPrimitiveClassFromString(MethodType.java:311)
>   at java.lang.invoke.MethodType.parseIntoClasses(MethodType.java:373)
>   at 
> java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:286)
>   at 
> java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:961)
>   at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
>   at 
> java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:852)
>   ... 22 more
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps$Handler.values(IndexSchema.java:1391)
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps.(IndexSchema.java:1503)
>   ... 30 more



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

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

[jira] [Updated] (SOLR-9368) FileDictionaryFactory does not treat lines beginning with '#' as comments

[JIRA]

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

Jan Høydahl updated SOLR-9368:
--
Description: 
The documentation for FileDictionaryFactory states that "Blank lines and lines 
that start with a '#' are ignored". This is not the case. When loading a 
dictionary file with '#' prefixed lines, they just get interpreted as terms and 
show up in suggestion results. 

This causes additional confusion when trying to use payloads. As stated in 
https://lucene.apache.org/core/6_1_0/suggest/org/apache/lucene/search/suggest/FileDictionary.html
 : "In order to have payload enabled, the first entry has to have a payload". 
However, if you happen to have a "comment" as the first line in a dictionary 
file (that doesn't happen to have two instances of the fieldDelimiter in 
it...), payloads are disabled.

  was:
The documentation for FileDictionaryFactory states that "Blank lines and lines 
that start with a '#' are ignored". This is not the case. When loading a 
dictionary file with '#' prefixed lines, they just get interpreted as terms and 
show up in suggestion results. 

This causes additional confusion when trying to use payloads. As stated in 
https://lucene.apache.org/core/6_1_0/suggest/org/apache/lucene/search/suggest/FileDictionary.html:
 "In order to have payload enabled, the first entry has to have a payload". 
However, if you happen to have a "comment" as the first line in a dictionary 
file (that doesn't happen to have two instances of the fieldDelimiter in 
it...), payloads are disabled.


> FileDictionaryFactory does not treat lines beginning with '#' as comments
> -
>
> Key: SOLR-9368
> URL: https://issues.apache.org/jira/browse/SOLR-9368
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 6.1
>Reporter: John Iacona
>Priority: Minor
>
> The documentation for FileDictionaryFactory states that "Blank lines and 
> lines that start with a '#' are ignored". This is not the case. When loading 
> a dictionary file with '#' prefixed lines, they just get interpreted as terms 
> and show up in suggestion results. 
> This causes additional confusion when trying to use payloads. As stated in 
> https://lucene.apache.org/core/6_1_0/suggest/org/apache/lucene/search/suggest/FileDictionary.html
>  : "In order to have payload enabled, the first entry has to have a payload". 
> However, if you happen to have a "comment" as the first line in a dictionary 
> file (that doesn't happen to have two instances of the fieldDelimiter in 
> it...), payloads are disabled.



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

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

[jira] [Issue Comment Deleted] (SOLR-9179) Error Initializing Schema

[Colvin Cowie (JIRA)]

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

Colvin Cowie updated SOLR-9179:
---
Comment: was deleted

(was: So, in {{org.apache.solr.schema.IndexSchema}} it's a case of moving line 
1503 below 1505. i.e. move {{nameMapping}} out of {{SchemaProps}} and into 
{{IndexSchema}} itself.

The other 2 changes are just to update the references to {{Handler}} in the 
{{nameMapping}} definition and the reference to {{nameMapping}} in 
{{org.apache.solr.schema.IndexSchema.SchemaProps}}, which Eclipse will show up 
readily.)

> Error Initializing Schema 
> --
>
> Key: SOLR-9179
> URL: https://issues.apache.org/jira/browse/SOLR-9179
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 6.0.1
> Environment: SOLR 6.0.1 running under Tomcat 8.0.35 on IBM System I
>Reporter: Andrew Bennison
> Attachments: solr.log
>
>
> After upgrade from 6.0.0 to 6.0.1 am getting Schema Initialization Errors.
> If I switch from ClassicSchema to Managed the Core will load first time, 
> however subsequent loads will fail.
> Error received is :
> org.apache.solr.common.SolrException: java.lang.ExceptionInInitializerError
>   at org.apache.solr.core.SolrCore.(SolrCore.java:771)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:642)
>   at org.apache.solr.core.CoreContainer.create(CoreContainer.java:817)
>   at org.apache.solr.core.CoreContainer.access$000(CoreContainer.java:88)
>   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:468)
>   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:459)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:277)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$1.948BC950.run(Unknown
>  Source)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.BootstrapMethodError: 
> java.lang.ExceptionInInitializerError
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps$Handler.(IndexSchema.java:1392)
>   at org.apache.solr.handler.SchemaHandler.(SchemaHandler.java:62)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:343)
>   at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:530)
>   at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:467)
>   at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:565)
>   at org.apache.solr.core.PluginBag.createPlugin(PluginBag.java:121)
>   at org.apache.solr.core.PluginBag.init(PluginBag.java:221)
>   at 
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:130)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:727)
>   ... 11 more
> Caused by: java.lang.ExceptionInInitializerError
>   at java.lang.J9VMInternals.ensureError(J9VMInternals.java:137)
>   at 
> java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:126)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:343)
>   at 
> java.lang.invoke.MethodType.nonPrimitiveClassFromString(MethodType.java:311)
>   at java.lang.invoke.MethodType.parseIntoClasses(MethodType.java:373)
>   at 
> java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:286)
>   at 
> java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:961)
>   at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
>   at 
> java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:852)
>   ... 22 more
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps$Handler.values(IndexSchema.java:1391)
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps.(IndexSchema.java:1503)
>   ... 30 more



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3450/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:57961/xq_rjn/h/forceleader_test_collection_shard1_replica2]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:57961/xq_rjn/h/forceleader_test_collection_shard1_replica2]
at 
__randomizedtesting.SeedInfo.seed([BFCFDB15C9A12EFB:5958EFD5F023D79A]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:774)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
at 
org.apache.solr.cloud.ForceLeaderTest.assertSendDocFails(ForceLeaderTest.java:315)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:110)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Commented] (SOLR-9256) Solr 6.x DataImportHandler fails with postgreSQL dataSource with multiple joined entities

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9209,SOLR-9256: extracting
JdbcDataSource.createResultSetIterator(), adding a test for
ResultSetIterator.hasNext() 

> Solr 6.x DataImportHandler fails with postgreSQL dataSource with multiple 
> joined entities
> -
>
> Key: SOLR-9256
> URL: https://issues.apache.org/jira/browse/SOLR-9256
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Affects Versions: 6.0, 6.0.1
> Environment: Solr 6.0, 6.0.1 Single Instance or SolrCloud with 
> postgreSQL 9.4 Server on Java Version 1.8.0_91 runtime
>Reporter: Benjamin Richter
> Fix For: 6.0.2, 6.1, 6.1.1, 6.2, master (7.0)
>
> Attachments: SOLR-9256.patch
>
>
> h1. solr-data-config.xml
> {code:xml}
> 
>url="jdbc:postgresql://host:5432/database" user="username" 
> password="password" readOnly="true" autoCommit="false" />
>   
> 
>   
>   
>   
>  cacheKey="a_id" cacheLookup="outer.id" 
> cacheImpl="SortedMapBackedCache">
>   
>   
>   
>  cacheKey="a_id" cacheLookup="outer.id" 
> join="zipper">
>   
>   
>   
>   
> 
> {code}
> This works up to SOLR 5.5.2 (latest 5.x) but fails in SOLR 6.x.
> Exception:
> org.apache.solr.handler.dataimport.DataImportHandlerException: 
> org.postgresql.util.PSQLException: Dieses ResultSet ist geschlossen.
> at 
> org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:61)
> at 
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:434)
> at 
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator$1.hasNext(JdbcDataSource.java:350)
> at 
> com.google.common.collect.Iterators$PeekingImpl.hasNext(Iterators.java:1216)
> at 
> org.apache.solr.handler.dataimport.Zipper.supplyNextChild(Zipper.java:65)
> at 
> org.apache.solr.handler.dataimport.EntityProcessorBase.getNext(EntityProcessorBase.java:127)
> at 
> org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:75)
> at 
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:244)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:475)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:514)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:414)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:329)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:232)
> at 
> org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:416)
> at 
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:480)
> at 
> org.apache.solr.handler.dataimport.DataImportHandler.handleRequestBody(DataImportHandler.java:200)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2053)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 

[jira] [Commented] (SOLR-9209) DIH JdbcDataSource - improve extensibility part 2

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9209,SOLR-9256: extracting
JdbcDataSource.createResultSetIterator(), adding a test for
ResultSetIterator.hasNext() 

> DIH JdbcDataSource - improve extensibility part 2
> -
>
> Key: SOLR-9209
> URL: https://issues.apache.org/jira/browse/SOLR-9209
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Attachments: SOLR-9209.patch, SOLR-9209.patch
>
>
> This is a follow up to SOLR-8616. Due to changes in SOLR-8612 it's now no 
> longer possible without additional modifications to use a different 
> {{ResultSetIterator}} class. The attached patch solves this.



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

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

[jira] [Commented] (SOLR-9179) Error Initializing Schema

[Colvin Cowie (JIRA)]

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

Colvin Cowie commented on SOLR-9179:


So, in {{org.apache.solr.schema.IndexSchema}} it's a case of moving line 1503 
below 1505. i.e. move {{nameMapping}} out of {{SchemaProps}} and into 
{{IndexSchema}} itself.

The other 2 changes are just to update the references to {{Handler}} in the 
{{nameMapping}} definition and the reference to {{nameMapping}} in 
{{org.apache.solr.schema.IndexSchema.SchemaProps}}, which Eclipse will show up 
readily.

> Error Initializing Schema 
> --
>
> Key: SOLR-9179
> URL: https://issues.apache.org/jira/browse/SOLR-9179
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 6.0.1
> Environment: SOLR 6.0.1 running under Tomcat 8.0.35 on IBM System I
>Reporter: Andrew Bennison
> Attachments: solr.log
>
>
> After upgrade from 6.0.0 to 6.0.1 am getting Schema Initialization Errors.
> If I switch from ClassicSchema to Managed the Core will load first time, 
> however subsequent loads will fail.
> Error received is :
> org.apache.solr.common.SolrException: java.lang.ExceptionInInitializerError
>   at org.apache.solr.core.SolrCore.(SolrCore.java:771)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:642)
>   at org.apache.solr.core.CoreContainer.create(CoreContainer.java:817)
>   at org.apache.solr.core.CoreContainer.access$000(CoreContainer.java:88)
>   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:468)
>   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:459)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:277)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>   at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$1.948BC950.run(Unknown
>  Source)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.BootstrapMethodError: 
> java.lang.ExceptionInInitializerError
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps$Handler.(IndexSchema.java:1392)
>   at org.apache.solr.handler.SchemaHandler.(SchemaHandler.java:62)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:343)
>   at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:530)
>   at 
> org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:467)
>   at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:565)
>   at org.apache.solr.core.PluginBag.createPlugin(PluginBag.java:121)
>   at org.apache.solr.core.PluginBag.init(PluginBag.java:221)
>   at 
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:130)
>   at org.apache.solr.core.SolrCore.(SolrCore.java:727)
>   ... 11 more
> Caused by: java.lang.ExceptionInInitializerError
>   at java.lang.J9VMInternals.ensureError(J9VMInternals.java:137)
>   at 
> java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:126)
>   at java.lang.Class.forNameImpl(Native Method)
>   at java.lang.Class.forName(Class.java:343)
>   at 
> java.lang.invoke.MethodType.nonPrimitiveClassFromString(MethodType.java:311)
>   at java.lang.invoke.MethodType.parseIntoClasses(MethodType.java:373)
>   at 
> java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:286)
>   at 
> java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:961)
>   at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
>   at 
> java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:852)
>   ... 22 more
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps$Handler.values(IndexSchema.java:1391)
>   at 
> org.apache.solr.schema.IndexSchema$SchemaProps.(IndexSchema.java:1503)
>   ... 30 more



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

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

[jira] [Commented] (SOLR-7562) ENABLE_REMOTE_JMX_OPTS=true without Host Name specified.

[Dan (JIRA)]

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

Dan commented on SOLR-7562:
---

On debian/ubuntu, enabling this will make the init-script hang for a while, 
then fail without explanation and Solr never gets started. 

It was only when finding this bugreport, that i found out i had to add the 
hostname in /etc/hosts, which isnt there by default on many cloud hosts, 
including amazon.

> ENABLE_REMOTE_JMX_OPTS=true without Host Name specified. 
> -
>
> Key: SOLR-7562
> URL: https://issues.apache.org/jira/browse/SOLR-7562
> Project: Solr
>  Issue Type: Improvement
>  Components: JMX, scripts and tools
>Affects Versions: 5.1
> Environment: Centos 6.6 
>Reporter: Shreejay
>Priority: Minor
>  Labels: improvement, suggestion
>
> This is not a big issue, but might be confusing for new users if they do not 
> have the hostname set in their servers. 
> Steps taken to reproduce the issue:
> 1) Downloaded solr tar file to /opt folder. 
> 2)Extract install_solr_service.sh file
> {quote} tar xzf solr-5.1.0.tgz solr-5.1.0/bin/install_solr_service.sh 
> --strip-components=2{quote}
> 3) run install_solr_service.sh file. 
> {quote}
> sudo bash ./install_solr_service.sh solr-5.1.0.tgz
> {quote}
> The above step starts solr with default options. 
> 4) Stop solr - {quote}service solr stop{quote} 
> 5) Change the JMX options in include folder at /var/solr/solr.in.sh
> {quote}
> ENABLE_REMOTE_JMX_OPTS="true"
> {quote}
> 6) Start solr again 
> {quote}
> service solr start 
> {quote}
> if the host name is not specified in /etc/hosts file, following message is 
> displayed
> {quote} 
> tail: cannot open `/var/solr/logs/solr' for reading: No such file or directory
> tail: no files remaining
> {quote}
> solr-8983-console.log file in /var/solr/logs shows the following output
> {quote}
> Error: Exception thrown by the agent : java.net.MalformedURLException: Local 
> host name unknown: java.net.UnknownHostException: SERVERNAME: SERVERNAME: 
> unknown error
> {quote}
> The error occurs if the /etc/hosts file does not have an entry for 
> SERVERNAME. 
> Setting SOLR_HOST=SERVERNAME in solr.in.sh also does not help. 
> Suggestion:
> May be add a message info message when ENABLE_REMOTE_JMX_OPTS=true. 



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/359/
Java: 64bit/jdk1.8.0_102 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.component.DistributedMLTComponentTest

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.handler.component.DistributedMLTComponentTest_7FEE6F4C48AF1F6F-001\tempDir-001\shard2\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.DistributedMLTComponentTest_7FEE6F4C48AF1F6F-001\tempDir-001\shard2\collection1

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

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.DistributedMLTComponentTest_7FEE6F4C48AF1F6F-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.DistributedMLTComponentTest_7FEE6F4C48AF1F6F-001\tempDir-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.handler.component.DistributedMLTComponentTest_7FEE6F4C48AF1F6F-001\tempDir-001\shard2\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.DistributedMLTComponentTest_7FEE6F4C48AF1F6F-001\tempDir-001\shard2\collection1
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.DistributedMLTComponentTest_7FEE6F4C48AF1F6F-001\tempDir-001\shard2:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.DistributedMLTComponentTest_7FEE6F4C48AF1F6F-001\tempDir-001\shard2
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.DistributedMLTComponentTest_7FEE6F4C48AF1F6F-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.DistributedMLTComponentTest_7FEE6F4C48AF1F6F-001\tempDir-001

at __randomizedtesting.SeedInfo.seed([7FEE6F4C48AF1F6F]: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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12055 lines...]
   [junit4] Suite: org.apache.solr.handler.component.DistributedMLTComponentTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.DistributedMLTComponentTest_7FEE6F4C48AF1F6F-001\init-core-data-001
   [junit4]   2> 1863536 INFO  
(SUITE-DistributedMLTComponentTest-seed#[7FEE6F4C48AF1F6F]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 1863536 INFO  
(SUITE-DistributedMLTComponentTest-seed#[7FEE6F4C48AF1F6F]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /kxb/m
   [junit4]   2> 1864036 INFO  
(TEST-DistributedMLTComponentTest.test-seed#[7FEE6F4C48AF1F6F]) [

[jira] [Updated] (SOLR-9209) DIH JdbcDataSource - improve extensibility part 2

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9209:
---
Attachment: SOLR-9209.patch

adding the test method from SOLR-9256. I'm going to commit it soon.

> DIH JdbcDataSource - improve extensibility part 2
> -
>
> Key: SOLR-9209
> URL: https://issues.apache.org/jira/browse/SOLR-9209
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Attachments: SOLR-9209.patch, SOLR-9209.patch
>
>
> This is a follow up to SOLR-8616. Due to changes in SOLR-8612 it's now no 
> longer possible without additional modifications to use a different 
> {{ResultSetIterator}} class. The attached patch solves this.



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

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

[jira] [Commented] (SOLR-2499) Index-time boosts for multivalue fields are consolidated

[Pat (JIRA)]

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

Pat commented on SOLR-2499:
---

Thank you for your explanations. If I understand it correctly, you would 
suggest to index the values to be boosted with a higher frequency (e.g. index 
the value twice)?

A useful resource to achieve it with payloads: 
https://lucidworks.com/blog/2009/08/05/getting-started-with-payloads/

> Index-time boosts for multivalue fields are consolidated
> 
>
> Key: SOLR-2499
> URL: https://issues.apache.org/jira/browse/SOLR-2499
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 3.1, 3.2, 4.0-ALPHA
>Reporter: Neil Hooey
>  Labels: boost, multivalue, multivalued
>
> Currently, if you boost a value in a multivalue field during index time, the 
> boosts are consolidated for every field, and the individual values are lost.
> So, for example, given a list of photos with a multivalue field "keywords", 
> and a boost for a keyword assigned to a photo corresponds to the number of 
> times that photo was downloaded after searching for that particular keyword, 
> we have documents like this:
> {code}
> photo1: Photo of a cat by itself
> keywords: [ cat:600 feline:100 ]
> => boost total = 700
> photo2: Photo of a cat driving a truck
> keywords: [ cat:100 feline:90 animal:80 truck:1000 ]
> => boost total = 1270
> {code}
> If you search for "cat feline", photo2 will rank higher, since the boost of 
> "cat-like" words was consolidated with the "truck" boost anomaly. Whereas 
> photo1, which has more downloads for "cat" and "feline", ranks lower with a 
> lower consolidated boost, even though the total boost for the relevant 
> keywords is higher than for photo1.
> *Intuitively, the boosts should be separate, so only the boosts for the terms 
> searched will be counted.*
> Given the current behaviour, you are forced to do one of the following:
> 1. Assemble all of the multi-values into a string, and use payloads in place 
> of boosts.
> 2. Use dynamic fields, such as keyword_*, and boost them independently.
> Neither of these solutions are ideal, as using payloads requires writing your 
> own BoostingTermQuery, and defining a new dynamic field per multi-value makes 
> searching more difficult than with multivalue fields.
> There's a blog entry that describes the current behaviour:
> http://blog.kapilchhabra.com/2008/01/solr-index-time-boost-facts-2



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

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

[jira] [Created] (SOLR-9368) FileDictionaryFactory does not treat lines beginning with '#' as comments

[John Iacona (JIRA)]

John Iacona created SOLR-9368:
-

 Summary: FileDictionaryFactory does not treat lines beginning with 
'#' as comments
 Key: SOLR-9368
 URL: https://issues.apache.org/jira/browse/SOLR-9368
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Suggester
Affects Versions: 6.1
Reporter: John Iacona
Priority: Minor


The documentation for FileDictionaryFactory states that "Blank lines and lines 
that start with a '#' are ignored". This is not the case. When loading a 
dictionary file with '#' prefixed lines, they just get interpreted as terms and 
show up in suggestion results. 

This causes additional confusion when trying to use payloads. As stated in 
https://lucene.apache.org/core/6_1_0/suggest/org/apache/lucene/search/suggest/FileDictionary.html:
 "In order to have payload enabled, the first entry has to have a payload". 
However, if you happen to have a "comment" as the first line in a dictionary 
file (that doesn't happen to have two instances of the fieldDelimiter in 
it...), payloads are disabled.



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

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