[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_40-ea-b09) - Build # 4534 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4534/
Java: 32bit/jdk1.8.0_40-ea-b09 -client -XX:+UseConcMarkSweepGC (asserts: true)

1 tests failed.
FAILED:  org.apache.solr.cloud.ReplicationFactorTest.testDistribSearch

Error Message:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: 
http://127.0.0.1:54216/_yb/is/repfacttest_c8n_1x3_shard1_replica1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: 
http://127.0.0.1:54216/_yb/is/repfacttest_c8n_1x3_shard1_replica1
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:581)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:890)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:736)
at 
org.apache.solr.cloud.ReplicationFactorTest.testRf3(ReplicationFactorTest.java:277)
at 
org.apache.solr.cloud.ReplicationFactorTest.doTest(ReplicationFactorTest.java:123)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
at sun.reflect.GeneratedMethodAccessor115.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(T

[jira] [Issue Comment Deleted] (SOLR-6359) Allow customization of the number of records and logs kept by UpdateLog

[Forest Soup (JIRA)]

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

Forest Soup updated SOLR-6359:
--
Comment: was deleted

(was: Thanks. But will there be this case?  
After a snapshot recovery of core A is done, the tlog is still out-of-date 
without any new records from recovery, and it's not cleared. And if the just 
recovered core(core A) taking the leader role, and another core(core C) is 
trying to recover from it. As A's tlog contains the old entries without newest 
ones, will the core C do a peersync only with the old records, but missing the 
newest ones?

And I think the snapshot recovery is because there are too much difference 
between the 2 cores, so the tlog gap are also too much. So the out-of-date tlog 
is no longer needed for peersync.

Our testing shows the snapshot recovery does not clean tlog with below steps:
1, Core A and core B are 2 replicas of a shard.
2, Core A down, and core B took leader role. And it takes some updates and 
record them to its tlog.
3, After A up, it will do recovery from B, and if the difference are too much, 
A will do snapshot pull recovery. And during the snapshot pull recovery, there 
is no other update comes in. After the snapshot pull recovery, the tlog of A is 
not updated, it still does NOT contain any most recent from B. 
* And the tlog are still out-of-date, although the index of A is already 
updated. *
4, Core A down again, and core B still remain the leader role, and it takes 
some other updates and recore them to its tlog.
5, After A up again, it will do recovery from B. But it found its tlog is still 
too old. So it will do a snapshot recovery again, which is not necessary.

Do you agree? Thanks!)

> Allow customization of the number of records and logs kept by UpdateLog
> ---
>
> Key: SOLR-6359
> URL: https://issues.apache.org/jira/browse/SOLR-6359
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ramkumar Aiyengar
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 5.0, Trunk
>
>
> Currently {{UpdateLog}} hardcodes the number of logs and records it keeps, 
> and the hardcoded numbers (100 records, 10 logs) can be quite low (esp. the 
> records) in an heavily indexing setup, leading to full recovery even if Solr 
> was just stopped and restarted.
> These values should be customizable (even if only present as expert options).



--
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-6359) Allow customization of the number of records and logs kept by UpdateLog

[Forest Soup (JIRA)]

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

Forest Soup edited comment on SOLR-6359 at 1/5/15 7:27 AM:
---

Thanks. But will there be this case?  
After a snapshot recovery of core A is done, the tlog is still out-of-date 
without any new records from recovery, and it's not cleared. And if the just 
recovered core(core A) taking the leader role, and another core(core C) is 
trying to recover from it. As A's tlog contains the old entries without newest 
ones, will the core C do a peersync only with the old records, but missing the 
newest ones?

And I think the snapshot recovery is because there are too much difference 
between the 2 cores, so the tlog gap are also too much. So the out-of-date tlog 
is no longer needed for peersync.

Our testing shows the snapshot recovery does not clean tlog with below steps:
1, Core A and core B are 2 replicas of a shard.
2, Core A down, and core B took leader role. And it takes some updates and 
record them to its tlog.
3, After A up, it will do recovery from B, and if the difference are too much, 
A will do snapshot pull recovery. And during the snapshot pull recovery, there 
is no other update comes in. After the snapshot pull recovery, the tlog of A is 
not updated, it still does NOT contain any most recent from B. 
And the tlog are still out-of-date, although the index of A is already updated.
4, Core A down again, and core B still remain the leader role, and it takes 
some other updates and recore them to its tlog.
5, After A up again, it will do recovery from B. But it found its tlog is still 
too old. So it will do a snapshot recovery again, which is not necessary.

Do you agree? Thanks!


was (Author: forest_soup):
Thanks. But will there be this case?  
After a snapshot recovery of core A is done, the tlog is still out-of-date 
without any new records from recovery, and it's not cleared. And if the just 
recovered core(core A) taking the leader role, and another core(core C) is 
trying to recover from it. As A's tlog contains the old entries without newest 
ones, will the core C do a peersync only with the old records, but missing the 
newest ones?

And I think the snapshot recovery is because there are too much difference 
between the 2 cores, so the tlog gap are also too much. So the out-of-date tlog 
is no longer needed for peersync.

Our testing shows the snapshot recovery does not clean tlog with below steps:
1, Core A and core B are 2 replicas of a shard.
2, Core A down, and core B took leader role. And it takes some updates and 
record them to its tlog.
3, After A up, it will do recovery from B, and if the difference are too much, 
A will do snapshot pull recovery. And during the snapshot pull recovery, there 
is no other update comes in. After the snapshot pull recovery, the tlog of A is 
not updated, it still does NOT contain any most recent from B. 
* And the tlog are still out-of-date, although the index of A is already 
updated. *
4, Core A down again, and core B still remain the leader role, and it takes 
some other updates and recore them to its tlog.
5, After A up again, it will do recovery from B. But it found its tlog is still 
too old. So it will do a snapshot recovery again, which is not necessary.

Do you agree? Thanks!

> Allow customization of the number of records and logs kept by UpdateLog
> ---
>
> Key: SOLR-6359
> URL: https://issues.apache.org/jira/browse/SOLR-6359
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ramkumar Aiyengar
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 5.0, Trunk
>
>
> Currently {{UpdateLog}} hardcodes the number of logs and records it keeps, 
> and the hardcoded numbers (100 records, 10 logs) can be quite low (esp. the 
> records) in an heavily indexing setup, leading to full recovery even if Solr 
> was just stopped and restarted.
> These values should be customizable (even if only present as expert options).



--
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-6359) Allow customization of the number of records and logs kept by UpdateLog

[Forest Soup (JIRA)]

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

Forest Soup commented on SOLR-6359:
---

Thanks. But will there be this case?  
After a snapshot recovery of core A is done, the tlog is still out-of-date 
without any new records from recovery, and it's not cleared. And if the just 
recovered core(core A) taking the leader role, and another core(core C) is 
trying to recover from it. As A's tlog contains the old entries without newest 
ones, will the core C do a peersync only with the old records, but missing the 
newest ones?

And I think the snapshot recovery is because there are too much difference 
between the 2 cores, so the tlog gap are also too much. So the out-of-date tlog 
is no longer needed for peersync.

Our testing shows the snapshot recovery does not clean tlog with below steps:
1, Core A and core B are 2 replicas of a shard.
2, Core A down, and core B took leader role. And it takes some updates and 
record them to its tlog.
3, After A up, it will do recovery from B, and if the difference are too much, 
A will do snapshot pull recovery. And during the snapshot pull recovery, there 
is no other update comes in. After the snapshot pull recovery, the tlog of A is 
not updated, it still does NOT contain any most recent from B. 
* And the tlog are still out-of-date, although the index of A is already 
updated. *
4, Core A down again, and core B still remain the leader role, and it takes 
some other updates and recore them to its tlog.
5, After A up again, it will do recovery from B. But it found its tlog is still 
too old. So it will do a snapshot recovery again, which is not necessary.

Do you agree? Thanks!

> Allow customization of the number of records and logs kept by UpdateLog
> ---
>
> Key: SOLR-6359
> URL: https://issues.apache.org/jira/browse/SOLR-6359
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ramkumar Aiyengar
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 5.0, Trunk
>
>
> Currently {{UpdateLog}} hardcodes the number of logs and records it keeps, 
> and the hardcoded numbers (100 records, 10 logs) can be quite low (esp. the 
> records) in an heavily indexing setup, leading to full recovery even if Solr 
> was just stopped and restarted.
> These values should be customizable (even if only present as expert options).



--
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-6359) Allow customization of the number of records and logs kept by UpdateLog

[Forest Soup (JIRA)]

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

Forest Soup commented on SOLR-6359:
---

Thanks. But will there be this case?  
After a snapshot recovery of core A is done, the tlog is still out-of-date 
without any new records from recovery, and it's not cleared. And if the just 
recovered core(core A) taking the leader role, and another core(core C) is 
trying to recover from it. As A's tlog contains the old entries without newest 
ones, will the core C do a peersync only with the old records, but missing the 
newest ones?

And I think the snapshot recovery is because there are too much difference 
between the 2 cores, so the tlog gap are also too much. So the out-of-date tlog 
is no longer needed for peersync.

Our testing shows the snapshot recovery does not clean tlog with below steps:
1, Core A and core B are 2 replicas of a shard.
2, Core A down, and core B took leader role. And it takes some updates and 
record them to its tlog.
3, After A up, it will do recovery from B, and if the difference are too much, 
A will do snapshot pull recovery. And during the snapshot pull recovery, there 
is no other update comes in. After the snapshot pull recovery, the tlog of A is 
not updated, it still does NOT contain any most recent from B. 
* And the tlog are still out-of-date, although the index of A is already 
updated. *
4, Core A down again, and core B still remain the leader role, and it takes 
some other updates and recore them to its tlog.
5, After A up again, it will do recovery from B. But it found its tlog is still 
too old. So it will do a snapshot recovery again, which is not necessary.

Do you agree? Thanks!

> Allow customization of the number of records and logs kept by UpdateLog
> ---
>
> Key: SOLR-6359
> URL: https://issues.apache.org/jira/browse/SOLR-6359
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ramkumar Aiyengar
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 5.0, Trunk
>
>
> Currently {{UpdateLog}} hardcodes the number of logs and records it keeps, 
> and the hardcoded numbers (100 records, 10 logs) can be quite low (esp. the 
> records) in an heavily indexing setup, leading to full recovery even if Solr 
> was just stopped and restarted.
> These values should be customizable (even if only present as expert options).



--
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-4.10-Linux (32bit/jdk1.8.0_20) - Build # 210 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.10-Linux/210/
Java: 32bit/jdk1.8.0_20 -client -XX:+UseConcMarkSweepGC (asserts: true)

1 tests failed.
FAILED:  org.apache.solr.cloud.OverseerTest.testOverseerFailure

Error Message:
KeeperErrorCode = NoNode for 
/collections/collection1/leader_elect/shard1/election

Stack Trace:
org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode 
for /collections/collection1/leader_elect/shard1/election
at 
__randomizedtesting.SeedInfo.seed([482CB93BE9A281DA:4C2436C8FB076EFB]:0)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783)
at 
org.apache.solr.common.cloud.SolrZkClient$11.execute(SolrZkClient.java:462)
at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:74)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:459)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:416)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:403)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:359)
at 
org.apache.solr.cloud.OverseerTest$MockZKController.publishState(OverseerTest.java:144)
at 
org.apache.solr.cloud.OverseerTest.testOverseerFailure(OverseerTest.java:662)
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:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.Statemen

[jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests

[Kapil Malik (JIRA)]

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

Kapil Malik commented on SOLR-4470:
---

Hi,
I've a solr cloud installation (Solr 4.10.2) and I want to authenticate 
requests made via SolrJ client using SolrCloudServer   
(Refer : http://wiki.apache.org/solr/Solrj#Using_with_SolrCloud )

I followed https://wiki.apache.org/solr/SolrSecurity to add basic 
authentication by editing webdefault.xml, jetty.xml etc. and when I start the 
first node, I am able to see the auth prompt on accessing it via web-browser, 
and login successfully. I am also able to access it via SolrJ client using 
SolrCloudServer and HttpClientUtil.setBasicAuth((DefaultHttpClient) 
cloudServer.getLbServer().getHttpClient(), username, password);
 But the 2nd node does not start properly and it gives 401 error
ERROR org.apache.solr.cloud.RecoveryStrategy  – Error while trying to recover. 
core=mycollection_shard1_replica1:java.util.concurrent.ExecutionException: 
org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Expected 
mime type application/octet-stream but got text/html
<401 error message html>
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:188)
at 
org.apache.solr.cloud.RecoveryStrategy.sendPrepRecoveryCmd(RecoveryStrategy.java:615)
at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:371)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:235)

The Solr security wiki relies on SOLR-4470 for inter-solr-node requests 
(org.apache.solr.security.InterSolrNodeAuthCredentialsFactory.SubRequestFactory 
etc.) 

Since SOLR-4470 is not implemented yet, is there any way I can secure the calls 
made to my solr cloud ? 
Or is it impossible to add basic authentication to requests to SolrCloud made 
via SolrJ client using SolrCloudServer today?

> Support for basic http auth in internal solr requests
> -
>
> Key: SOLR-4470
> URL: https://issues.apache.org/jira/browse/SOLR-4470
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java, multicore, replication (java), SolrCloud
>Affects Versions: 4.0
>Reporter: Per Steffensen
>Assignee: Jan Høydahl
>  Labels: authentication, https, solrclient, solrcloud, ssl
> Fix For: Trunk
>
> Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, 
> SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, 
> SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, 
> SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, 
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, 
> SOLR-4470_trunk_r1568857.patch
>
>
> We want to protect any HTTP-resource (url). We want to require credentials no 
> matter what kind of HTTP-request you make to a Solr-node.
> It can faily easy be acheived as described on 
> http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes 
> also make "internal" request to other Solr-nodes, and for it to work 
> credentials need to be provided here also.
> Ideally we would like to "forward" credentials from a particular request to 
> all the "internal" sub-requests it triggers. E.g. for search and update 
> request.
> But there are also "internal" requests
> * that only indirectly/asynchronously triggered from "outside" requests (e.g. 
> shard creation/deletion/etc based on calls to the "Collection API")
> * that do not in any way have relation to an "outside" "super"-request (e.g. 
> replica synching stuff)
> We would like to aim at a solution where "original" credentials are 
> "forwarded" when a request directly/synchronously trigger a subrequest, and 
> fallback to a configured "internal credentials" for the 
> asynchronous/non-rooted requests.
> In our solution we would aim at only supporting basic http auth, but we would 
> like to make a "framework" around it, so that not to much refactoring is 
> needed if you later want to make support for other kinds of auth (e.g. digest)
> We will work at a solution but create this JIRA issue early in order to get 
> input/comments from the community as early as possible.



--
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-4509) Disable HttpClient stale check for performance and fewer spurious connection errors.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-4509:
--
Attachment: SOLR-4509.patch

I brought this up to date with trunk and spent some more time hardening and 
investigating test issues. Getting close to a resolution.

> Disable HttpClient stale check for performance and fewer spurious connection 
> errors.
> 
>
> Key: SOLR-4509
> URL: https://issues.apache.org/jira/browse/SOLR-4509
> Project: Solr
>  Issue Type: Improvement
>  Components: search
> Environment: 5 node SmartOS cluster (all nodes living in same global 
> zone - i.e. same physical machine)
>Reporter: Ryan Zezeski
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 5.0, Trunk
>
> Attachments: IsStaleTime.java, SOLR-4509-4_4_0.patch, 
> SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, 
> SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, 
> baremetal-stale-nostale-med-latency.dat, 
> baremetal-stale-nostale-med-latency.svg, 
> baremetal-stale-nostale-throughput.dat, baremetal-stale-nostale-throughput.svg
>
>
> By disabling the Apache HTTP Client stale check I've witnessed a 2-4x 
> increase in throughput and reduction of over 100ms.  This patch was made in 
> the context of a project I'm leading, called Yokozuna, which relies on 
> distributed search.
> Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26
> Here's a write-up I did on my findings: 
> http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html
> I'm happy to answer any questions or make changes to the patch to make it 
> acceptable.
> ReviewBoard: https://reviews.apache.org/r/28393/



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

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

[JENKINS-MAVEN] Lucene-Solr-Maven-5.x #809: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/809/

No tests ran.

Build Log:
[...truncated 40077 lines...]


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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2036/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC (asserts: false)

1 tests failed.
FAILED:  
org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.testDistribSearch

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 30 
seconds
at 
__randomizedtesting.SeedInfo.seed([EF690A6D356B51AB:6E8F847542343197]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:178)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:835)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1454)
at 
org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.doTest(DistribDocExpirationUpdateProcessorTest.java:69)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
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:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.e

[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 724 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/724/

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

Error Message:
Error from server at http://127.0.0.1:51063/_uu/uj: Error CREATEing SolrCore 
'halfcollection_shard1_replica1': Unable to create core 
[halfcollection_shard1_replica1] Caused by: Could not get shard id for core: 
halfcollection_shard1_replica1

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:51063/_uu/uj: Error CREATEing SolrCore 
'halfcollection_shard1_replica1': Unable to create core 
[halfcollection_shard1_replica1] Caused by: Could not get shard id for core: 
halfcollection_shard1_replica1
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:558)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:214)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:210)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:449)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:201)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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.TestRuleAssertionsR

[jira] [Commented] (SOLR-6907) URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in file name

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-6907:
--

Done, thanks!

> URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in 
> file name
> ---
>
> Key: SOLR-6907
> URL: https://issues.apache.org/jira/browse/SOLR-6907
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce, Tests
>Reporter: Ramkumar Aiyengar
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6907-2.patch, SOLR-6907.patch
>
>
> Currently the test fails if the source is checked out on a directory whose 
> path contains, say spaces..



--
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-6907) URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in file name

[ASF subversion and git services (JIRA)]

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

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

Commit 1649457 from [~erickoerickson] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1649457 ]

SOLR-6907, corrected patch, URLEncode documents directory in 
MorphlineMapperTest to handle spaces etc in file name

> URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in 
> file name
> ---
>
> Key: SOLR-6907
> URL: https://issues.apache.org/jira/browse/SOLR-6907
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce, Tests
>Reporter: Ramkumar Aiyengar
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6907-2.patch, SOLR-6907.patch
>
>
> Currently the test fails if the source is checked out on a directory whose 
> path contains, say spaces..



--
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-6909) Allow pluggable atomic update merging logic

[Steve Davids (JIRA)]

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

Steve Davids updated SOLR-6909:
---
Attachment: SOLR-6909.patch

Attached a patch which pulls the current merging implementation out from the 
DistributedUpdateProcessor into a new AtomicUpdateDocumentMerger class. This 
DistributedUpdateProcessorFactory instantiates a new AtomicUpdateDocumentMerger 
and passes it to the DistributedUpdateProcessor. This approach allows clients 
to extend the DistributedUpdateProcessorFactory and instantiate their own 
custom AtomicUpdateDocumentMerger which is then passed along to the 
DistributedUpdateProcessor. One thing that I'm not thrilled about is having a 
static 'isAtomicUpdate' method (currently in the code), I tried to remove the 
static but a couple other classes require that static method to be there and 
having a merger member variable didn't quite make sense in those cases so I 
left it a static.

> Allow pluggable atomic update merging logic
> ---
>
> Key: SOLR-6909
> URL: https://issues.apache.org/jira/browse/SOLR-6909
> Project: Solr
>  Issue Type: Improvement
>Reporter: Steve Davids
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6909.patch
>
>
> Clients should be able to introduce their own specific merging logic by 
> implementing a new class that will be used by the DistributedUpdateProcessor. 
> This is particularly useful if you require a custom hook to interrogate the 
> incoming document with the document that is already resident in the index as 
> there isn't the ability to perform that operation nor can you currently 
> extend the DistributedUpdateProcessor to provide the modifications.



--
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-6907) URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in file name

[ASF subversion and git services (JIRA)]

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

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

Commit 1649455 from [~erickoerickson] in branch 'dev/trunk'
[ https://svn.apache.org/r1649455 ]

SOLR-6907, corrected patch, URLEncode documents directory in 
MorphlineMapperTest to handle spaces etc in file name

> URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in 
> file name
> ---
>
> Key: SOLR-6907
> URL: https://issues.apache.org/jira/browse/SOLR-6907
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce, Tests
>Reporter: Ramkumar Aiyengar
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6907-2.patch, SOLR-6907.patch
>
>
> Currently the test fails if the source is checked out on a directory whose 
> path contains, say spaces..



--
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] (LUCENE-6162) type="java.io.FileNotFoundException">java.io.FileNotFoundException: \data\thunderbirdDicts\addon-0.4.5-an+fx+tb+fn+sm.xpi

[Martin Gainty (JIRA)]

Martin Gainty created LUCENE-6162:
-

 Summary: 
type="java.io.FileNotFoundException">java.io.FileNotFoundException: 
\data\thunderbirdDicts\addon-0.4.5-an+fx+tb+fn+sm.xpi
 Key: LUCENE-6162
 URL: https://issues.apache.org/jira/browse/LUCENE-6162
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 4.10.3
 Environment: JDK 1.7.0_45
ANT 1.8.2
Reporter: Martin Gainty


type="java.io.FileNotFoundException">java.io.FileNotFoundException: 
\data\thunderbirdDicts\addon-0.4.5-an+fx+tb+fn+sm.xpi

I think common-build.xml needs serious trimming.. I keep getting OutOfMemory 
even with 8GB RAM...I refactored common-build.xml to rid of serious baggage and 
now javac on src/java and src/test and junit seem to work flawlessly now
IVY calling a macro calling the actual taskdef with everything parameritised 
probably is the culprit..By replacing IVY macros with plain taskdefs I was able 
to run all 537 testcases with 4GB RAM

MG
04-Jan-2015



--
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-6909) Allow pluggable atomic update merging logic

[Steve Davids (JIRA)]

Steve Davids created SOLR-6909:
--

 Summary: Allow pluggable atomic update merging logic
 Key: SOLR-6909
 URL: https://issues.apache.org/jira/browse/SOLR-6909
 Project: Solr
  Issue Type: Improvement
Reporter: Steve Davids
 Fix For: 5.0, Trunk


Clients should be able to introduce their own specific merging logic by 
implementing a new class that will be used by the DistributedUpdateProcessor. 
This is particularly useful if you require a custom hook to interrogate the 
incoming document with the document that is already resident in the index as 
there isn't the ability to perform that operation nor can you currently extend 
the DistributedUpdateProcessor to provide the modifications.



--
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-6119) Add auto-io-throttle to ConcurrentMergeScheduler

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-6119:
---
Attachment: LUCENE-6119.patch

New patch, fixing one nocommit, adding some more infoStream logging
around applying deletes, fixing "ant precommit".  I also fixed CFS
building to also throttle.

I tested on spinning disks ... it seems to behave well: under intense
indexing, the throttle moves to unlimited since the spinning disk
can't keep up.  Under light indexing, it stays low.

I upped the starting rate to 20 MB/sec (from 5 before): this helps it
move to less throttling more quickly before merges fall behind in the
beginning during heavy indexing.

Tests pass ... I think it's ready.

> Add auto-io-throttle to ConcurrentMergeScheduler
> 
>
> Key: LUCENE-6119
> URL: https://issues.apache.org/jira/browse/LUCENE-6119
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6119.patch, LUCENE-6119.patch, LUCENE-6119.patch, 
> LUCENE-6119.patch, LUCENE-6119.patch
>
>
> This method returns number of "incoming" bytes IW has written since it
> was opened, excluding merging.
> It tracks flushed segments, new commits (segments_N), incoming
> files/segments by addIndexes, newly written live docs / doc values
> updates files.
> It's an easy statistic for IW to track and should be useful to help
> applications more intelligently set defaults for IO throttling
> (RateLimiter).
> For example, an application that does hardly any indexing but finally
> triggered a large merge can afford to heavily throttle that large
> merge so it won't interfere with ongoing searches.
> But an application that's causing IW to write new bytes at 50 MB/sec
> must set a correspondingly higher IO throttling otherwise merges will
> clearly fall behind.



--
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-5.x-Windows (64bit/jdk1.7.0_67) - Build # 4429 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4429/
Java: 64bit/jdk1.7.0_67 -XX:-UseCompressedOops -XX:+UseSerialGC (asserts: true)

2 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([44A06159A3FE76FD]:0)


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

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([44A06159A3FE76FD]:0)




Build Log:
[...truncated 9047 lines...]
   [junit4] Suite: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest
   [junit4]   2> Creating dataDir: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.ChaosMonkeySafeLeaderTest-44A06159A3FE76FD-001\init-core-data-001
   [junit4]   2> 206860 T488 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl 
(false) and clientAuth (false)
   [junit4]   2> 206860 T488 oas.BaseDistributedSearchTestCase.initHostContext 
Setting hostContext system property: /_bwd/e
   [junit4]   2> 206880 T488 oas.SolrTestCaseJ4.setUp ###Starting 
testDistribSearch
   [junit4]   2> 206881 T488 oasc.ZkTestServer.run STARTING ZK TEST SERVER
   [junit4]   1> client port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 206882 T489 oasc.ZkTestServer$ZKServerMain.runFromConfig 
Starting server
   [junit4]   2> 206982 T488 oasc.ZkTestServer.run start zk server on port:63065
   [junit4]   2> 206982 T488 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2> 206986 T488 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2> 206992 T496 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@57c24d02 
name:ZooKeeperConnection Watcher:127.0.0.1:63065 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 206993 T488 oascc.ConnectionManager.waitForConnected Client is 
connected to ZooKeeper
   [junit4]   2> 206993 T488 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2> 206993 T488 oascc.SolrZkClient.makePath makePath: /solr
   [junit4]   2> 207002 T488 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2> 207004 T488 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2> 207008 T499 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@748530f2 
name:ZooKeeperConnection Watcher:127.0.0.1:63065/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 207008 T488 oascc.ConnectionManager.waitForConnected Client is 
connected to ZooKeeper
   [junit4]   2> 207008 T488 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2> 207008 T488 oascc.SolrZkClient.makePath makePath: 
/collections/collection1
   [junit4]   2> 207016 T488 oascc.SolrZkClient.makePath makePath: 
/collections/collection1/shards
   [junit4]   2> 207022 T488 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection
   [junit4]   2> 207026 T488 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection/shards
   [junit4]   2> 207033 T488 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 207033 T488 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.xml
   [junit4]   2> 207044 T488 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\test-files\solr\collection1\conf\schema15.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 207044 T488 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/schema.xml
   [junit4]   2> 207052 T488 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 207052 T488 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 207062 T488 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\test-files\solr\collection1\conf\stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 207063 T488 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/stopwords.txt
   [junit4]   2> 207070 T488 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-

[JENKINS-MAVEN] Lucene-Solr-Maven-5.x #808: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/808/

2 tests failed.
FAILED:  org.apache.solr.hadoop.MorphlineBasicMiniMRTest.testPathParts

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([81D0353C77DE4FE3]:0)


FAILED:  
org.apache.solr.hadoop.MorphlineBasicMiniMRTest.org.apache.solr.hadoop.MorphlineBasicMiniMRTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([81D0353C77DE4FE3]:0)




Build Log:
[...truncated 54077 lines...]
BUILD FAILED
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:552: 
The following error occurred while executing this line:
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:204: 
The following error occurred while executing this line:
: Java returned: 1

Total time: 357 minutes 51 seconds
Build step 'Invoke Ant' marked build as failure
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Comment Edited] (SOLR-6908) SimplePostTool's help message is incorrect -Durl parameter

[Erik Hatcher (JIRA)]

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

Erik Hatcher edited comment on SOLR-6908 at 1/4/15 11:03 PM:
-

-Dtype isn't needed when going to /update/extract, as it detects the type 
automatically there and I figured it'd be good to shorten up the example line.  
Ah, pdf1, sorry I missed that - I'll adjust.


was (Author: ehatcher):
-Dtype isn't needed when going to /update/extract, as that it detects the type 
automatically there and I figured it'd be good to shorten up the example line.  
Ah, pdf1, sorry I missed that - I'll adjust.

> SimplePostTool's help message is incorrect -Durl parameter
> --
>
> Key: SOLR-6908
> URL: https://issues.apache.org/jira/browse/SOLR-6908
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 5.0
>Reporter: Alexandre Rafalovitch
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.0, Trunk
>
>
> {quote}
> java -jar post.jar -h
> ...
> java -Durl=http://localhost:8983/solr/update/extract -Dparams=literal.id=a 
> -Dtype=application/pdf -jar post.jar a.pdf
> ...
> {quote}
> The example is the only one for -Durl and is not correct as it is missing the 
> collection name. Also, even though this is an example, *a.pdf* does not 
> exist, but we do have *solr-word.pdf* now.
> So, this should probably say:
> {quote}
> java -Durl=http://localhost:8983/solr/techproducts/update/extract 
> -Dparams=literal.id=pdf1 -Dtype=application/pdf -jar post.jar solr-word.pdf
> {quote}
> Also, it is worth mentioning (if true) that specifying *-Durl* overrides 
> *-Dc*.



--
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-6908) SimplePostTool's help message is incorrect -Durl parameter

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-6908:
-

Thank you. Shorter line looks great.

> SimplePostTool's help message is incorrect -Durl parameter
> --
>
> Key: SOLR-6908
> URL: https://issues.apache.org/jira/browse/SOLR-6908
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 5.0
>Reporter: Alexandre Rafalovitch
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.0, Trunk
>
>
> {quote}
> java -jar post.jar -h
> ...
> java -Durl=http://localhost:8983/solr/update/extract -Dparams=literal.id=a 
> -Dtype=application/pdf -jar post.jar a.pdf
> ...
> {quote}
> The example is the only one for -Durl and is not correct as it is missing the 
> collection name. Also, even though this is an example, *a.pdf* does not 
> exist, but we do have *solr-word.pdf* now.
> So, this should probably say:
> {quote}
> java -Durl=http://localhost:8983/solr/techproducts/update/extract 
> -Dparams=literal.id=pdf1 -Dtype=application/pdf -jar post.jar solr-word.pdf
> {quote}
> Also, it is worth mentioning (if true) that specifying *-Durl* overrides 
> *-Dc*.



--
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-6908) SimplePostTool's help message is incorrect -Durl parameter

[Erik Hatcher (JIRA)]

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

Erik Hatcher edited comment on SOLR-6908 at 1/4/15 10:32 PM:
-

-Dtype isn't needed when going to /update/extract, as that it detects the type 
automatically there and I figured it'd be good to shorten up the example line.  
Ah, pdf1, sorry I missed that - I'll adjust.


was (Author: ehatcher):
-Dtype isn't needed with going to /update/extract, as that it detects the type 
automatically there and I figured it'd be good to shorten up the example line.  
Ah, pdf1, sorry I missed that - I'll adjust.

> SimplePostTool's help message is incorrect -Durl parameter
> --
>
> Key: SOLR-6908
> URL: https://issues.apache.org/jira/browse/SOLR-6908
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 5.0
>Reporter: Alexandre Rafalovitch
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.0, Trunk
>
>
> {quote}
> java -jar post.jar -h
> ...
> java -Durl=http://localhost:8983/solr/update/extract -Dparams=literal.id=a 
> -Dtype=application/pdf -jar post.jar a.pdf
> ...
> {quote}
> The example is the only one for -Durl and is not correct as it is missing the 
> collection name. Also, even though this is an example, *a.pdf* does not 
> exist, but we do have *solr-word.pdf* now.
> So, this should probably say:
> {quote}
> java -Durl=http://localhost:8983/solr/techproducts/update/extract 
> -Dparams=literal.id=pdf1 -Dtype=application/pdf -jar post.jar solr-word.pdf
> {quote}
> Also, it is worth mentioning (if true) that specifying *-Durl* overrides 
> *-Dc*.



--
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-6908) SimplePostTool's help message is incorrect -Durl parameter

[ASF subversion and git services (JIRA)]

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

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

Commit 1649443 from [~ehatcher] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1649443 ]

SOLR-6908: Minor corrections to SimplePostTool -help (merged from trunk 
r1649442)

> SimplePostTool's help message is incorrect -Durl parameter
> --
>
> Key: SOLR-6908
> URL: https://issues.apache.org/jira/browse/SOLR-6908
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 5.0
>Reporter: Alexandre Rafalovitch
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.0, Trunk
>
>
> {quote}
> java -jar post.jar -h
> ...
> java -Durl=http://localhost:8983/solr/update/extract -Dparams=literal.id=a 
> -Dtype=application/pdf -jar post.jar a.pdf
> ...
> {quote}
> The example is the only one for -Durl and is not correct as it is missing the 
> collection name. Also, even though this is an example, *a.pdf* does not 
> exist, but we do have *solr-word.pdf* now.
> So, this should probably say:
> {quote}
> java -Durl=http://localhost:8983/solr/techproducts/update/extract 
> -Dparams=literal.id=pdf1 -Dtype=application/pdf -jar post.jar solr-word.pdf
> {quote}
> Also, it is worth mentioning (if true) that specifying *-Durl* overrides 
> *-Dc*.



--
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-6908) SimplePostTool's help message is incorrect -Durl parameter

[ASF subversion and git services (JIRA)]

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

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

Commit 1649442 from [~ehatcher] in branch 'dev/trunk'
[ https://svn.apache.org/r1649442 ]

SOLR-6908: Minor corrections to SimplePostTool -help

> SimplePostTool's help message is incorrect -Durl parameter
> --
>
> Key: SOLR-6908
> URL: https://issues.apache.org/jira/browse/SOLR-6908
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 5.0
>Reporter: Alexandre Rafalovitch
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.0, Trunk
>
>
> {quote}
> java -jar post.jar -h
> ...
> java -Durl=http://localhost:8983/solr/update/extract -Dparams=literal.id=a 
> -Dtype=application/pdf -jar post.jar a.pdf
> ...
> {quote}
> The example is the only one for -Durl and is not correct as it is missing the 
> collection name. Also, even though this is an example, *a.pdf* does not 
> exist, but we do have *solr-word.pdf* now.
> So, this should probably say:
> {quote}
> java -Durl=http://localhost:8983/solr/techproducts/update/extract 
> -Dparams=literal.id=pdf1 -Dtype=application/pdf -jar post.jar solr-word.pdf
> {quote}
> Also, it is worth mentioning (if true) that specifying *-Durl* overrides 
> *-Dc*.



--
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-6908) SimplePostTool's help message is incorrect -Durl parameter

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-6908:


-Dtype isn't needed with going to /update/extract, as that it detects the type 
automatically there and I figured it'd be good to shorten up the example line.  
Ah, pdf1, sorry I missed that - I'll adjust.

> SimplePostTool's help message is incorrect -Durl parameter
> --
>
> Key: SOLR-6908
> URL: https://issues.apache.org/jira/browse/SOLR-6908
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 5.0
>Reporter: Alexandre Rafalovitch
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.0, Trunk
>
>
> {quote}
> java -jar post.jar -h
> ...
> java -Durl=http://localhost:8983/solr/update/extract -Dparams=literal.id=a 
> -Dtype=application/pdf -jar post.jar a.pdf
> ...
> {quote}
> The example is the only one for -Durl and is not correct as it is missing the 
> collection name. Also, even though this is an example, *a.pdf* does not 
> exist, but we do have *solr-word.pdf* now.
> So, this should probably say:
> {quote}
> java -Durl=http://localhost:8983/solr/techproducts/update/extract 
> -Dparams=literal.id=pdf1 -Dtype=application/pdf -jar post.jar solr-word.pdf
> {quote}
> Also, it is worth mentioning (if true) that specifying *-Durl* overrides 
> *-Dc*.



--
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-6908) SimplePostTool's help message is incorrect -Durl parameter

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-6908:
-

Just to double-check. The updated version seem to skip -Dtype that was there in 
the original. Is that now auto-detected somehow?

Also, the literal.id was 'a' which made sense with 'a.pdf'. I suggested 'pdf1', 
though this is not as big a deal.

> SimplePostTool's help message is incorrect -Durl parameter
> --
>
> Key: SOLR-6908
> URL: https://issues.apache.org/jira/browse/SOLR-6908
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 5.0
>Reporter: Alexandre Rafalovitch
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.0, Trunk
>
>
> {quote}
> java -jar post.jar -h
> ...
> java -Durl=http://localhost:8983/solr/update/extract -Dparams=literal.id=a 
> -Dtype=application/pdf -jar post.jar a.pdf
> ...
> {quote}
> The example is the only one for -Durl and is not correct as it is missing the 
> collection name. Also, even though this is an example, *a.pdf* does not 
> exist, but we do have *solr-word.pdf* now.
> So, this should probably say:
> {quote}
> java -Durl=http://localhost:8983/solr/techproducts/update/extract 
> -Dparams=literal.id=pdf1 -Dtype=application/pdf -jar post.jar solr-word.pdf
> {quote}
> Also, it is worth mentioning (if true) that specifying *-Durl* overrides 
> *-Dc*.



--
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-6908) SimplePostTool's help message is incorrect -Durl parameter

[Erik Hatcher (JIRA)]

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

Erik Hatcher resolved SOLR-6908.

   Resolution: Fixed
Fix Version/s: Trunk
 Assignee: Erik Hatcher

Fixed.  Thanks Alex!

> SimplePostTool's help message is incorrect -Durl parameter
> --
>
> Key: SOLR-6908
> URL: https://issues.apache.org/jira/browse/SOLR-6908
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 5.0
>Reporter: Alexandre Rafalovitch
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.0, Trunk
>
>
> {quote}
> java -jar post.jar -h
> ...
> java -Durl=http://localhost:8983/solr/update/extract -Dparams=literal.id=a 
> -Dtype=application/pdf -jar post.jar a.pdf
> ...
> {quote}
> The example is the only one for -Durl and is not correct as it is missing the 
> collection name. Also, even though this is an example, *a.pdf* does not 
> exist, but we do have *solr-word.pdf* now.
> So, this should probably say:
> {quote}
> java -Durl=http://localhost:8983/solr/techproducts/update/extract 
> -Dparams=literal.id=pdf1 -Dtype=application/pdf -jar post.jar solr-word.pdf
> {quote}
> Also, it is worth mentioning (if true) that specifying *-Durl* overrides 
> *-Dc*.



--
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-6908) SimplePostTool's help message is incorrect -Durl parameter

[ASF subversion and git services (JIRA)]

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

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

Commit 1649439 from [~ehatcher] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1649439 ]

SOLR-6908: Minor corrections to SimplePostTool -help (merged from trunk 
r1649438)

> SimplePostTool's help message is incorrect -Durl parameter
> --
>
> Key: SOLR-6908
> URL: https://issues.apache.org/jira/browse/SOLR-6908
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 5.0
>Reporter: Alexandre Rafalovitch
>Priority: Minor
> Fix For: 5.0
>
>
> {quote}
> java -jar post.jar -h
> ...
> java -Durl=http://localhost:8983/solr/update/extract -Dparams=literal.id=a 
> -Dtype=application/pdf -jar post.jar a.pdf
> ...
> {quote}
> The example is the only one for -Durl and is not correct as it is missing the 
> collection name. Also, even though this is an example, *a.pdf* does not 
> exist, but we do have *solr-word.pdf* now.
> So, this should probably say:
> {quote}
> java -Durl=http://localhost:8983/solr/techproducts/update/extract 
> -Dparams=literal.id=pdf1 -Dtype=application/pdf -jar post.jar solr-word.pdf
> {quote}
> Also, it is worth mentioning (if true) that specifying *-Durl* overrides 
> *-Dc*.



--
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-6908) SimplePostTool's help message is incorrect -Durl parameter

[ASF subversion and git services (JIRA)]

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

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

Commit 1649438 from [~ehatcher] in branch 'dev/trunk'
[ https://svn.apache.org/r1649438 ]

SOLR-6908: Minor corrections to SimplePostTool -help

> SimplePostTool's help message is incorrect -Durl parameter
> --
>
> Key: SOLR-6908
> URL: https://issues.apache.org/jira/browse/SOLR-6908
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 5.0
>Reporter: Alexandre Rafalovitch
>Priority: Minor
> Fix For: 5.0
>
>
> {quote}
> java -jar post.jar -h
> ...
> java -Durl=http://localhost:8983/solr/update/extract -Dparams=literal.id=a 
> -Dtype=application/pdf -jar post.jar a.pdf
> ...
> {quote}
> The example is the only one for -Durl and is not correct as it is missing the 
> collection name. Also, even though this is an example, *a.pdf* does not 
> exist, but we do have *solr-word.pdf* now.
> So, this should probably say:
> {quote}
> java -Durl=http://localhost:8983/solr/techproducts/update/extract 
> -Dparams=literal.id=pdf1 -Dtype=application/pdf -jar post.jar solr-word.pdf
> {quote}
> Also, it is worth mentioning (if true) that specifying *-Durl* overrides 
> *-Dc*.



--
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-6907) URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in file name

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar updated SOLR-6907:

Attachment: SOLR-6907-2.patch

Here you go..

> URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in 
> file name
> ---
>
> Key: SOLR-6907
> URL: https://issues.apache.org/jira/browse/SOLR-6907
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce, Tests
>Reporter: Ramkumar Aiyengar
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6907-2.patch, SOLR-6907.patch
>
>
> Currently the test fails if the source is checked out on a directory whose 
> path contains, say spaces..



--
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-5.x-Linux (64bit/jdk1.8.0_20) - Build # 11678 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11678/
Java: 64bit/jdk1.8.0_20 -XX:+UseCompressedOops -XX:+UseSerialGC (asserts: false)

5 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest

Error Message:
ERROR: SolrIndexSearcher opens=4 closes=1

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=4 closes=1
at __randomizedtesting.SeedInfo.seed([D9864374E8E5CEF0]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:447)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:187)
at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:790)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
46 threads leaked from SUITE scope at org.apache.solr.cloud.HttpPartitionTest:  
   1) Thread[id=7846, name=qtp859836886-7846 Acceptor1 
SelectChannelConnector@127.0.0.1:53819, state=BLOCKED, 
group=TGRP-HttpPartitionTest] at 
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:224) 
at 
org.eclipse.jetty.server.nio.SelectChannelConnector.accept(SelectChannelConnector.java:109)
 at 
org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:938)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) 
at java.lang.Thread.run(Thread.java:745)2) Thread[id=7859, 
name=Thread-3293, state=WAITING, group=TGRP-HttpPartitionTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:502) at 
org.apache.solr.core.CloserThread.run(CoreContainer.java:929)3) 
Thread[id=7823, name=qtp1575822333-7823 Selector1, state=RUNNABLE, 
group=TGRP-HttpPartitionTest] at 
sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at 
sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at 
sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at 
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at 
org.eclipse.jetty.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:569)
 at 
org.eclipse.jetty.io.nio.SelectorManager$1.run(SelectorManager.java:290)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) 
at java.lang.Thread.run(Thread.java:745)4) Thread[id=7825, 
name=qtp1575822333-7825 Acce

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_40-ea-b09) - Build # 4533 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4533/
Java: 32bit/jdk1.8.0_40-ea-b09 -client -XX:+UseConcMarkSweepGC (asserts: true)

2 tests failed.
FAILED:  org.apache.solr.handler.TestSolrConfigHandlerCloud.testDistribSearch

Error Message:
Could not get expected value  P val for path [response, params, y, p] full 
output {   "responseHeader":{ "status":0, "QTime":0},   "response":{
 "znodeVersion":1, "params":{   "x":{ "a":"A val", 
"b":"B val", "":{"v":0}},   "y":{ "c":"CY val", 
"b":"BY val", "":{"v":0}

Stack Trace:
java.lang.AssertionError: Could not get expected value  P val for path 
[response, params, y, p] full output {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":1,
"params":{
  "x":{
"a":"A val",
"b":"B val",
"":{"v":0}},
  "y":{
"c":"CY val",
"b":"BY val",
"":{"v":0}
at 
__randomizedtesting.SeedInfo.seed([42224DF15038E4B7:C3C4C3E92767848B]: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:231)
at 
org.apache.solr.handler.TestSolrConfigHandlerCloud.testReqParams(TestSolrConfigHandlerCloud.java:253)
at 
org.apache.solr.handler.TestSolrConfigHandlerCloud.doTest(TestSolrConfigHandlerCloud.java:61)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsea

[jira] [Commented] (SOLR-6907) URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in file name

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-6907:
--

OK, could you create a proper patch file and attach it then? That's the usual 
way patches
are submitted, and it allows the author to insure that the right code is 
current. It also
keeps a permanent record of the change not dependent on an external repo.

Once you do I'll commit it. Please make it a delta to the newly-committed code 
rather than
from the original.

Thanks,


> URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in 
> file name
> ---
>
> Key: SOLR-6907
> URL: https://issues.apache.org/jira/browse/SOLR-6907
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce, Tests
>Reporter: Ramkumar Aiyengar
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6907.patch
>
>
> Currently the test fails if the source is checked out on a directory whose 
> path contains, say spaces..



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

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

Re: One other question

[Erick Erickson]

Oops, was a private e-mail. Anyway, yes this was a failure on my part to
check the autocomplete.

Erick

On Sat, Jan 3, 2015 at 6:41 PM, david.w.smi...@gmail.com <
david.w.smi...@gmail.com> wrote:

> I’m puzzled… did you mean to send this to our dev list?  The wording
> suggests it was in error.
>
> ~ David Smiley
> Freelance Apache Lucene/Solr Search Consultant/Developer
> http://www.linkedin.com/in/davidwsmiley
>
> On Sat, Jan 3, 2015 at 1:47 PM, Erick Erickson 
> wrote:
>
>> My son-in-law pointed me at a couple of things I wanted to bounce off you
>> re: retirement plans.
>>
>> I guess the main question is whether I should put it on my radar to open
>> up a solr 401K for 2015 (missed the deadline for 2014, I it's been a busy
>> year).
>>
>> On a very quick look, there are three options:
>> 1> solo 401(K).
>> 2> just continue with SEP
>> 3> solr 401(K) with defined benefit plan.
>>
>> I'm guessing that we can take <3> right off the table as it has
>> longer-term commitments than I want to deal with. Who knows? I could
>> actually, you know, retire in the next few years.
>>
>> Is there any downside to the solo 401(K) here? On a _very_ quick glance,
>> it looks like the setup costs are minimal. How does that interact with the
>> SEP? I'm hoping that they're independent and I could contribute to one or
>> the other in a given year and the fact the the other one existed would be
>> of no consequence.
>>
>> Thanks,
>> Erick
>>
>
>

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11846/
Java: 64bit/jdk1.8.0_20 -XX:+UseCompressedOops -XX:+UseG1GC (asserts: true)

1 tests failed.
FAILED:  
org.apache.solr.handler.component.DistributedFacetPivotLongTailTest.testDistribSearch

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:37841
at 
__randomizedtesting.SeedInfo.seed([E6652A290BA3A0CA:6783A4317CFCC0F6]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:570)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:214)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:210)
at 
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:124)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:117)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:103)
at 
org.apache.solr.handler.component.DistributedFacetPivotLongTailTest.doTest(DistributedFacetPivotLongTailTest.java:74)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.e

[jira] [Created] (SOLR-6908) SimplePostTool's help message is incorrect -Durl parameter

[Alexandre Rafalovitch (JIRA)]

Alexandre Rafalovitch created SOLR-6908:
---

 Summary: SimplePostTool's help message is incorrect -Durl parameter
 Key: SOLR-6908
 URL: https://issues.apache.org/jira/browse/SOLR-6908
 Project: Solr
  Issue Type: Bug
  Components: documentation
Affects Versions: 5.0
Reporter: Alexandre Rafalovitch
Priority: Minor
 Fix For: 5.0


{quote}
java -jar post.jar -h

...
java -Durl=http://localhost:8983/solr/update/extract -Dparams=literal.id=a 
-Dtype=application/pdf -jar post.jar a.pdf
...
{quote}

The example is the only one for -Durl and is not correct as it is missing the 
collection name. Also, even though this is an example, *a.pdf* does not exist, 
but we do have *solr-word.pdf* now.

So, this should probably say:
{quote}
java -Durl=http://localhost:8983/solr/techproducts/update/extract 
-Dparams=literal.id=pdf1 -Dtype=application/pdf -jar post.jar solr-word.pdf
{quote}

Also, it is worth mentioning (if true) that specifying *-Durl* overrides *-Dc*.



--
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-6159) TestSearcherManager sometimes uses too many files

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6159:


+1

> TestSearcherManager sometimes uses too many files
> -
>
> Key: LUCENE-6159
> URL: https://issues.apache.org/jira/browse/LUCENE-6159
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-6159.patch
>
>
> on branch_5x:
>  
> ant test  -Dtestcase=TestSearcherManager -Dtests.seed=D6BC19E58A39CA7 
> -Dtests.multiplier=2 -Dtests.nightly=true
> it reproduces, its not hitting the operating system limit, instead the 
> mockfilesystem one in TestRuleTemporaryFilesCleanup:
> {code}
>   // os/config-independent limit for too many open files
>   // TODO: can we make this lower?
>   private static final int MAX_OPEN_FILES = 2048;
> {code}
> I havent looked further only to check it reproduced.



--
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-6907) URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in file name

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar commented on SOLR-6907:
-

Erick, I think this contains the first version of the patch, without Uwe's 
suggestions..

> URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in 
> file name
> ---
>
> Key: SOLR-6907
> URL: https://issues.apache.org/jira/browse/SOLR-6907
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce, Tests
>Reporter: Ramkumar Aiyengar
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6907.patch
>
>
> Currently the test fails if the source is checked out on a directory whose 
> path contains, say spaces..



--
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-6907) URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in file name

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-6907.
--
   Resolution: Fixed
Fix Version/s: Trunk
   5.0

Thanks Ramkumar!

> URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in 
> file name
> ---
>
> Key: SOLR-6907
> URL: https://issues.apache.org/jira/browse/SOLR-6907
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce, Tests
>Reporter: Ramkumar Aiyengar
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6907.patch
>
>
> Currently the test fails if the source is checked out on a directory whose 
> path contains, say spaces..



--
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-6907) URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in file name

[ASF subversion and git services (JIRA)]

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

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

Commit 1649386 from [~erickoerickson] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1649386 ]

SOLR-6907: URLEncode documents directory in MorphlineMapperTest to handle 
spaces etc in file name

> URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in 
> file name
> ---
>
> Key: SOLR-6907
> URL: https://issues.apache.org/jira/browse/SOLR-6907
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce, Tests
>Reporter: Ramkumar Aiyengar
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-6907.patch
>
>
> Currently the test fails if the source is checked out on a directory whose 
> path contains, say spaces..



--
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-6907) URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in file name

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-6907:
-
Attachment: SOLR-6907.patch

Ramkumar's changes with CHANGES.txt entry.

> URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in 
> file name
> ---
>
> Key: SOLR-6907
> URL: https://issues.apache.org/jira/browse/SOLR-6907
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce, Tests
>Reporter: Ramkumar Aiyengar
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-6907.patch
>
>
> Currently the test fails if the source is checked out on a directory whose 
> path contains, say spaces..



--
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-6907) URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in file name

[ASF subversion and git services (JIRA)]

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

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

Commit 1649383 from [~erickoerickson] in branch 'dev/trunk'
[ https://svn.apache.org/r1649383 ]

SOLR-6907: URLEncode documents directory in MorphlineMapperTest to handle 
spaces etc in file name

> URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in 
> file name
> ---
>
> Key: SOLR-6907
> URL: https://issues.apache.org/jira/browse/SOLR-6907
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce, Tests
>Reporter: Ramkumar Aiyengar
>Assignee: Erick Erickson
>Priority: Minor
>
> Currently the test fails if the source is checked out on a directory whose 
> path contains, say spaces..



--
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-6907) URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in file name

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-6907:
-
Summary: URLEncode documents directory in MorphlineMapperTest to handle 
spaces etc. in file name  (was: URLEncode documents directory in 
MorphlineMapperTest)

> URLEncode documents directory in MorphlineMapperTest to handle spaces etc. in 
> file name
> ---
>
> Key: SOLR-6907
> URL: https://issues.apache.org/jira/browse/SOLR-6907
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce, Tests
>Reporter: Ramkumar Aiyengar
>Assignee: Erick Erickson
>Priority: Minor
>
> Currently the test fails if the source is checked out on a directory whose 
> path contains, say spaces..



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

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

Re: Solr 5 build fails - who do I tell?

[Erick Erickson]

Do note, though, that this should be fixed very quickly if it happens.
There'll be all sorts of messages here on the dev list about build failures
and someone usually notices/fixes ASAP.

On Sun, Jan 4, 2015 at 9:51 AM, Erik Hatcher  wrote:

> Alex - in general, I think you did the right thing by e-mailing here.
> However, you could also ping in the #lucene-dev IRC channel if you wanted
> more real-time attention.
>
> Please provide the details of the errors you’re seeing, and any relevant
> environmental details - that would have been higher impact than not
> providing details :)
>
> Erik
>
>
> > On Jan 4, 2015, at 11:35 AM, Alexandre Rafalovitch 
> wrote:
> >
> > Hi,
> >
> > I did a checkout of the latest 5.0 and the build fails (with ant clean
> > package). With errors from two different JIRAs ports it seems.
> >
> > Should I provide the feedback or do I assume that the Jenkins builds
> > catch this? I can see the build fails, but does not seem to be where
> > mine is? Does it exercise the same build path?
> >
> > If I do need to contact somebody, do I just ping this mailing list or
> > should I notify the JIRAs that I think caused this? Or both?
> >
> > What's the minimum noise + highest impact strategy here?
> >
> > Thanks,
> >   Alex.
> > 
> > Sign up for my Solr resources newsletter at http://www.solr-start.com/
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: One other question

[Erick Erickson]

Already been answered in this thread.

On Sat, Jan 3, 2015 at 6:41 PM, david.w.smi...@gmail.com <
david.w.smi...@gmail.com> wrote:

> I’m puzzled… did you mean to send this to our dev list?  The wording
> suggests it was in error.
>
> ~ David Smiley
> Freelance Apache Lucene/Solr Search Consultant/Developer
> http://www.linkedin.com/in/davidwsmiley
>
> On Sat, Jan 3, 2015 at 1:47 PM, Erick Erickson 
> wrote:
>
>> My son-in-law pointed me at a couple of things I wanted to bounce off you
>> re: retirement plans.
>>
>> I guess the main question is whether I should put it on my radar to open
>> up a solr 401K for 2015 (missed the deadline for 2014, I it's been a busy
>> year).
>>
>> On a very quick look, there are three options:
>> 1> solo 401(K).
>> 2> just continue with SEP
>> 3> solr 401(K) with defined benefit plan.
>>
>> I'm guessing that we can take <3> right off the table as it has
>> longer-term commitments than I want to deal with. Who knows? I could
>> actually, you know, retire in the next few years.
>>
>> Is there any downside to the solo 401(K) here? On a _very_ quick glance,
>> it looks like the setup costs are minimal. How does that interact with the
>> SEP? I'm hoping that they're independent and I could contribute to one or
>> the other in a given year and the fact the the other one existed would be
>> of no consequence.
>>
>> Thanks,
>> Erick
>>
>
>

Re: Solr 5 build fails - who do I tell?

[Erik Hatcher]

Alex - in general, I think you did the right thing by e-mailing here.  However, 
you could also ping in the #lucene-dev IRC channel if you wanted more real-time 
attention.

Please provide the details of the errors you’re seeing, and any relevant 
environmental details - that would have been higher impact than not providing 
details :)

Erik


> On Jan 4, 2015, at 11:35 AM, Alexandre Rafalovitch  wrote:
> 
> Hi,
> 
> I did a checkout of the latest 5.0 and the build fails (with ant clean
> package). With errors from two different JIRAs ports it seems.
> 
> Should I provide the feedback or do I assume that the Jenkins builds
> catch this? I can see the build fails, but does not seem to be where
> mine is? Does it exercise the same build path?
> 
> If I do need to contact somebody, do I just ping this mailing list or
> should I notify the JIRAs that I think caused this? Or both?
> 
> What's the minimum noise + highest impact strategy here?
> 
> Thanks,
>   Alex.
> 
> Sign up for my Solr resources newsletter at http://www.solr-start.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Solr 5 build fails - who do I tell?

[Alexandre Rafalovitch]

Yeah,

I must have been caught in between the commits or something. 30
minutes later, everything built.

But I think the question is still valid for the next time somebody
hits the problem, assuming it stays there after another hour or
whatever.

Regards,
   Alex.

Sign up for my Solr resources newsletter at http://www.solr-start.com/


On 4 January 2015 at 12:43, Erik Hatcher  wrote:
> I just ran (cd solr; ant clean package) on a clean 5x checkout:
>
>   BUILD SUCCESSFUL
>   Total time: 6 minutes 15 seconds
>
> Mac OS X 10.10.1
>
> $ ant -version
> Apache Ant(TM) version 1.9.4 compiled on April 29 2014
>
> $ java -version
> java version "1.8.0_25"
> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
>
>
>> On Jan 4, 2015, at 11:35 AM, Alexandre Rafalovitch  
>> wrote:
>>
>> Hi,
>>
>> I did a checkout of the latest 5.0 and the build fails (with ant clean
>> package). With errors from two different JIRAs ports it seems.
>>
>> Should I provide the feedback or do I assume that the Jenkins builds
>> catch this? I can see the build fails, but does not seem to be where
>> mine is? Does it exercise the same build path?
>>
>> If I do need to contact somebody, do I just ping this mailing list or
>> should I notify the JIRAs that I think caused this? Or both?
>>
>> What's the minimum noise + highest impact strategy here?
>>
>> Thanks,
>>   Alex.
>> 
>> Sign up for my Solr resources newsletter at http://www.solr-start.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Commented] (SOLR-6127) Improve Solr's exampledocs data

[ASF subversion and git services (JIRA)]

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

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

Commit 1649377 from [~ehatcher] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1649377 ]

SOLR-6127: Fix reference to previously renamed script (merged from trunk 
r1649376)

> Improve Solr's exampledocs data
> ---
>
> Key: SOLR-6127
> URL: https://issues.apache.org/jira/browse/SOLR-6127
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation, scripts and tools
>Reporter: Varun Thacker
>Assignee: Erik Hatcher
> Fix For: 5.0, Trunk
>
> Attachments: LICENSE.txt, README.txt, README.txt, SOLR-6127.patch, 
> film.csv, film.json, film.xml, freebase_film_dump.py, freebase_film_dump.py, 
> freebase_film_dump.py, freebase_film_dump.py, freebase_film_dump.py, 
> freebase_film_dump.py, freebase_film_dump.py
>
>
> Currently 
> - The CSV example has 10 documents.
> - The JSON example has 4 documents.
> - The XML example has 32 documents.
> 1. We should have equal number of documents and the same documents in all the 
> example formats
> 2. A data set which is slightly more comprehensive.



--
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-6127) Improve Solr's exampledocs data

[ASF subversion and git services (JIRA)]

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

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

Commit 1649376 from [~ehatcher] in branch 'dev/trunk'
[ https://svn.apache.org/r1649376 ]

SOLR-6127: Fix reference to previously renamed script

> Improve Solr's exampledocs data
> ---
>
> Key: SOLR-6127
> URL: https://issues.apache.org/jira/browse/SOLR-6127
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation, scripts and tools
>Reporter: Varun Thacker
>Assignee: Erik Hatcher
> Fix For: 5.0, Trunk
>
> Attachments: LICENSE.txt, README.txt, README.txt, SOLR-6127.patch, 
> film.csv, film.json, film.xml, freebase_film_dump.py, freebase_film_dump.py, 
> freebase_film_dump.py, freebase_film_dump.py, freebase_film_dump.py, 
> freebase_film_dump.py, freebase_film_dump.py
>
>
> Currently 
> - The CSV example has 10 documents.
> - The JSON example has 4 documents.
> - The XML example has 32 documents.
> 1. We should have equal number of documents and the same documents in all the 
> example formats
> 2. A data set which is slightly more comprehensive.



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

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

Re: Solr 5 build fails - who do I tell?

[Erik Hatcher]

I just ran (cd solr; ant clean package) on a clean 5x checkout:

  BUILD SUCCESSFUL
  Total time: 6 minutes 15 seconds

Mac OS X 10.10.1

$ ant -version
Apache Ant(TM) version 1.9.4 compiled on April 29 2014

$ java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)


> On Jan 4, 2015, at 11:35 AM, Alexandre Rafalovitch  wrote:
> 
> Hi,
> 
> I did a checkout of the latest 5.0 and the build fails (with ant clean
> package). With errors from two different JIRAs ports it seems.
> 
> Should I provide the feedback or do I assume that the Jenkins builds
> catch this? I can see the build fails, but does not seem to be where
> mine is? Does it exercise the same build path?
> 
> If I do need to contact somebody, do I just ping this mailing list or
> should I notify the JIRAs that I think caused this? Or both?
> 
> What's the minimum noise + highest impact strategy here?
> 
> Thanks,
>   Alex.
> 
> Sign up for my Solr resources newsletter at http://www.solr-start.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2426 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2426/

1 tests failed.
REGRESSION:  org.apache.solr.handler.TestBlobHandler.testDistribSearch

Error Message:
Index: 0, Size: 0

Stack Trace:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at 
__randomizedtesting.SeedInfo.seed([A1FB2431F7CCA3B5:201DAA298093C389]:0)
at java.util.ArrayList.rangeCheck(ArrayList.java:635)
at java.util.ArrayList.get(ArrayList.java:411)
at 
org.apache.solr.handler.TestBlobHandler.doBlobHandlerTest(TestBlobHandler.java:91)
at 
org.apache.solr.handler.TestBlobHandler.doTest(TestBlobHandler.java:180)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 9710 lines...]
   [junit4] Suite: org.apache.solr.handler.TestBl

[jira] [Resolved] (SOLR-6127) Improve Solr's exampledocs data

[Erik Hatcher (JIRA)]

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

Erik Hatcher resolved SOLR-6127.

Resolution: Fixed

Committed to both 5x and trunk.  This will eventually warrant tutorials and 
other documentation updated, but can close this issue now.

> Improve Solr's exampledocs data
> ---
>
> Key: SOLR-6127
> URL: https://issues.apache.org/jira/browse/SOLR-6127
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation, scripts and tools
>Reporter: Varun Thacker
>Assignee: Erik Hatcher
> Fix For: 5.0, Trunk
>
> Attachments: LICENSE.txt, README.txt, README.txt, SOLR-6127.patch, 
> film.csv, film.json, film.xml, freebase_film_dump.py, freebase_film_dump.py, 
> freebase_film_dump.py, freebase_film_dump.py, freebase_film_dump.py, 
> freebase_film_dump.py, freebase_film_dump.py
>
>
> Currently 
> - The CSV example has 10 documents.
> - The JSON example has 4 documents.
> - The XML example has 32 documents.
> 1. We should have equal number of documents and the same documents in all the 
> example formats
> 2. A data set which is slightly more comprehensive.



--
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-6127) Improve Solr's exampledocs data

[ASF subversion and git services (JIRA)]

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

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

Commit 1649356 from [~ehatcher] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1649356 ]

SOLR-6127: add films data to 5x

> Improve Solr's exampledocs data
> ---
>
> Key: SOLR-6127
> URL: https://issues.apache.org/jira/browse/SOLR-6127
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation, scripts and tools
>Reporter: Varun Thacker
>Assignee: Erik Hatcher
> Fix For: 5.0, Trunk
>
> Attachments: LICENSE.txt, README.txt, README.txt, SOLR-6127.patch, 
> film.csv, film.json, film.xml, freebase_film_dump.py, freebase_film_dump.py, 
> freebase_film_dump.py, freebase_film_dump.py, freebase_film_dump.py, 
> freebase_film_dump.py, freebase_film_dump.py
>
>
> Currently 
> - The CSV example has 10 documents.
> - The JSON example has 4 documents.
> - The XML example has 32 documents.
> 1. We should have equal number of documents and the same documents in all the 
> example formats
> 2. A data set which is slightly more comprehensive.



--
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-6127) Improve Solr's exampledocs data

[ASF subversion and git services (JIRA)]

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

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

Commit 1649355 from [~ehatcher] in branch 'dev/trunk'
[ https://svn.apache.org/r1649355 ]

SOLR-6127: fix paths in README

> Improve Solr's exampledocs data
> ---
>
> Key: SOLR-6127
> URL: https://issues.apache.org/jira/browse/SOLR-6127
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation, scripts and tools
>Reporter: Varun Thacker
>Assignee: Erik Hatcher
> Fix For: 5.0, Trunk
>
> Attachments: LICENSE.txt, README.txt, README.txt, SOLR-6127.patch, 
> film.csv, film.json, film.xml, freebase_film_dump.py, freebase_film_dump.py, 
> freebase_film_dump.py, freebase_film_dump.py, freebase_film_dump.py, 
> freebase_film_dump.py, freebase_film_dump.py
>
>
> Currently 
> - The CSV example has 10 documents.
> - The JSON example has 4 documents.
> - The XML example has 32 documents.
> 1. We should have equal number of documents and the same documents in all the 
> example formats
> 2. A data set which is slightly more comprehensive.



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

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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_20) - Build # 11845 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11845/
Java: 64bit/jdk1.8.0_20 -XX:+UseCompressedOops -XX:+UseG1GC (asserts: true)

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

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([9AC08A23A0B30B98]:0)


FAILED:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([9AC08A23A0B30B98]:0)




Build Log:
[...truncated 10327 lines...]
   [junit4] Suite: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest
   [junit4]   2> Creating dataDir: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.ChaosMonkeySafeLeaderTest-9AC08A23A0B30B98-001/init-core-data-001
   [junit4]   2> 945219 T5046 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl 
(true) and clientAuth (true)
   [junit4]   2> 945219 T5046 oas.BaseDistributedSearchTestCase.initHostContext 
Setting hostContext system property: /nt_fmd/ce
   [junit4]   2> 945224 T5046 oas.SolrTestCaseJ4.setUp ###Starting 
testDistribSearch
   [junit4]   2> 945225 T5046 oasc.ZkTestServer.run STARTING ZK TEST SERVER
   [junit4]   1> client port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 945225 T5047 oasc.ZkTestServer$ZKServerMain.runFromConfig 
Starting server
   [junit4]   2> 945325 T5046 oasc.ZkTestServer.run start zk server on 
port:42337
   [junit4]   2> 945326 T5046 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2> 945326 T5046 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2> 945329 T5054 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@2a19be40 
name:ZooKeeperConnection Watcher:127.0.0.1:42337 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 945329 T5046 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2> 945330 T5046 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2> 945330 T5046 oascc.SolrZkClient.makePath makePath: /solr
   [junit4]   2> 945332 T5046 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2> 945334 T5046 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2> 945334 T5057 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@206f995f 
name:ZooKeeperConnection Watcher:127.0.0.1:42337/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 945334 T5046 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2> 945334 T5046 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2> 945335 T5046 oascc.SolrZkClient.makePath makePath: 
/collections/collection1
   [junit4]   2> 945336 T5046 oascc.SolrZkClient.makePath makePath: 
/collections/collection1/shards
   [junit4]   2> 945337 T5046 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection
   [junit4]   2> 945338 T5046 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection/shards
   [junit4]   2> 945339 T5046 oasc.AbstractZkTestCase.putConfig put 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 945340 T5046 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.xml
   [junit4]   2> 945341 T5046 oasc.AbstractZkTestCase.putConfig put 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/schema15.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 945342 T5046 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/schema.xml
   [junit4]   2> 945344 T5046 oasc.AbstractZkTestCase.putConfig put 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 945344 T5046 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 945346 T5046 oasc.AbstractZkTestCase.putConfig put 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/test-files/solr/collection1/conf/stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 945347 T5046 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/stopwords.txt
   [junit4]   2> 945349 T5046 oasc.AbstractZkTestCase.putConfig put 
/mnt/ssd/jenkins/workspace/Lucene-

Solr 5 build fails - who do I tell?

[Alexandre Rafalovitch]

Hi,

I did a checkout of the latest 5.0 and the build fails (with ant clean
package). With errors from two different JIRAs ports it seems.

Should I provide the feedback or do I assume that the Jenkins builds
catch this? I can see the build fails, but does not seem to be where
mine is? Does it exercise the same build path?

If I do need to contact somebody, do I just ping this mailing list or
should I notify the JIRAs that I think caused this? Or both?

What's the minimum noise + highest impact strategy here?

Thanks,
   Alex.

Sign up for my Solr resources newsletter at http://www.solr-start.com/

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

[jira] [Commented] (SOLR-6900) bin/post improvements needed

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-6900:


Another one: handle stdin, such that `cat data.csv | bin/post my_collection` 
works.  SimplePostTool can do this standalone.

> bin/post improvements needed
> 
>
> Key: SOLR-6900
> URL: https://issues.apache.org/jira/browse/SOLR-6900
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, Trunk
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: 5.0, Trunk
>
>
> * Fix glob patterns.  They don't work as expected: bin/post collection1 
> \*.xml expands \*.xml such that the script gets all the file names as 
> parameters not just literally "\*.xml"
> * Add error handling to check that the collection exists
> * Create Windows version



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2035/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC (asserts: true)

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

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:49772
at 
__randomizedtesting.SeedInfo.seed([EFAB7135C1535986:6E4DFF2DB60C39BA]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:570)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:214)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:210)
at 
org.apache.solr.cloud.ShardSplitTest.splitShard(ShardSplitTest.java:531)
at 
org.apache.solr.cloud.ShardSplitTest.incompleteOrOverlappingCustomRangeTest(ShardSplitTest.java:150)
at org.apache.solr.cloud.ShardSplitTest.doTest(ShardSplitTest.java:102)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
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:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apac

[jira] [Commented] (LUCENE-6149) Infix suggesters' highlighting, allTermsRequired options are hardwired and not configurable for non-contextual lookup

[Boon Low (JIRA)]

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

Boon Low commented on LUCENE-6149:
--

That patch was based upon and tested with the v4.10.3 release on Dec 20. But I 
can see that have been significant changes to AnalyzingInfixSuggester in the 
trunk.

Shall update and test the patch tomorrow.

> Infix suggesters' highlighting, allTermsRequired options are hardwired and 
> not configurable for non-contextual lookup
> -
>
> Key: LUCENE-6149
> URL: https://issues.apache.org/jira/browse/LUCENE-6149
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/other
>Affects Versions: 4.9, 4.10.1, 4.10.2, 4.10.3
>Reporter: Boon Low
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
>  Labels: suggester
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6149.patch
>
>
> Highlighting and allTermsRequired are hardwired in _AnalyzingInfixSuggester_ 
> for non-contextual lookup (via _Lookup_) see *true*, *true* below:
> {code:title=AnalyzingInfixSuggester.java (extends Lookup.java) }
> public List lookup(CharSequence key, Set contexts, 
> boolean onlyMorePopular, int num) throws IOException {
> return lookup(key, contexts, num, true, true);
> }
> /** Lookup, without any context. */
> public List lookup(CharSequence key, int num, boolean 
> allTermsRequired, boolean doHighlight) throws IOException {
> return lookup(key, null, num, allTermsRequired, doHighlight);
>   }
> {code}
> {code:title=Lookup.java}
> public List lookup(CharSequence key, boolean onlyMorePopular, 
> int num) throws IOException {
> return lookup(key, null, onlyMorePopular, num);
> }
> {code}
> The above means the majority of the current infix suggester lookup always 
> return highlighted results with allTermsRequired in effect. There is no way 
> to change this despite the options and improvement of LUCENE-6050, made to 
> incorporate Boolean lookup clauses (MUST/SHOULD). This shortcoming has also 
> been reported in SOLR-6648.
> The suggesters (AnalyzingInfixSuggester, BlendedInfixSuggester) should 
> provide a proper mechanism to set defaults for highlighting and 
> "allTermsRequired", e.g. in constructors (and in Solr factories, thus 
> configurable via solrconfig.xml). 



--
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-6787) API to manage blobs in Solr

[ASF subversion and git services (JIRA)]

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

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

Commit 1649349 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1649349 ]

SOLR-6787  more logging to trace errors

> API to manage blobs in  Solr
> 
>
> Key: SOLR-6787
> URL: https://issues.apache.org/jira/browse/SOLR-6787
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6787.patch, SOLR-6787.patch
>
>
> A special collection called .system needs to be created by the user to 
> store/manage blobs. The schema/solrconfig of that collection need to be 
> automatically supplied by the system so that there are no errors
> APIs need to be created to manage the content of that collection
> {code}
> #create your .system collection first
> http://localhost:8983/solr/admin/collections?action=CREATE&name=.system&replicationFactor=2
> #The config for this collection is automatically created . numShards for this 
> collection is hardcoded to 1
> #create a new jar or add a new version of a jar
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary 
> @mycomponent.jar http://localhost:8983/solr/.system/blob/mycomponent
> #  GET on the end point would give a list of jars and other details
> curl http://localhost:8983/solr/.system/blob 
> # GET on the end point with jar name would give  details of various versions 
> of the available jars
> curl http://localhost:8983/solr/.system/blob/mycomponent
> # GET on the end point with jar name and version with a wt=filestream to get 
> the actual file
> curl http://localhost:8983/solr/.system/blob/mycomponent/1?wt=filestream > 
> mycomponent.1.jar
> # GET on the end point with jar name and wt=filestream to get the latest 
> version of the file
> curl http://localhost:8983/solr/.system/blob/mycomponent?wt=filestream > 
> mycomponent.jar
> {code}
> Please note that the jars are never deleted. a new version is added to the 
> system everytime a new jar is posted for the name. You must use the standard 
> delete commands to delete the old entries



--
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-6801) Load RequestHandler from blob store

[ASF subversion and git services (JIRA)]

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

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

Commit 1649348 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1649348 ]

SOLR-6801 increase wait times to address failures 
http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1989/

> Load RequestHandler from blob store
> ---
>
> Key: SOLR-6801
> URL: https://issues.apache.org/jira/browse/SOLR-6801
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6801.patch, SOLR-6801.patch
>
>
> The solrconfig APIs ( SOLR-6607)  now allow registering components through 
> API. SOLR-6787 will support for blob storage. 
> Jars should be able to be loaded from blobs
> example 
> {code}
>  curl http://localhost:8983/solr/gettingstarted/config -H "Content-Type: 
> application/json"  -d '{
> "create-requesthandler" : {"name" : "/mypath" ,
>
> "class":"org.apache.solr.handler.DumpRequestHandler",
>"lib" : "mycomponent",
>"version":2}
> }'
> {code}



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

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

[jira] [Commented] (LUCENE-6005) Explore alternative to Document/Field/FieldType API

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-6005:
-

Commit 1649347 from [~mikemccand] in branch 'dev/branches/lucene6005'
[ https://svn.apache.org/r1649347 ]

LUCENE-6005: merge trunk

> Explore alternative to Document/Field/FieldType API
> ---
>
> Key: LUCENE-6005
> URL: https://issues.apache.org/jira/browse/LUCENE-6005
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk
>
>
> Auto-prefix terms (LUCENE-5879) is blocked because it's impossible in
> Lucene today to add a simple API to use it, and I don't think we
> should commit features that only super-experts can figure out how to
> use: that's evil.
> The only realistic "workaround" for such new features is to instead
> add them directly to the various servers on top of Lucene, since they
> all already have nice schema APIs.
> I opened LUCENE-5989 to try do at least a baby step towards making it
> easier to use auto-prefix terms, so you can easily add singleton
> binary tokens, but even that has proven controversial.
> Net/net I think we have to solve the root cause of this by fixing the
> Document/Field/FieldType API so that new index-level features can have
> a usable API, properly defaulted for the right types of fields.
> Towards that, I'm exploring a replacement for
> Document/Field/FieldType.  The idea is to expose simple methods on the
> document class (no more separate Field and FieldType classes):
> {noformat}
> doc.addLargeText("body", "some text");
> doc.addShortText("title", "a title");
> doc.addAtom("id", "29jafnn");
> doc.addBinary("bytes", new byte[7]);
> doc.addNumber("number", 17);
> {noformat}
> And then expose a separate FieldTypes class, that you pass to ctor of
> the new document class, which lets you set all the various per-field
> settings (stored, doc values, etc.).  E.g.:
> {noformat}
> types.enableStored("id");
> {noformat}
> FieldTypes is a write-once schema, and it throws exceptions if you try
> to make invalid changes once a given setting is already written
> (e.g. enabling norms after having disabled them).  It will (I haven't
> implemented this yet) save its state into IndexWriter's commitData, so
> it's available when you open a new IndexWriter for append and when you
> open a reader.
> It has methods to set all the per-field settings (analyzer, stored,
> term vectors, norms, index options, doc values type), and chooses
> "reasonable" defaults based on the value's type when it suddenly sees
> a new field.  For example, when you add a number, it's indexed for
> range querying and sorting (numeric doc values) by default.
> FieldTypes provides the analyzer and codec (a little messy) that you
> pass to IndexWriterConfig.  Since it's effectively a persistent
> schema, it knows all about the available fields at search time, so we
> could use it to create queries (checking if they are valid given that
> field's type).  Query parsers and highlighters could consult it.
> Default UIs (above Lucene) could use it, etc.  This is all future .. I
> think for this issue the goal should be to "just" provide a "better"
> index-time API but not yet make use of it at search time.
> So with this change, for auto-prefix terms, we could add an "enable
> range queries/filters" option, but then validate that the selected
> postings format supports such an option.
> I know this exploration will be horribly controversial, but
> realistically I don't think Lucene can move on much further if we
> can't finally address this schema problem head on.
> This is long overdue.



--
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-6801) Load RequestHandler from blob store

[ASF subversion and git services (JIRA)]

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

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

Commit 1649346 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1649346 ]

SOLR-6801 increase wait times to address failures 
http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1989/

> Load RequestHandler from blob store
> ---
>
> Key: SOLR-6801
> URL: https://issues.apache.org/jira/browse/SOLR-6801
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6801.patch, SOLR-6801.patch
>
>
> The solrconfig APIs ( SOLR-6607)  now allow registering components through 
> API. SOLR-6787 will support for blob storage. 
> Jars should be able to be loaded from blobs
> example 
> {code}
>  curl http://localhost:8983/solr/gettingstarted/config -H "Content-Type: 
> application/json"  -d '{
> "create-requesthandler" : {"name" : "/mypath" ,
>
> "class":"org.apache.solr.handler.DumpRequestHandler",
>"lib" : "mycomponent",
>"version":2}
> }'
> {code}



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

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

[jira] [Created] (LUCENE-6161) Applying deletes is sometimes dog slow

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-6161:
--

 Summary: Applying deletes is sometimes dog slow
 Key: LUCENE-6161
 URL: https://issues.apache.org/jira/browse/LUCENE-6161
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
 Fix For: 5.0, Trunk


I hit this while testing various use cases for LUCENE-6119 (adding 
auto-throttle to ConcurrentMergeScheduler).

When I tested "always call updateDocument" (each add buffers a delete term), 
with many indexing threads, opening an NRT reader once per second (forcing all 
deleted terms to be applied), I see that BufferedUpdatesStream.applyDeletes 
sometimes seems to take a lng time, e.g.:

{noformat}
BD 0 [2015-01-04 09:31:12.597; Lucene Merge Thread #69]: applyDeletes took 339 
msec for 10 segments, 117 deleted docs, 607333 visited terms
BD 0 [2015-01-04 09:31:18.148; Thread-4]: applyDeletes took 5533 msec for 62 
segments, 10989 deleted docs, 8517225 visited terms
BD 0 [2015-01-04 09:31:21.463; Lucene Merge Thread #71]: applyDeletes took 1065 
msec for 10 segments, 470 deleted docs, 1825649 visited terms
BD 0 [2015-01-04 09:31:26.301; Thread-5]: applyDeletes took 4835 msec for 61 
segments, 14676 deleted docs, 9649860 visited terms
BD 0 [2015-01-04 09:31:35.572; Thread-11]: applyDeletes took 6073 msec for 72 
segments, 13835 deleted docs, 11865319 visited terms
BD 0 [2015-01-04 09:31:37.604; Lucene Merge Thread #75]: applyDeletes took 251 
msec for 10 segments, 58 deleted docs, 240721 visited terms
BD 0 [2015-01-04 09:31:44.641; Thread-11]: applyDeletes took 5956 msec for 64 
segments, 15109 deleted docs, 10599034 visited terms
BD 0 [2015-01-04 09:31:47.814; Lucene Merge Thread #77]: applyDeletes took 396 
msec for 10 segments, 137 deleted docs, 719914 visit
{noformat}

What this means is even though I want an NRT reader every second, often I don't 
get one for up to ~7 or more seconds.

This is on an SSD, machine has 48 GB RAM, heap size is only 2 GB.  12 indexing 
threads.

As hideously complex as this code is, I think there are some inefficiencies, 
but fixing them could be hard / make code even hairier ...

Also, this code is mega-locked: holds IW's lock, holds BD's lock.  It blocks 
things like merges kicking off or finishing...

E.g., we pull the MergedIterator many times on the same set of sub-iterators.  
Maybe we can create the sorted terms up front and reuse that?

Maybe we should go "term stride" (one term visits all N segments) not "segment 
stride" (visit each segment, iterating all deleted terms for it).  Just 
iterating the terms to be deleted takes a sizable part of the time, and we now 
do that once for every segment in the index.

Also, the "isUnique" bit in LUCENE-6005 should help here, since if we know the 
field is unique, we can stop seekExact once we found a segment that has the 
deleted term, we can maybe pass false for removeDuplicates to MergedIterator...



--
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-6801) Load RequestHandler from blob store

[ASF subversion and git services (JIRA)]

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

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

Commit 1649345 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1649345 ]

SOLR-6801 increase wait times to address failures 
http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1989/

> Load RequestHandler from blob store
> ---
>
> Key: SOLR-6801
> URL: https://issues.apache.org/jira/browse/SOLR-6801
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6801.patch, SOLR-6801.patch
>
>
> The solrconfig APIs ( SOLR-6607)  now allow registering components through 
> API. SOLR-6787 will support for blob storage. 
> Jars should be able to be loaded from blobs
> example 
> {code}
>  curl http://localhost:8983/solr/gettingstarted/config -H "Content-Type: 
> application/json"  -d '{
> "create-requesthandler" : {"name" : "/mypath" ,
>
> "class":"org.apache.solr.handler.DumpRequestHandler",
>"lib" : "mycomponent",
>"version":2}
> }'
> {code}



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

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

[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.7.0_67) - Build # 11676 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11676/
Java: 32bit/jdk1.7.0_67 -client -XX:+UseConcMarkSweepGC (asserts: true)

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

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:36401
at 
__randomizedtesting.SeedInfo.seed([64EFE3E71686ABC9:E5096DFF61D9CBF5]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:568)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:214)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:210)
at 
org.apache.solr.cloud.ShardSplitTest.splitShard(ShardSplitTest.java:531)
at 
org.apache.solr.cloud.ShardSplitTest.incompleteOrOverlappingCustomRangeTest(ShardSplitTest.java:137)
at org.apache.solr.cloud.ShardSplitTest.doTest(ShardSplitTest.java:102)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene

[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.8.0_20) - Build # 4428 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4428/
Java: 64bit/jdk1.8.0_20 -XX:-UseCompressedOops -XX:+UseSerialGC (asserts: false)

2 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([92E7BFB926C2E12A]:0)


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

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([92E7BFB926C2E12A]:0)




Build Log:
[...truncated 9840 lines...]
   [junit4] Suite: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest
   [junit4]   2> Creating dataDir: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.ChaosMonkeySafeLeaderTest-92E7BFB926C2E12A-001\init-core-data-001
   [junit4]   2> 2063359 T8987 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl 
(false) and clientAuth (true)
   [junit4]   2> 2063362 T8987 
oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext system 
property: /fdiy/v
   [junit4]   2> 2063365 T8987 oas.SolrTestCaseJ4.setUp ###Starting 
testDistribSearch
   [junit4]   2> 2063366 T8987 oasc.ZkTestServer.run STARTING ZK TEST SERVER
   [junit4]   1> client port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 2063367 T8988 oasc.ZkTestServer$ZKServerMain.runFromConfig 
Starting server
   [junit4]   2> 2063457 T8987 oasc.ZkTestServer.run start zk server on 
port:52477
   [junit4]   2> 2063457 T8987 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2> 2063459 T8987 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2> 2063466 T8995 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@585fc6bd 
name:ZooKeeperConnection Watcher:127.0.0.1:52477 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 2063466 T8987 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2> 2063466 T8987 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2> 2063466 T8987 oascc.SolrZkClient.makePath makePath: /solr
   [junit4]   2> 2063476 T8987 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2> 2063478 T8987 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2> 2063479 T8998 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@1ec36e15 
name:ZooKeeperConnection Watcher:127.0.0.1:52477/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 2063479 T8987 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2> 2063479 T8987 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2> 2063480 T8987 oascc.SolrZkClient.makePath makePath: 
/collections/collection1
   [junit4]   2> 2063484 T8987 oascc.SolrZkClient.makePath makePath: 
/collections/collection1/shards
   [junit4]   2> 2063486 T8987 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection
   [junit4]   2> 2063489 T8987 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection/shards
   [junit4]   2> 2063493 T8987 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 2063493 T8987 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.xml
   [junit4]   2> 2063498 T8987 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\test-files\solr\collection1\conf\schema15.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 2063499 T8987 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/schema.xml
   [junit4]   2> 2063504 T8987 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 2063504 T8987 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 2063508 T8987 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\test-files\solr\collection1\conf\stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 2063509 T8987 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/stopwords.txt
   [junit4]   2> 2063513 T8987 oasc.AbstractZkT

[jira] [Commented] (SOLR-4839) Jetty 9

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-4839:
-

I will disable the tests of course once this is committed. Lucene trunk's tests 
are already disabled, because Java 8 crushes while running Solr tests (also 
inside networking code).

> Jetty 9
> ---
>
> Key: SOLR-4839
> URL: https://issues.apache.org/jira/browse/SOLR-4839
> Project: Solr
>  Issue Type: Improvement
>Reporter: Bill Bell
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, 
> SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch
>
>
> Implement Jetty 9



--
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-6735) CloneFieldUpdateProcessorFactory should be null safe

[Erik Hatcher (JIRA)]

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

Erik Hatcher resolved SOLR-6735.

Resolution: Fixed

committed.  Thanks Steve! 

> CloneFieldUpdateProcessorFactory should be null safe
> 
>
> Key: SOLR-6735
> URL: https://issues.apache.org/jira/browse/SOLR-6735
> Project: Solr
>  Issue Type: Bug
>Reporter: Steve Davids
>Assignee: Erik Hatcher
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6735.patch
>
>
> If a source field value is null the CloneFieldUpdateProcessor throws a null 
> pointer exception.



--
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-6735) CloneFieldUpdateProcessorFactory should be null safe

[ASF subversion and git services (JIRA)]

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

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

Commit 1649324 from [~ehatcher] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1649324 ]

SOLR-6735: Make CloneFieldUpdateProcessorFactory null safe (merged with 
CHANGES.txt manual edits from trunk r1649323)

> CloneFieldUpdateProcessorFactory should be null safe
> 
>
> Key: SOLR-6735
> URL: https://issues.apache.org/jira/browse/SOLR-6735
> Project: Solr
>  Issue Type: Bug
>Reporter: Steve Davids
>Assignee: Erik Hatcher
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6735.patch
>
>
> If a source field value is null the CloneFieldUpdateProcessor throws a null 
> pointer exception.



--
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-6735) CloneFieldUpdateProcessorFactory should be null safe

[ASF subversion and git services (JIRA)]

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

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

Commit 1649323 from [~ehatcher] in branch 'dev/trunk'
[ https://svn.apache.org/r1649323 ]

SOLR-6735: Make CloneFieldUpdateProcessorFactory null safe

> CloneFieldUpdateProcessorFactory should be null safe
> 
>
> Key: SOLR-6735
> URL: https://issues.apache.org/jira/browse/SOLR-6735
> Project: Solr
>  Issue Type: Bug
>Reporter: Steve Davids
>Assignee: Erik Hatcher
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6735.patch
>
>
> If a source field value is null the CloneFieldUpdateProcessor throws a null 
> pointer exception.



--
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-6735) CloneFieldUpdateProcessorFactory should be null safe

[Erik Hatcher (JIRA)]

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

Erik Hatcher reassigned SOLR-6735:
--

Assignee: Erik Hatcher

> CloneFieldUpdateProcessorFactory should be null safe
> 
>
> Key: SOLR-6735
> URL: https://issues.apache.org/jira/browse/SOLR-6735
> Project: Solr
>  Issue Type: Bug
>Reporter: Steve Davids
>Assignee: Erik Hatcher
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6735.patch
>
>
> If a source field value is null the CloneFieldUpdateProcessor throws a null 
> pointer exception.



--
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-6359) Allow customization of the number of records and logs kept by UpdateLog

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-6359:
-

bq. The snapshot recovery does not clear tlog of the core being recovered. Is 
it an issue?

No, that's fine. The last two transaction log references are always kept around 
in case a peer sync is needed again.

> Allow customization of the number of records and logs kept by UpdateLog
> ---
>
> Key: SOLR-6359
> URL: https://issues.apache.org/jira/browse/SOLR-6359
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ramkumar Aiyengar
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 5.0, Trunk
>
>
> Currently {{UpdateLog}} hardcodes the number of logs and records it keeps, 
> and the hardcoded numbers (100 records, 10 logs) can be quite low (esp. the 
> records) in an heavily indexing setup, leading to full recovery even if Solr 
> was just stopped and restarted.
> These values should be customizable (even if only present as expert options).



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

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

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_40-ea-b09) - Build # 4532 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4532/
Java: 32bit/jdk1.8.0_40-ea-b09 -server -XX:+UseSerialGC (asserts: false)

1 tests failed.
FAILED:  org.apache.solr.cloud.ReplicationFactorTest.testDistribSearch

Error Message:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:62081/repfacttest_c8n_1x3_shard1_replica1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:62081/repfacttest_c8n_1x3_shard1_replica1
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:581)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:890)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:736)
at 
org.apache.solr.cloud.ReplicationFactorTest.testRf3(ReplicationFactorTest.java:277)
at 
org.apache.solr.cloud.ReplicationFactorTest.doTest(ReplicationFactorTest.java:123)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java

[jira] [Commented] (SOLR-6359) Allow customization of the number of records and logs kept by UpdateLog

[Forest Soup (JIRA)]

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

Forest Soup commented on SOLR-6359:
---

The snapshot recovery does not clear tlog of the core being recovered. Is it an 
issue?

> Allow customization of the number of records and logs kept by UpdateLog
> ---
>
> Key: SOLR-6359
> URL: https://issues.apache.org/jira/browse/SOLR-6359
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ramkumar Aiyengar
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 5.0, Trunk
>
>
> Currently {{UpdateLog}} hardcodes the number of logs and records it keeps, 
> and the hardcoded numbers (100 records, 10 logs) can be quite low (esp. the 
> records) in an heavily indexing setup, leading to full recovery even if Solr 
> was just stopped and restarted.
> These values should be customizable (even if only present as expert options).



--
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-6683) Need a configurable parameter to control the doc number between peersync and the snapshot pull recovery

[Forest Soup (JIRA)]

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

Forest Soup commented on SOLR-6683:
---

The snapshot recovery does not clear tlog of the core being recovered. Is it an 
issue?

> Need a configurable parameter to control the doc number between peersync and 
> the snapshot pull recovery
> ---
>
> Key: SOLR-6683
> URL: https://issues.apache.org/jira/browse/SOLR-6683
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 4.7
> Environment: Redhat Linux 64bit
>Reporter: Forest Soup
>Priority: Critical
>  Labels: performance
>
> If there are >100 docs gap between the recovering node and the good node, the 
> solr will do snap pull recovery instead of peersync.
> Can the 100 docs be configurable? For example, there can be 1, 1000, or 
> 10 docs gap between the good node and the node to recover.
> For 100 doc, a regular restart of a solr node will trigger a full recovery, 
> which is a huge impact to the performance of the running systems
> Thanks!



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1990/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC (asserts: true)

1 tests failed.
FAILED:  org.apache.solr.client.solrj.impl.CloudSolrClientTest.testDistribSearch

Error Message:
Error from server at http://127.0.0.1:64133/checkStateVerCol: STATE STALE: 
checkStateVerCol:28valid : false

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:64133/checkStateVerCol: STATE STALE: 
checkStateVerCol:28valid : false
at 
__randomizedtesting.SeedInfo.seed([CC468E2C29FFB19B:4DA000345EA0D1A7]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:558)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:214)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:210)
at 
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:302)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.stateVersionParamTest(CloudSolrClientTest.java:361)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.doTest(CloudSolrClientTest.java:124)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:868)
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:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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.