date:20150214


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

Noble Paul updated SOLR-1945:
-
Summary: Allow support for child docs in DocumentObjectBinder  (was: Allow 
@Field annotations in nested classes using DocumentObjectBinder)

 Allow support for child docs in DocumentObjectBinder
 

 Key: SOLR-1945
 URL: https://issues.apache.org/jira/browse/SOLR-1945
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Noble Paul
Priority: Minor
 Attachments: SOLR-1945.patch, SOLR-1945.patch


 see 
 http://search.lucidimagination.com/search/document/d909d909420aeb4e/does_solrj_support_nested_annotated_beans
 Would be nice to be able to pass an object graph to solrj with @field 
 annotations rather than just a top level class



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

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

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2643 - Still Failing

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

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

Error Message:
org.apache.http.NoHttpResponseException: The target server failed to respond

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.http.NoHttpResponseException: The target server failed to respond
at 
__randomizedtesting.SeedInfo.seed([8FBBE1313DE894C0:7EFDEEB9314F938]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:865)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730)
at 
org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106)
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 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
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

[jira] [Commented] (LUCENE-6246) Fix DocsEnum - PostingsEnum transition

[
https://issues.apache.org/jira/browse/LUCENE-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321270#comment-14321270
]

Robert Muir commented on LUCENE-6246:
-

FLAG_ALL is also buggy today. The generated bitmask does not actually include
offsets. It would need to be 0xF.

The logic is also wrong here for OFFSETS and PAYLOADS i think too? With the
current constants, OFFSETS implies positions but PAYLOADS does not. This
doesn't make sense...

Fix DocsEnum - PostingsEnum transition
---

Key: LUCENE-6246
URL: https://issues.apache.org/jira/browse/LUCENE-6246
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir

The current back compat introduced in LUCENE-4524, does not really help the
users calling e.g. LeafReader.termDocsEnum() or
LeafReader.termPositionsEnum(), because the former's return value changes to
PostingsEnum, its superclass, and the latter got removed.
It also does not help users using TermsEnum.docs() or
TermsEnum.docsAndPositions() which got removed and just replaced with
postings().
DocsEnum is different, but not deprecated, instead only used by some codecs
as a convenience class. DocsAndPositionsEnum is removed.
I think we can do this a little better. First, we need to fix trunk to work
the way we want it to look. I think we should have LeafReader.postings() and
TermsEnum.postings(), and everything should use PostingsEnum. This is
simplest.
But in 5.x, I think we should have DocsEnum and DocsAndPositionsEnum which
are deprecated, to help guide the user.
The sugar methods on LeafReader that exist in 5.0 (termDocsEnum(),
termPositionsEnum()) should be deprecated (with message to use postings())
and final, and can just wrap PostingsEnum. There is no reuse and flags here
so this is very simple.
On TermsEnum its more complicated, but i dont think impossible. We should add
back deprecated and final termDocsEnum() and termPositionsEnum() (with
message to use postings()) and these deprecated ones can have an instanceof
check, unwrapping back to PostingsEnum before they invoke postings behind the
scenes.
For the 2 remaining ones on TermsEnum that take flags, thats the most tricky.
I actually think we shouldn't change the existing constant values when we
dont have to. And I don't think the names FLAG_FREQS are special, i'd rather
these just be constants like FREQS. I looked thru JDK constants
(http://docs.oracle.com/javase/7/docs/api/constant-values.html) and only one
class uses this FLAG_xxx prefix.
So I think we should have PostingsEnum.FREQS etc with new values, not
conflicting with the old FLAG_FREQS etc values (which we can add back,
deprecated, to DocsEnum and DocsAndPositionsEnum). We can even add a check to
the deprecated methods that only valid values are passed.
This just means we have contained back compat, only for deprecated and final
sugar methods in LeafReader and TermsEnum, and the 2 deprecated classes. I
think we can live with that and it would save users pain.

--
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-6244) Approximations on disjunctions


[ 
https://issues.apache.org/jira/browse/LUCENE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321294#comment-14321294
 ] 

Adrien Grand commented on LUCENE-6244:
--

How funny I've spent entire days working on BooleanScorer and now I forget to 
disable it to benchmark BS2. :-) Indeed it was not disabled and luceneutil 
reports slowdowns of about 20%. Profiling doesn't show a clear culprit so I'll 
try to redo the patch step by step and see how I can make things better.

 Approximations on disjunctions
 --

 Key: LUCENE-6244
 URL: https://issues.apache.org/jira/browse/LUCENE-6244
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
 Fix For: Trunk, 5.1

 Attachments: LUCENE-6244.patch


 Like we just did on exact phrases and conjunctions, we should also support 
 approximations on disjunctions in order to apply matches() lazily.



--
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 #849: POMs out of sync

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

No tests ran.

Build Log:
[...truncated 37093 lines...]
-validate-maven-dependencies:
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-test-framework:5.1.0-SNAPSHOT: checking for updates 
from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-test-framework:5.1.0-SNAPSHOT: checking for updates 
from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-parent:5.1.0-SNAPSHOT: checking for updates from 
sonatype.releases
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-parent:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-parent:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-common:5.1.0-SNAPSHOT: checking for updates 
from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-common:5.1.0-SNAPSHOT: checking for updates 
from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-kuromoji:5.1.0-SNAPSHOT: checking for 
updates from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-kuromoji:5.1.0-SNAPSHOT: checking for 
updates from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-phonetic:5.1.0-SNAPSHOT: checking for 
updates from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-phonetic:5.1.0-SNAPSHOT: checking for 
updates from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-backward-codecs:5.1.0-SNAPSHOT: checking for updates 
from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-backward-codecs:5.1.0-SNAPSHOT: checking for updates 
from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-codecs:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-codecs:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-core:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-core:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-expressions:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-expressions:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-grouping:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-grouping:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-highlighter:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-highlighter:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-join:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-join:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-memory:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-memory:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-misc:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-misc:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queries:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queries:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queryparser:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queryparser:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-spatial:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-spatial:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies]

[jira] [Commented] (LUCENE-6222) Remove TermFilter


[ 
https://issues.apache.org/jira/browse/LUCENE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321401#comment-14321401
 ] 

Adrien Grand commented on LUCENE-6222:
--

+1

 Remove TermFilter
 -

 Key: LUCENE-6222
 URL: https://issues.apache.org/jira/browse/LUCENE-6222
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: LUCENE-6222-bw.patch


 It used to be better than a QueryWrapperFilter(TermQuery) by not decoding 
 freqs but it is not the case anymore since LUCENE-6218



--
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] [Reopened] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


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

Steve Rowe reopened LUCENE-6231:


Reopening again to add multiple download retries

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest
 checkMaven(baseURL, tmpDir, svnRevision, version, isSigned)
   File dev-tools/scripts/smokeTestRelease.py, line 1012, in checkMaven
 crawl(artifacts[project], artifactsURL, targetDir)
   File dev-tools/scripts/smokeTestRelease.py, line 1280, in crawl
 crawl(downloadedFiles, subURL, path, exclusions)
   File dev-tools/scripts/smokeTestRelease.py, line 1280, in crawl
 crawl(downloadedFiles, subURL,

[jira] [Updated] (LUCENE-6246) Fix DocsEnum - PostingsEnum transition

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

Robert Muir updated LUCENE-6246:

Attachment: LUCENE-6246-trunk.patch

Here is a patch with the API changes for trunk.

This is just the conversion to postings(), removal of DocsEnum, renaming of
FLAG_XXX constants, and fixing some documentation bugs.

I'd like to also backport this to 5.x

I didn't change any FLAG constant values yet, because I think this is buggy and
would prefer to have better tests. But I think this is the API we want in
trunk? And it allows us to implement simple deprecations and back compat on 5.x
afterwards.

Fix DocsEnum - PostingsEnum transition
---

Key: LUCENE-6246
URL: https://issues.apache.org/jira/browse/LUCENE-6246
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Attachments: LUCENE-6246-trunk.patch

--
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-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321392#comment-14321392
 ] 

Robert Muir commented on LUCENE-6231:
-

To be frank, why are we suddenly seeing this?

Perhaps the artifacts are just too large (hundreds of megabytes) and we should 
stop trying to workaround it, instead fixing the root cause (including javadocs 
in the binary release, releasing .zip files unnecessarily, etc).

Nobody wants to give here (I tried to remove stupidity here before) but the 
problem is bad and getting worse.

I don't think think we should add any more retries. This conversation may not 
be pleasant but it needs to be had.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version,

[jira] [Created] (LUCENE-6247) artifacts are half a gigabyte

Robert Muir created LUCENE-6247:
---

 Summary: artifacts are half a gigabyte
 Key: LUCENE-6247
 URL: https://issues.apache.org/jira/browse/LUCENE-6247
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
 Fix For: 5.0


This is a growing problem and now, its spun out of control.

The latest release artifacts are half a gigabyte. sorry, I am against adding 
more retries to the smoke tester and continuing down the same path 
(LUCENE-6231).

Instead I open this blocker issue to discuss fixing this. Whenever i tried to 
fix it before (e.g. removing zips), people complained at me what are you 
trying to fix and wouldn't let me minimize it in the slightest.

Now the problem is clear, we have a blocker issue to discuss it.



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

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

[jira] [Resolved] (SOLR-7106) Disable dynamic loading by default


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

Noble Paul resolved SOLR-7106.
--
Resolution: Fixed

 Disable dynamic loading by default
 --

 Key: SOLR-7106
 URL: https://issues.apache.org/jira/browse/SOLR-7106
 Project: Solr
  Issue Type: Task
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Blocker
 Fix For: 5.0

 Attachments: SOLR-7106.patch, SOLR-7106.patch


 Dynamic loading of jars is enabled by default SOLR-6801. It is a security 
 vulnerability and we should set it to be disabled by default



--
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-6222) Remove TermFilter

2015-02-14 Thread Michael McCandless (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321318#comment-14321318
 ] 

Michael McCandless commented on LUCENE-6222:


+1

 Remove TermFilter
 -

 Key: LUCENE-6222
 URL: https://issues.apache.org/jira/browse/LUCENE-6222
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: LUCENE-6222-bw.patch


 It used to be better than a QueryWrapperFilter(TermQuery) by not decoding 
 freqs but it is not the case anymore since LUCENE-6218



--
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-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321395#comment-14321395
 ] 

Robert Muir commented on LUCENE-6231:
-

I opened LUCENE-6247 and set it as a blocker for 5.0

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest
 checkMaven(baseURL, tmpDir, svnRevision, version, isSigned)
   File dev-tools/scripts/smokeTestRelease.py, line 1012, in checkMaven
 crawl(artifacts[project], artifactsURL, targetDir)
   File dev-tools/scripts/smokeTestRelease.py, line 1280, in crawl
 crawl(downloadedFiles, subURL, path, exclusions)
   File

[jira] [Commented] (LUCENE-6247) artifacts are half a gigabyte

2015-02-14 Thread ASF subversion and git services (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321404#comment-14321404
]

Robert Muir commented on LUCENE-6247:
-

The first thing to fix is the embedded javadocs in the binary release.

I love how the esoteric cases love to pop out from trying to do this: but i
dont have an internet connection, i'm on a secure network, blah blah. World's
smallest violin is playing: you guys can run 'ant javadocs'. Very simple.
Everyone else can read them online.

I am going to repeat for the last time: We shouldnt include these tens of
thousands of files in our binary releases when they just bloat them for all
users, when most do not need it.

artifacts are half a gigabyte
-

Key: LUCENE-6247
URL: https://issues.apache.org/jira/browse/LUCENE-6247
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
Fix For: 5.0

This is a growing problem and now, its spun out of control.
The latest release artifacts are half a gigabyte. sorry, I am against adding
more retries to the smoke tester and continuing down the same path
(LUCENE-6231).
Instead I open this blocker issue to discuss fixing this. Whenever i tried to
fix it before (e.g. removing zips), people complained at me what are you
trying to fix and wouldn't let me minimize it in the slightest.
Now the problem is clear, we have a blocker issue to discuss it.

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

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

[jira] [Commented] (LUCENE-6222) Remove TermFilter


[ 
https://issues.apache.org/jira/browse/LUCENE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321403#comment-14321403
 ] 

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

Commit 1659789 from [~rcmuir] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1659789 ]

LUCENE-6222: add backwards compatibility (deprecated TermFilter)

 Remove TermFilter
 -

 Key: LUCENE-6222
 URL: https://issues.apache.org/jira/browse/LUCENE-6222
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: LUCENE-6222-bw.patch


 It used to be better than a QueryWrapperFilter(TermQuery) by not decoding 
 freqs but it is not the case anymore since LUCENE-6218



--
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-6246) Fix DocsEnum - PostingsEnum transition

2015-02-14 Thread Michael McCandless (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321312#comment-14321312
]

Michael McCandless commented on LUCENE-6246:

+1 to the plan and to the trunk patch.

Fix DocsEnum - PostingsEnum transition
---

Key: LUCENE-6246
URL: https://issues.apache.org/jira/browse/LUCENE-6246
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Attachments: LUCENE-6246-trunk.patch

--
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] (LUCENE-1252) Avoid using positions when not all required terms are present

2015-02-14 Thread Paul Elschot (JIRA)


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

Paul Elschot resolved LUCENE-1252.
--
   Resolution: Duplicate
Lucene Fields:   (was: New)

LUCENE-6198 and followups do this. 

 Avoid using positions when not all required terms are present
 -

 Key: LUCENE-1252
 URL: https://issues.apache.org/jira/browse/LUCENE-1252
 Project: Lucene - Core
  Issue Type: Wish
  Components: core/search
Reporter: Paul Elschot
Priority: Minor
  Labels: gsoc2014

 In the Scorers of queries with (lots of) Phrases and/or (nested) Spans, 
 currently next() and skipTo() will use position information even when other 
 parts of the query cannot match because some required terms are not present.
 This could be avoided by adding some methods to Scorer that relax the 
 postcondition of next() and skipTo() to something like all required terms 
 are present, but no position info was checked yet, and implementing these 
 methods for Scorers that do conjunctions: BooleanScorer, PhraseScorer, and 
 SpanScorer/NearSpans.



--
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-7106) Disable dynamic loading by default

2015-02-14 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321400#comment-14321400
 ] 

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

Commit 1659786 from [~noble.paul] in branch 'dev/branches/lucene_solr_5_0'
[ https://svn.apache.org/r1659786 ]

SOLR-7106: Disable dynamic class loading by default

 Disable dynamic loading by default
 --

 Key: SOLR-7106
 URL: https://issues.apache.org/jira/browse/SOLR-7106
 Project: Solr
  Issue Type: Task
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Blocker
 Fix For: 5.0

 Attachments: SOLR-7106.patch, SOLR-7106.patch


 Dynamic loading of jars is enabled by default SOLR-6801. It is a security 
 vulnerability and we should set it to be disabled by default



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

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

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2644 - Still Failing

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

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

Error Message:
org.apache.http.NoHttpResponseException: The target server failed to respond

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.http.NoHttpResponseException: The target server failed to respond
at 
__randomizedtesting.SeedInfo.seed([134BDA1E5C60D4BE:9B1FE5C4F29CB946]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:865)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730)
at 
org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106)
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 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
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

[jira] [Commented] (LUCENE-6244) Approximations on disjunctions


[ 
https://issues.apache.org/jira/browse/LUCENE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321411#comment-14321411
 ] 

Robert Muir commented on LUCENE-6244:
-

I only brought it up because I think its a trap. Maybe later we should fix 
this, for example have BS1 vs BS2 explicitly separate in the benchmarks so we 
never have to worry about this. Its also a trap to put the nocommits in your 
code needed to do the benchmark properly... one of these days, one of us is 
going to make a commit disabling BS1 on accident.

 Approximations on disjunctions
 --

 Key: LUCENE-6244
 URL: https://issues.apache.org/jira/browse/LUCENE-6244
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
 Fix For: Trunk, 5.1

 Attachments: LUCENE-6244.patch


 Like we just did on exact phrases and conjunctions, we should also support 
 approximations on disjunctions in order to apply matches() lazily.



--
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-6245) ConstantScoreQuery etc have crazy toString()'s


[ 
https://issues.apache.org/jira/browse/LUCENE-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321494#comment-14321494
 ] 

Robert Muir commented on LUCENE-6245:
-

I didn't start on anything yet... I didn't know what other options we had. 

Its very surprising to me that Query.toString(String) is abstract but 
Query.toString() is not final, to me that is the root problem and fixing that 
means introducing a break. Anything else I think will be clumsy?

 ConstantScoreQuery etc have crazy toString()'s
 --

 Key: LUCENE-6245
 URL: https://issues.apache.org/jira/browse/LUCENE-6245
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir

 For backwards compatibility reasons, LUCENE-1518 gave Filter a default crap 
 toString(String) impl of getClass().getSimpleName(). I don't think we should 
 do this. It causes problems e.g. when filters are wrapped in 
 ConstantScoreQuery or other places, because toString(String) does the wrong 
 thing.
 {code}
 Filter f = new MultiTermQueryWrapperFilterWildcardQuery(new 
 WildcardQuery(new Term(foo, b*ar)));
 
 System.out.println(f.toString()); // foo:b*ar
 System.out.println(f.toString(foo)); // MultiTermQueryWrapperFilter
 {code}
 Instead i think that impl should be removed (leaving it abstract), and 
 Query.toString() should be final for a hard break:
 {code}
   /** Prints a query to a string, with codefield/code assumed to be the 
* default field and omitted.
*/
   public abstract String toString(String field);
   /** Prints a query to a string. */
   @Override
   public final String toString() {
 return toString();
   }
 {code}
 having buggy toString's is worse than requiring a change in custom filters. 
 It impacts all users rather than just expert ones. Also by doing this, all 
 the current toString bugs in the codebase show up as compile errors.



--
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-6245) ConstantScoreQuery etc have crazy toString()'s


[ 
https://issues.apache.org/jira/browse/LUCENE-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321533#comment-14321533
 ] 

Adrien Grand commented on LUCENE-6245:
--

Right, I thought I could do it without introducing breaks but as you notice it 
does not work.

Then maybe we should only target the merge of queries and filters for 6.0. I 
could back out LUCENE-1518 from 5.x. There is so much left to do that I don't 
think we would be ready anytime soon anyway, and maybe this merge of queries 
and filters could be a good reason to release 6.0 once we are done?

 ConstantScoreQuery etc have crazy toString()'s
 --

 Key: LUCENE-6245
 URL: https://issues.apache.org/jira/browse/LUCENE-6245
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir

 For backwards compatibility reasons, LUCENE-1518 gave Filter a default crap 
 toString(String) impl of getClass().getSimpleName(). I don't think we should 
 do this. It causes problems e.g. when filters are wrapped in 
 ConstantScoreQuery or other places, because toString(String) does the wrong 
 thing.
 {code}
 Filter f = new MultiTermQueryWrapperFilterWildcardQuery(new 
 WildcardQuery(new Term(foo, b*ar)));
 
 System.out.println(f.toString()); // foo:b*ar
 System.out.println(f.toString(foo)); // MultiTermQueryWrapperFilter
 {code}
 Instead i think that impl should be removed (leaving it abstract), and 
 Query.toString() should be final for a hard break:
 {code}
   /** Prints a query to a string, with codefield/code assumed to be the 
* default field and omitted.
*/
   public abstract String toString(String field);
   /** Prints a query to a string. */
   @Override
   public final String toString() {
 return toString();
   }
 {code}
 having buggy toString's is worse than requiring a change in custom filters. 
 It impacts all users rather than just expert ones. Also by doing this, all 
 the current toString bugs in the codebase show up as compile errors.



--
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-6244) Approximations on disjunctions


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

Adrien Grand updated LUCENE-6244:
-
Attachment: wikibig.tasks
LUCENE-6244.patch

I agree it would be important that our benchmarks track the performance of BS2 
as this scorer is probably used pretty often!

I worked a bit more on the patch in order to get back some performance. Because 
things are structured differently, I lost the feature that we confirm at most 
one clause per doc, but at least performance on simple queries is back (with 
BS1 disabled this time):

{noformat}
TaskQPS baseline  StdDev   QPS patch  StdDev
Pct diff
 Respell   70.77  (3.2%)   69.96  (5.6%)   
-1.1% (  -9% -7%)
  Fuzzy2   57.49  (7.8%)   57.03 (10.1%)   
-0.8% ( -17% -   18%)
 AndHighHigh   90.13  (1.7%)   89.61  (2.1%)   
-0.6% (  -4% -3%)
  IntNRQ7.32  (5.2%)7.28  (5.3%)   
-0.5% ( -10% -   10%)
OrNotHighLow  824.56  (3.5%)  821.47  (4.0%)   
-0.4% (  -7% -7%)
HighTerm   73.82  (1.3%)   73.57  (1.1%)   
-0.3% (  -2% -2%)
   LowPhrase   74.18  (1.9%)   73.96  (1.9%)   
-0.3% (  -4% -3%)
HighSpanNear   43.58  (3.4%)   43.49  (3.7%)   
-0.2% (  -7% -7%)
 Prefix3   72.06  (3.9%)   71.91  (3.8%)   
-0.2% (  -7% -7%)
PKLookup  265.53  (3.1%)  265.02  (2.8%)   
-0.2% (  -5% -5%)
  HighPhrase4.24  (4.2%)4.23  (4.4%)   
-0.1% (  -8% -8%)
   OrHighNotHigh   35.52  (1.5%)   35.51  (1.6%)   
-0.0% (  -3% -3%)
HighSloppyPhrase   27.77  (2.4%)   27.77  (2.8%)   
-0.0% (  -5% -5%)
 LowSpanNear   24.53  (5.1%)   24.53  (5.7%)
0.0% ( -10% -   11%)
 MedSloppyPhrase   51.82  (2.5%)   51.83  (2.6%)
0.0% (  -5% -5%)
   OrNotHighHigh   36.18  (1.0%)   36.20  (1.2%)
0.1% (  -2% -2%)
 LowSloppyPhrase   96.11  (2.6%)   96.18  (2.8%)
0.1% (  -5% -5%)
   MedPhrase  134.06  (2.0%)  134.18  (2.5%)
0.1% (  -4% -4%)
  Fuzzy1   64.22  (8.2%)   64.29  (6.3%)
0.1% ( -13% -   15%)
  AndHighMed  206.17  (1.8%)  206.47  (2.5%)
0.1% (  -4% -4%)
Wildcard   27.28  (2.3%)   27.32  (2.9%)
0.2% (  -4% -5%)
 MedSpanNear   36.58  (3.6%)   36.64  (4.1%)
0.2% (  -7% -8%)
  AndHighLow  882.47  (3.8%)  884.53  (4.4%)
0.2% (  -7% -8%)
 MedTerm  297.22  (1.1%)  297.91  (1.4%)
0.2% (  -2% -2%)
OrHighNotLow   80.63  (2.3%)   80.85  (2.5%)
0.3% (  -4% -5%)
OrHighNotMed   97.77  (2.3%)   98.11  (2.2%)
0.3% (  -4% -4%)
OrNotHighMed  189.36  (1.8%)  190.11  (1.8%)
0.4% (  -3% -4%)
 LowTerm  820.55  (2.9%)  830.32  (2.5%)
1.2% (  -4% -6%)
  OrHighHigh   26.44  (4.5%)   27.58  (3.5%)
4.3% (  -3% -   12%)
   OrHighMed   59.16  (4.4%)   62.87  (4.2%)
6.3% (  -2% -   15%)
   OrHighLow8.45  (4.5%)9.10  (4.4%)
7.7% (  -1% -   17%)
{noformat}

I also wanted to test the overhead of propagating approximations to other 
scorers such as conjunctions, so I modified the tasks from LUCENE-6198 to make 
them look like {{+(phrase term1) +term2}} (see attached file), here are the 
results, I think they are encouraging.

{noformat}
TaskQPS baseline  StdDev   QPS patch  StdDev
Pct diff
AndMedPhraseHighTerm   17.10  (2.3%)   15.47  (1.7%)   
-9.5% ( -13% -   -5%)
   AndHighPhraseHighTerm9.04  (2.0%)8.95  (1.2%)   
-1.0% (  -4% -2%)
 AndMedPhraseLowTerm  129.01  (5.2%)  147.93  (9.2%)   
14.7% (   0% -   30%)
AndHighPhraseMedTerm   13.55  (2.4%)   15.90  (2.4%)   
17.3% (  12% -   22%)
AndHighPhraseLowTerm   31.49  (2.7%)   38.07  (3.8%)   
20.9% (  13% -   28%)
 AndMedPhraseMedTerm   25.39  (2.6%)   37.93  (4.1%)   
49.4% (  41% -   57%)
{noformat}

I also added more evil tests to TestApproximationSearchEquivalence.

 Approximations on disjunctions
 --

 Key: LUCENE-6244
 URL:

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321459#comment-14321459
 ] 

Robert Muir commented on LUCENE-6231:
-

I have an easy technical justification: the problem still impacts real users, 
its too hard to download the artifacts, its half a gigabyte.
Adding retries is shoving the problem under the rug, it only hides the 
problem for developers, but does not fix it for users.

This is a serious justification, because it impacts even the most basic usage: 
if you can't even download it, you cannot use it.

It doesn't get any better than this as far as justification.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, '

[jira] [Comment Edited] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321491#comment-14321491
 ] 

Robert Muir edited comment on LUCENE-6231 at 2/14/15 3:22 PM:
--

Here is a listing showing binary release size over time for lucene and solr, 
each. If we don't fix this now, then when? My proposal on LUCENE-6247 would 
reduce this for lucene to less than 25M. I think similar improvements can be 
made to the solr artifacts.

Lucene 3.0: 42M
lucene-3.0.3.tar.gz 2010-12-01 15:06   17M  
lucene-3.0.3.zip2010-12-01 15:06   25M  

Lucene 4.0: 104M
lucene-4.0.0.tgz2013-01-15 15:13   47M
lucene-4.0.0.zip2013-01-15 15:13   57M

Lucene 5.0: 138M
lucene-5.0.0.tgz09-Feb-2015 17:50   64M
lucene-5.0.0.zip09-Feb-2015 17:50   74M

Solr 1.4: 113M
apache-solr-1.4.0.tgz   2009-11-09 20:38   54M
apache-solr-1.4.0.zip   2009-11-09 20:38   59M

Solr 3.1: 156M
apache-solr-3.1.0.tgz   2011-03-30 13:21   76M
apache-solr-3.1.0.zip   2011-03-30 13:21   80M

Solr 4.0: 210M
apache-solr-4.0.0.tgz   2013-01-15 15:13  103M
apache-solr-4.0.0.zip   2013-01-15 15:13  107M

Solr 5.0: 250M
solr-5.0.0.tgz  09-Feb-2015 17:56  122M
solr-5.0.0.zip  09-Feb-2015 17:56  128M 

edit: fix typo of lucene issue number


was (Author: rcmuir):
Here is a listing showing binary release size over time for lucene and solr, 
each. If we don't fix this now, then when? My proposal on LUCENE-6427 would 
reduce this for lucene to less than 25M. I think similar improvements can be 
made to the solr artifacts.

Lucene 3.0: 42M
lucene-3.0.3.tar.gz 2010-12-01 15:06   17M  
lucene-3.0.3.zip2010-12-01 15:06   25M  

Lucene 4.0: 104M
lucene-4.0.0.tgz2013-01-15 15:13   47M
lucene-4.0.0.zip2013-01-15 15:13   57M

Lucene 5.0: 138M
lucene-5.0.0.tgz09-Feb-2015 17:50   64M
lucene-5.0.0.zip09-Feb-2015 17:50   74M

Solr 1.4: 113M
apache-solr-1.4.0.tgz   2009-11-09 20:38   54M
apache-solr-1.4.0.zip   2009-11-09 20:38   59M

Solr 3.1: 156M
apache-solr-3.1.0.tgz   2011-03-30 13:21   76M
apache-solr-3.1.0.zip   2011-03-30 13:21   80M

Solr 4.0: 210M
apache-solr-4.0.0.tgz   2013-01-15 15:13  103M
apache-solr-4.0.0.zip   2013-01-15 15:13  107M

Solr 5.0: 250M
solr-5.0.0.tgz  09-Feb-2015 17:56  122M
solr-5.0.0.zip  09-Feb-2015 17:56  128M 

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231-part-3.patch, LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321498#comment-14321498
 ] 

Robert Muir commented on LUCENE-6231:
-

{quote}
Robert, I'll commit if you unconditionally remove your -1.
{quote}

I will remove it after people have had the chance to read what I said here, and 
read the proposed modifications on LUCENE-6247 and decide either:
1. fix for 5.0: we attack the downloads problem directly and release 5.0.
2. fix for 5.1: we commit your patch and release 5.0, but we fix download size 
for 5.1.
3. fix for 6.0: we commit your patch and 5.x stays huge and hard to download, 
but we fix download size 6.0
4. don't fix at all: Robert is crazy and half a gigabyte of artifacts is just 
fine and normal.

Seriously, if i get outvoted (i seriously hate options 3 and 4), then I will 
still drop it. I just think we need to have the discussion.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231-part-3.patch, LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the

[jira] [Commented] (SOLR-7106) Disable dynamic loading by default


[ 
https://issues.apache.org/jira/browse/SOLR-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321543#comment-14321543
 ] 

Yonik Seeley commented on SOLR-7106:


Can you explain in what sense it's a security vulnerability?  I'm not saying 
that it isn't... but understanding the exact issues we're worried about would 
be helpful.

For example, allowing read/write access to the entire index by default could 
also be considered a security vulnerability, but we're OK with that.

 Disable dynamic loading by default
 --

 Key: SOLR-7106
 URL: https://issues.apache.org/jira/browse/SOLR-7106
 Project: Solr
  Issue Type: Task
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Blocker
 Fix For: 5.0

 Attachments: SOLR-7106.patch, SOLR-7106.patch


 Dynamic loading of jars is enabled by default SOLR-6801. It is a security 
 vulnerability and we should set it to be disabled by default



--
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-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321449#comment-14321449
 ] 

Robert Muir commented on LUCENE-6231:
-

I don't agree. The huge sizes are really a problem.

If developers can't even download the release, how will users? Should we tell 
them they need a download manager? 

Seriously, is everyone so much in denial about half a gigabyte of release 
artifacts being a problem? Am I the only one that sees issues with this?

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest
 checkMaven(baseURL, tmpDir, svnRevision, version, isSigned)

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321458#comment-14321458
 ] 

Steve Rowe commented on LUCENE-6231:


Sorry, Robert, you're just plain wrong on this particular issue.

Once you've reduced the size of the downloads, devs will still have problems 
using the smoke tester to download files from people.apache.org.

Your -1 on this change requires a technical justification, and the one you've 
provided seriously doesn't cut it. 

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest
 checkMaven(baseURL, tmpDir, svnRevision, version,

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321470#comment-14321470
 ] 

Robert Muir commented on LUCENE-6231:
-

By the way: the easiest solution to me, is for us to agree that there is a 
problem, and agree that its ok to fix packaging in this way in 5.1

Solr packaging for example significantly changed in 5.0, i just know that even 
if we can get consensus there is a problem, it will be a tougher battle to 
change it in 5.1, thats why I opened a blocker issue. I don't think the entire 
5.x release series should have to suffer under this, only to fix it in 6.0

So if we can agree on this, we can commit this workaround for 5.0 and move 
on. But it is not clear to me that everyone sees a problem yet.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231-part-3.patch, LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321471#comment-14321471
 ] 

Steve Rowe commented on LUCENE-6231:


Robert, I'll commit if you unconditionally remove your -1.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231-part-3.patch, LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest
 checkMaven(baseURL, tmpDir, svnRevision, version, isSigned)
   File dev-tools/scripts/smokeTestRelease.py, line 1012, in checkMaven
 crawl(artifacts[project], artifactsURL, targetDir)
   File dev-tools/scripts/smokeTestRelease.py, line 1280, in crawl
 crawl(downloadedFiles, subURL, path,

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321491#comment-14321491
 ] 

Robert Muir commented on LUCENE-6231:
-

Here is a listing showing binary release size over time for lucene and solr, 
each. If we don't fix this now, then when? My proposal on LUCENE-6427 would 
reduce this for lucene to less than 25M. I think similar improvements can be 
made to the solr artifacts.

Lucene 3.0: 42M
lucene-3.0.3.tar.gz 2010-12-01 15:06   17M  
lucene-3.0.3.zip2010-12-01 15:06   25M  

Lucene 4.0: 104M
lucene-4.0.0.tgz2013-01-15 15:13   47M
lucene-4.0.0.zip2013-01-15 15:13   57M

Lucene 5.0: 138M
lucene-5.0.0.tgz09-Feb-2015 17:50   64M
lucene-5.0.0.zip09-Feb-2015 17:50   74M

Solr 1.4: 113M
apache-solr-1.4.0.tgz   2009-11-09 20:38   54M
apache-solr-1.4.0.zip   2009-11-09 20:38   59M

Solr 3.1: 156M
apache-solr-3.1.0.tgz   2011-03-30 13:21   76M
apache-solr-3.1.0.zip   2011-03-30 13:21   80M

Solr 4.0: 210M
apache-solr-4.0.0.tgz   2013-01-15 15:13  103M
apache-solr-4.0.0.zip   2013-01-15 15:13  107M

Solr 5.0: 250M
solr-5.0.0.tgz  09-Feb-2015 17:56  122M
solr-5.0.0.zip  09-Feb-2015 17:56  128M 

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231-part-3.patch, LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return

[jira] [Commented] (LUCENE-6245) ConstantScoreQuery etc have crazy toString()'s


[ 
https://issues.apache.org/jira/browse/LUCENE-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321492#comment-14321492
 ] 

Adrien Grand commented on LUCENE-6245:
--

OK I see the issue. I wanted to keep Filter as backward-compatible as possible 
but I had not anticipated the bad effects on toString(). Your proposal sounds 
good to me, I'll work on a fix unless you already started.

 ConstantScoreQuery etc have crazy toString()'s
 --

 Key: LUCENE-6245
 URL: https://issues.apache.org/jira/browse/LUCENE-6245
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir

 For backwards compatibility reasons, LUCENE-1518 gave Filter a default crap 
 toString(String) impl of getClass().getSimpleName(). I don't think we should 
 do this. It causes problems e.g. when filters are wrapped in 
 ConstantScoreQuery or other places, because toString(String) does the wrong 
 thing.
 {code}
 Filter f = new MultiTermQueryWrapperFilterWildcardQuery(new 
 WildcardQuery(new Term(foo, b*ar)));
 
 System.out.println(f.toString()); // foo:b*ar
 System.out.println(f.toString(foo)); // MultiTermQueryWrapperFilter
 {code}
 Instead i think that impl should be removed (leaving it abstract), and 
 Query.toString() should be final for a hard break:
 {code}
   /** Prints a query to a string, with codefield/code assumed to be the 
* default field and omitted.
*/
   public abstract String toString(String field);
   /** Prints a query to a string. */
   @Override
   public final String toString() {
 return toString();
   }
 {code}
 having buggy toString's is worse than requiring a change in custom filters. 
 It impacts all users rather than just expert ones. Also by doing this, all 
 the current toString bugs in the codebase show up as compile errors.



--
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-6245) ConstantScoreQuery etc have crazy toString()'s


[ 
https://issues.apache.org/jira/browse/LUCENE-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321536#comment-14321536
 ] 

Robert Muir commented on LUCENE-6245:
-

I think we should first fix the issue for trunk, and then think about the 
impact.

My issue here is that breaking toString() functionality silently will affect 
many many users. I am not worried about making a clean compile-time break that 
only impacts custom queries/filters code. It only impacts advanced users and 
does so without confusing them.

 ConstantScoreQuery etc have crazy toString()'s
 --

 Key: LUCENE-6245
 URL: https://issues.apache.org/jira/browse/LUCENE-6245
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir

 For backwards compatibility reasons, LUCENE-1518 gave Filter a default crap 
 toString(String) impl of getClass().getSimpleName(). I don't think we should 
 do this. It causes problems e.g. when filters are wrapped in 
 ConstantScoreQuery or other places, because toString(String) does the wrong 
 thing.
 {code}
 Filter f = new MultiTermQueryWrapperFilterWildcardQuery(new 
 WildcardQuery(new Term(foo, b*ar)));
 
 System.out.println(f.toString()); // foo:b*ar
 System.out.println(f.toString(foo)); // MultiTermQueryWrapperFilter
 {code}
 Instead i think that impl should be removed (leaving it abstract), and 
 Query.toString() should be final for a hard break:
 {code}
   /** Prints a query to a string, with codefield/code assumed to be the 
* default field and omitted.
*/
   public abstract String toString(String field);
   /** Prints a query to a string. */
   @Override
   public final String toString() {
 return toString();
   }
 {code}
 having buggy toString's is worse than requiring a change in custom filters. 
 It impacts all users rather than just expert ones. Also by doing this, all 
 the current toString bugs in the codebase show up as compile errors.



--
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-6244) Approximations on disjunctions


[ 
https://issues.apache.org/jira/browse/LUCENE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321546#comment-14321546
 ] 

Robert Muir commented on LUCENE-6244:
-

This latest patch looks nice at a glance. 

Can you explain this comment a bit more, I'm not sure I understand:
{noformat}
Because things are structured differently, I lost the feature that we confirm 
at most one clause per doc
{noformat}

Why do we pass needsScores to these disjunctions? It seems to only optimize the 
case where someone doesnt needScores but calls freq() anyway, and I don't think 
we should optimize that. DisjunctionScorer already defers all scoring/freq so I 
don't think it needs this boolean at all.

 Approximations on disjunctions
 --

 Key: LUCENE-6244
 URL: https://issues.apache.org/jira/browse/LUCENE-6244
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
 Fix For: Trunk, 5.1

 Attachments: LUCENE-6244.patch, LUCENE-6244.patch, wikibig.tasks


 Like we just did on exact phrases and conjunctions, we should also support 
 approximations on disjunctions in order to apply matches() lazily.



--
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-6247) artifacts are half a gigabyte

[
https://issues.apache.org/jira/browse/LUCENE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321419#comment-14321419
]

Robert Muir commented on LUCENE-6247:
-

Here are the calculations for current lucene branch_5x.
Instead of a 144MB binary release, it could be 24MB.

{noformat}
Current: 144,919,796 bytes

-rw-rw-r-- 1 rmuir rmuir 67144315 Feb 14 08:38 lucene-5.1.0-SNAPSHOT.tgz
-rw-rw-r-- 1 rmuir rmuir 5481 Feb 14 08:38 lucene-5.1.0-SNAPSHOT.zip

-Javadocs: 122,022,758 bytes

(this means: don't include javadocs in the binary release. they are on the
website,
and users who need a local copy can build one with 'ant javadocs')

-rw-rw-r-- 1 rmuir rmuir 60947629 Feb 14 08:42 lucene-5.1.0-SNAPSHOT.tgz
-rw-rw-r-- 1 rmuir rmuir 61075129 Feb 14 08:42 lucene-5.1.0-SNAPSHOT.zip

-Javadocs -3rdPartyJars: 48,935,497 bytes

(this means: also don't include dependent third party jars. basic usage of
lucene
like running the demos does not require them. but several advanced modules
have huge
ones. Instead we could just clearly document what versions, for people not
using
a dependency manager)

-rw-rw-r-- 1 rmuir rmuir 24405986 Feb 14 08:48 lucene-5.1.0-SNAPSHOT.tgz
-rw-rw-r-- 1 rmuir rmuir 24529511 Feb 14 08:48 lucene-5.1.0-SNAPSHOT.zip

-Javadocs -3rdPartyJars -Zip: 24,405,986 bytes

(this means: also don't include the .zip. Its totally redundant. Welcome to
2015).

-rw-rw-r-- 1 rmuir rmuir 24405986 Feb 14 08:48 lucene-5.1.0-SNAPSHOT.tgz
{noformat}

artifacts are half a gigabyte
-

Key: LUCENE-6247
URL: https://issues.apache.org/jira/browse/LUCENE-6247
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
Fix For: 5.0

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

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

[jira] [Commented] (LUCENE-6247) artifacts are half a gigabyte


[ 
https://issues.apache.org/jira/browse/LUCENE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321430#comment-14321430
 ] 

Steve Rowe commented on LUCENE-6247:


Setting an issue as a Blocker doesn't mean it holds up the release, Robert, as 
you are well aware.

Even -1'ing a release vote doesn't hold up a release, unless you can get the 
majority of voters to agree with you.

But you know this: you've been saying so for years.

 artifacts are half a gigabyte
 -

 Key: LUCENE-6247
 URL: https://issues.apache.org/jira/browse/LUCENE-6247
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
 Fix For: 5.0


 This is a growing problem and now, its spun out of control.
 The latest release artifacts are half a gigabyte. sorry, I am against adding 
 more retries to the smoke tester and continuing down the same path 
 (LUCENE-6231).
 Instead I open this blocker issue to discuss fixing this. Whenever i tried to 
 fix it before (e.g. removing zips), people complained at me what are you 
 trying to fix and wouldn't let me minimize it in the slightest.
 Now the problem is clear, we have a blocker issue to discuss it.



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

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

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321444#comment-14321444
 ] 

Robert Muir commented on LUCENE-6231:
-

-1

The size of the release is exactly what is at hand. Its half a gigabyte. Thats 
why all the retries are needed.

Please don't add more retries. This is our release, not a solr test.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest
 checkMaven(baseURL, tmpDir, svnRevision, version, isSigned)
   File dev-tools/scripts/smokeTestRelease.py, line 1012, in checkMaven
 crawl(artifacts[project], artifactsURL, targetDir)

[jira] [Commented] (LUCENE-6247) artifacts are half a gigabyte


[ 
https://issues.apache.org/jira/browse/LUCENE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321443#comment-14321443
 ] 

Robert Muir commented on LUCENE-6247:
-

Nope, I'm just opening a blocker issue. If you don't agree this is a problem, 
then feel free to ignore it, create an RC, and call a VOTE on half a gigabyte 
anyway.

But I am raising the issue and discussing the actual problem at hand here (not 
adding more retries and stuff like that to try to hack around it).

 artifacts are half a gigabyte
 -

 Key: LUCENE-6247
 URL: https://issues.apache.org/jira/browse/LUCENE-6247
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
 Fix For: 5.0


 This is a growing problem and now, its spun out of control.
 The latest release artifacts are half a gigabyte. sorry, I am against adding 
 more retries to the smoke tester and continuing down the same path 
 (LUCENE-6231).
 Instead I open this blocker issue to discuss fixing this. Whenever i tried to 
 fix it before (e.g. removing zips), people complained at me what are you 
 trying to fix and wouldn't let me minimize it in the slightest.
 Now the problem is clear, we have a blocker issue to discuss it.



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

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

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321447#comment-14321447
 ] 

Steve Rowe commented on LUCENE-6231:


bq. The size of the release is exactly what is at hand. Its half a gigabyte. 
Thats why all the retries are needed.

No, it's not.  You must have missed where I said that it's tiny files that are 
failing.  The same tiny files will be present no matter the size of the release 
packages.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest
 checkMaven(baseURL, tmpDir, svnRevision, version, isSigned)
   File

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321457#comment-14321457
 ] 

Robert Muir commented on LUCENE-6231:
-

By the way, just so you realize. I am willing to do the work to fix the 
situation.

But whenever ive tried in the past, I've only gotten complains, from people in 
denial that there is an actual problem.

Now, the problem is undeniably here, its going to impact end-users too, I can 
fix this crap within a day. It just takes bring the issue to a head and making 
a damn decision.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321465#comment-14321465
 ] 

Robert Muir commented on LUCENE-6231:
-

I do actually care. I'm just the only one who will speak up, and has the guts 
to bring the problem to a head.

half a gigabyte is seriously ridiculous here! And yeah, I'm frustrated from 
having worked to try to address this issue in the past, only to receive 
comments like what is the problem?

Like i said, its gotten to the point where its now clearly problematic. Its 
time to fix the actual problem, and not hack around it with retries in 
developer scripts that make us all pretend like it is ok.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version,

[jira] [Updated] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


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

Steve Rowe updated LUCENE-6231:
---
Attachment: LUCENE-6231-part-3.patch

Slightly modified patch that correctly identifies the retry #.

When Robert has finished holding this issue hostage for unrelated issues, we 
can put this in place.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231-part-3.patch, LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest
 checkMaven(baseURL, tmpDir, svnRevision, version, isSigned)
   File dev-tools/scripts/smokeTestRelease.py, line 1012, in checkMaven
 crawl(artifacts[project], artifactsURL, targetDir)
   File

[jira] [Commented] (LUCENE-6246) Fix DocsEnum - PostingsEnum transition

[
https://issues.apache.org/jira/browse/LUCENE-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321415#comment-14321415
]

Robert Muir commented on LUCENE-6246:
-

Thanks for reviewing. Anyone else please have a look if you have the chance.

There is a fair amount of work to do on this issue, but I will do it. I just
want to do it iteratively.

Fix DocsEnum - PostingsEnum transition
---

Key: LUCENE-6246
URL: https://issues.apache.org/jira/browse/LUCENE-6246
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Attachments: LUCENE-6246-trunk.patch

--
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-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321429#comment-14321429
 ] 

Steve Rowe commented on LUCENE-6231:


I don't know why it's suddenly become worse, but it's not the first time it's 
been a problem, for me anyway - other releases I've had to re-run the smoke 
tester because of failed downloads.  Usually it would succeed after a try or 
two.

In every single case for me, the failed downloads are tiny files, either 
{{.sha1}} or {{.md5}}.

In other words, the size of the release archives are irrelevant to this problem.

I plan on committing shortly.


 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321456#comment-14321456
 ] 

Steve Rowe commented on LUCENE-6231:


Robert, you're trying to hold hostage a reasonable improvement in dev tooling 
because you think users shouldn't have to download as many bytes.

While I don't disagree with the idea of reducing the download size, this issue 
is the wrong place.

The retries here help with a problem that has absolutely nothing to do with the 
size of the release.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest
 checkMaven(baseURL, tmpDir,

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321461#comment-14321461
 ] 

Steve Rowe commented on LUCENE-6231:


No Robert.

Once you've fixed what you deem the problem, downloading using the smoke tester 
will still have problems.

I repeat, the thing you're complaining about has zero, literally zero, impact 
on the issues my patch fixes.

Please take your objections elsewhere.


 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest
 checkMaven(baseURL, tmpDir, svnRevision, version, isSigned)
   File dev-tools/scripts/smokeTestRelease.py, line

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321462#comment-14321462
 ] 

Robert Muir commented on LUCENE-6231:
-

my -1 is here. its a veto. you don't like it, but you must live with it, even 
if you disagree with it.

Please work with me to fix the download sizes so they are manageable, and not 
half a gigabyte.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest
 checkMaven(baseURL, tmpDir, svnRevision, version, isSigned)
   File dev-tools/scripts/smokeTestRelease.py, line 1012, in checkMaven
 crawl(artifacts[project], artifactsURL,

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321463#comment-14321463
 ] 

Steve Rowe commented on LUCENE-6231:


Robert, I will not help you.

You have hijacked this issue with a bogus technical justification, and I 
sincerely believe that you know that and don't care.

I will not commit, but you're abusing the system.  Please stop the abuse.  It's 
harmful.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest
 checkMaven(baseURL, tmpDir, svnRevision, version, isSigned)
   File dev-tools/scripts/smokeTestRelease.py, line 1012, in checkMaven

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321472#comment-14321472
 ] 

Robert Muir commented on LUCENE-6231:
-

I'm not going to just let the problem be shoved under the rug and then for you 
guys to tell me, its not ok to fix the packaging in 5.1 to be smaller than half 
a gigabyte, because its too much for a minor release. 

This is important stuff impacting real users. We need to make a decision about 
it.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231-part-3.patch, LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest
 checkMaven(baseURL, tmpDir, svnRevision, version,

[jira] [Commented] (LUCENE-6245) ConstantScoreQuery etc have crazy toString()'s


[ 
https://issues.apache.org/jira/browse/LUCENE-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321550#comment-14321550
 ] 

Robert Muir commented on LUCENE-6245:
-

Besides wanting to see the change come to fruition before 6.0, I also think it 
would be great to deprecate Filter, and not just rip it out. This would be a 
much easier transition for users I think.

We can rip it out in trunk of course.

 ConstantScoreQuery etc have crazy toString()'s
 --

 Key: LUCENE-6245
 URL: https://issues.apache.org/jira/browse/LUCENE-6245
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir

 For backwards compatibility reasons, LUCENE-1518 gave Filter a default crap 
 toString(String) impl of getClass().getSimpleName(). I don't think we should 
 do this. It causes problems e.g. when filters are wrapped in 
 ConstantScoreQuery or other places, because toString(String) does the wrong 
 thing.
 {code}
 Filter f = new MultiTermQueryWrapperFilterWildcardQuery(new 
 WildcardQuery(new Term(foo, b*ar)));
 
 System.out.println(f.toString()); // foo:b*ar
 System.out.println(f.toString(foo)); // MultiTermQueryWrapperFilter
 {code}
 Instead i think that impl should be removed (leaving it abstract), and 
 Query.toString() should be final for a hard break:
 {code}
   /** Prints a query to a string, with codefield/code assumed to be the 
* default field and omitted.
*/
   public abstract String toString(String field);
   /** Prints a query to a string. */
   @Override
   public final String toString() {
 return toString();
   }
 {code}
 having buggy toString's is worse than requiring a change in custom filters. 
 It impacts all users rather than just expert ones. Also by doing this, all 
 the current toString bugs in the codebase show up as compile errors.



--
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-6247) artifacts are half a gigabyte

2015-02-14 Thread Ryan Ernst (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321585#comment-14321585
 ] 

Ryan Ernst commented on LUCENE-6247:


I'm +1 to removing javadocs from binary release.  I thought there was an issue 
for this from a while ago (after a release Robert did), but the closest I could 
find is the previous discussion on LUCENE-5589.

 artifacts are half a gigabyte
 -

 Key: LUCENE-6247
 URL: https://issues.apache.org/jira/browse/LUCENE-6247
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
 Fix For: 5.0


 This is a growing problem and now, its spun out of control.
 The latest release artifacts are half a gigabyte. sorry, I am against adding 
 more retries to the smoke tester and continuing down the same path 
 (LUCENE-6231).
 Instead I open this blocker issue to discuss fixing this. Whenever i tried to 
 fix it before (e.g. removing zips), people complained at me what are you 
 trying to fix and wouldn't let me minimize it in the slightest.
 Now the problem is clear, we have a blocker issue to discuss it.



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

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

[jira] [Commented] (LUCENE-6247) artifacts are half a gigabyte

[
https://issues.apache.org/jira/browse/LUCENE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321577#comment-14321577
]

Yonik Seeley commented on LUCENE-6247:
--

bq. I am going to repeat for the last time: We shouldnt include these tens of
thousands of files in our binary releases when they just bloat them for all
users, when most do not need it.

+1 for removing javadoc from both lucene and solr (I've been onboard with that
for years ;-)

As far as zip/tgz, I think Lucene as a developer library only needs one... but
Solr as a product should keep the zip. My heliosearch download counts have the
.zip outnumbering the .tgz... anyone know the counts for the ASF downloads?

artifacts are half a gigabyte
-

Key: LUCENE-6247
URL: https://issues.apache.org/jira/browse/LUCENE-6247
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
Fix For: 5.0

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

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

[jira] [Commented] (LUCENE-6247) artifacts are half a gigabyte

[
https://issues.apache.org/jira/browse/LUCENE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321580#comment-14321580
]

Robert Muir commented on LUCENE-6247:
-

{quote}
As far as zip/tgz, I think Lucene as a developer library only needs one... but
Solr as a product should keep the zip. My heliosearch download counts have the
.zip outnumbering the .tgz... anyone know the counts for the ASF downloads?
{quote}

I don't know this, but I want to point out one fact. Once the javadocs
situation is fixed, the size of .tgz vs .zip is essentially the same (see my
numbers above). I think thats because, once the javadocs thing is fixed, then
zips/tgzs mostly contain already-compressed jars so it does not matter, its
just a convenient packaging format.

artifacts are half a gigabyte
-

Key: LUCENE-6247
URL: https://issues.apache.org/jira/browse/LUCENE-6247
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
Fix For: 5.0

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

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

[jira] [Commented] (LUCENE-6247) artifacts are half a gigabyte


[ 
https://issues.apache.org/jira/browse/LUCENE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321579#comment-14321579
 ] 

Robert Muir commented on LUCENE-6247:
-

{quote}
We all know that 5.1 will be right around the corner, so let's get 5.0 released.
{quote}

I am completely +1 for this approach, but i have big concerns because there are 
quite a few file size issues open and no consensus anywhere. I honestly think 
it has gotten out of control, i DO NOT want to do anything risky or scary for 
5.0, i DO NOT want to hold up the release, I just want us to agree there is a 
problem, and that we will fix this change this packaging in e.g. 5.1.

As i mentioned, I do understand that solr underwent radical packaging changes 
for 5.0 already, so doing it again could cause confusion. If we must fix it for 
5.0 due to those concerns, then that's ok too. But lets please not let it drop 
like all the other issues.

 artifacts are half a gigabyte
 -

 Key: LUCENE-6247
 URL: https://issues.apache.org/jira/browse/LUCENE-6247
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
 Fix For: 5.0


 This is a growing problem and now, its spun out of control.
 The latest release artifacts are half a gigabyte. sorry, I am against adding 
 more retries to the smoke tester and continuing down the same path 
 (LUCENE-6231).
 Instead I open this blocker issue to discuss fixing this. Whenever i tried to 
 fix it before (e.g. removing zips), people complained at me what are you 
 trying to fix and wouldn't let me minimize it in the slightest.
 Now the problem is clear, we have a blocker issue to discuss it.



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

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

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads

2015-02-14 Thread Anshum Gupta (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321607#comment-14321607
 ] 

Anshum Gupta commented on LUCENE-6231:
--

My points:
# I'm +1 on this issue but an exponential back-off would be better.
# I'm also in favor of reducing the size of the download. So +1 on that! 
# Most importantly, both of the above issues are related but orthogonal and 
should be discussed in separate threads. A valid issue shouldn't become a 
blocker for another valid fix.

[~rcmuir] if you want to have the other issue about reducing the download size 
as a blocker, I'm totally fine with that but let's not hijack this valid issue 
with a good patch.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231-part-3.patch, LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321613#comment-14321613
 ] 

Yonik Seeley commented on LUCENE-6231:
--

+1 to this patch.  What should be in a download is a separate issue.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231-part-3.patch, LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' 
 '.join(c.test_args))
   File dev-tools/scripts/smokeTestRelease.py, line 1517, in smokeTest
 checkMaven(baseURL, tmpDir, svnRevision, version, isSigned)
   File dev-tools/scripts/smokeTestRelease.py, line 1012, in checkMaven
 crawl(artifacts[project], artifactsURL, targetDir)
   File dev-tools/scripts/smokeTestRelease.py, line 1280, in crawl
 crawl(downloadedFiles,

[jira] [Commented] (LUCENE-6246) Fix DocsEnum - PostingsEnum transition

2015-02-14 Thread Ryan Ernst (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321614#comment-14321614
]

Ryan Ernst commented on LUCENE-6246:

+1 The trunk patch and plan also lgtm.

Fix DocsEnum - PostingsEnum transition
---

Key: LUCENE-6246
URL: https://issues.apache.org/jira/browse/LUCENE-6246
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Attachments: LUCENE-6246-trunk.patch

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

Solr Tests On Our Jenkins Cluster Not Stable

2015-02-14 Thread Mark Miller

Tests fails on jenkins seem kind of out of control for quite a while now if
anyone has an interest.

I'll see what I can badapple or quickly fix over the next couple days.


- Mark

[jira] [Commented] (LUCENE-6244) Approximations on disjunctions


[ 
https://issues.apache.org/jira/browse/LUCENE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321632#comment-14321632
 ] 

Robert Muir commented on LUCENE-6244:
-

In the first chunk of the patch, i think we should pass false to needsScores. 
This is when we have multiple prohibited clauses and we form a disjunction of 
them. so scoring is implicitly not needed there:

{noformat}
@@ -376,10 +376,7 @@
 } else {
   float coords[] = new float[prohibited.size()+1];
   Arrays.fill(coords, 1F);
-  return new ReqExclScorer(main, 
-   new DisjunctionSumScorer(this, 
-prohibited.toArray(new 
Scorer[prohibited.size()]), 
-coords));
+  return new ReqExclScorer(main, new DisjunctionSumScorer(this, 
prohibited, coords, needsScores));
{noformat}


 Approximations on disjunctions
 --

 Key: LUCENE-6244
 URL: https://issues.apache.org/jira/browse/LUCENE-6244
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
 Fix For: Trunk, 5.1

 Attachments: LUCENE-6244.patch, LUCENE-6244.patch, wikibig.tasks


 Like we just did on exact phrases and conjunctions, we should also support 
 approximations on disjunctions in order to apply matches() lazily.



--
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-6621) SolrZkClient does not guarantee that a watch object will only be triggered once for a given notification


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

Mark Miller updated SOLR-6621:
--
Fix Version/s: (was: 5.0)
   5.1

 SolrZkClient does not guarantee that a watch object will only be triggered 
 once for a given notification
 

 Key: SOLR-6621
 URL: https://issues.apache.org/jira/browse/SOLR-6621
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: Trunk
Reporter: Renaud Delbru
Assignee: Mark Miller
 Fix For: Trunk, 5.1

 Attachments: SOLR-6621


 The SolrZkClient provides methods such as getData or exists. The problem is 
 that the client automatically wraps the provided watcher with a new watcher 
 (see 
 [here|https://github.com/apache/lucene-solr/blob/6ead83a6fafbdd6c444e2a837b09eccf34a255ef/solr/solrj/src/java/org/apache/solr/common/cloud/SolrZkClient.java#L255])
  which breaks the guarantee that a watch object, or function/context pair, 
 will only be triggered once for a given notification. This creates 
 undesirable effects when we are registering the same watch is the Watcher 
 callback method.
 A possible solution would be to introduce a SolrZkWatcher class, that will 
 take care of submitting the job to the zkCallbackExecutor. Components in 
 SolrCloud will extend this class and implement their own callback method. 
 This will ensure that the watcher object that zookeeper receives remains the 
 same.
 See SOLR-6462 for background information.



--
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-1945) Add support for child docs in DocumentObjectBinder


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

Noble Paul updated SOLR-1945:
-
Summary: Add support for child docs in DocumentObjectBinder  (was: Allow 
support for child docs in DocumentObjectBinder)

 Add support for child docs in DocumentObjectBinder
 --

 Key: SOLR-1945
 URL: https://issues.apache.org/jira/browse/SOLR-1945
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Noble Paul
Priority: Minor
 Attachments: SOLR-1945.patch, SOLR-1945.patch


 see 
 http://search.lucidimagination.com/search/document/d909d909420aeb4e/does_solrj_support_nested_annotated_beans
 Would be nice to be able to pass an object graph to solrj with @field 
 annotations rather than just a top level class



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

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

[jira] [Commented] (SOLR-7106) Disable dynamic loading by default


[ 
https://issues.apache.org/jira/browse/SOLR-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321559#comment-14321559
 ] 

Yonik Seeley commented on SOLR-7106:


bq. Bad guy could upload a JAR with a request handler that ships back 
/etc/passwd or does other malicious things.

Ah, right - stuff beyond the content of the index, which is more obvious.

 Disable dynamic loading by default
 --

 Key: SOLR-7106
 URL: https://issues.apache.org/jira/browse/SOLR-7106
 Project: Solr
  Issue Type: Task
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Blocker
 Fix For: 5.0

 Attachments: SOLR-7106.patch, SOLR-7106.patch


 Dynamic loading of jars is enabled by default SOLR-6801. It is a security 
 vulnerability and we should set it to be disabled by default



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

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

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

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

No tests ran.

Build Log:
[...truncated 37062 lines...]
-validate-maven-dependencies:
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-test-framework:6.0.0-SNAPSHOT: checking for updates 
from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-test-framework:6.0.0-SNAPSHOT: checking for updates 
from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
sonatype.releases
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-common:6.0.0-SNAPSHOT: checking for updates 
from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-common:6.0.0-SNAPSHOT: checking for updates 
from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-kuromoji:6.0.0-SNAPSHOT: checking for 
updates from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-kuromoji:6.0.0-SNAPSHOT: checking for 
updates from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-phonetic:6.0.0-SNAPSHOT: checking for 
updates from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-phonetic:6.0.0-SNAPSHOT: checking for 
updates from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-backward-codecs:6.0.0-SNAPSHOT: checking for updates 
from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-backward-codecs:6.0.0-SNAPSHOT: checking for updates 
from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-codecs:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-codecs:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-core:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-core:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-expressions:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-expressions:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-grouping:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-grouping:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-highlighter:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-highlighter:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-join:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-join:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-memory:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-memory:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-misc:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-misc:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queries:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queries:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queryparser:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queryparser:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-spatial:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-spatial:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies]

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

2015-02-14 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11638/
Java: 32bit/jdk1.7.0_76 -client -XX:+UseSerialGC

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

Error Message:
Didn't see all replicas for shard shard1 in collection1 come up within 3 
ms! ClusterState: {   collection1:{ autoAddReplicas:false, 
replicationFactor:1, router:{name:compositeId}, 
maxShardsPerNode:1, shards:{shard1:{ 
range:8000-7fff, state:active, replicas:{ 
  core_node1:{ base_url:http://127.0.0.1:45939;,   
  state:active, node_name:127.0.0.1:45939_, 
core:collection1, leader:true},   core_node2:{
 base_url:http://127.0.0.1:35933;, state:recovering, 
node_name:127.0.0.1:35933_, 
core:collection1, autoCreated:true},   control_collection:{   
  autoAddReplicas:false, replicationFactor:1, 
router:{name:compositeId}, maxShardsPerNode:1, 
shards:{shard1:{ range:8000-7fff, 
state:active, replicas:{core_node1:{ 
base_url:http://127.0.0.1:49210;, state:active, 
node_name:127.0.0.1:49210_, core:collection1, 
leader:true, autoCreated:true}}

Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in 
collection1 come up within 3 ms! ClusterState: {
  collection1:{
autoAddReplicas:false,
replicationFactor:1,
router:{name:compositeId},
maxShardsPerNode:1,
shards:{shard1:{
range:8000-7fff,
state:active,
replicas:{
  core_node1:{
base_url:http://127.0.0.1:45939;,
state:active,
node_name:127.0.0.1:45939_,
core:collection1,
leader:true},
  core_node2:{
base_url:http://127.0.0.1:35933;,
state:recovering,
node_name:127.0.0.1:35933_,
core:collection1,
autoCreated:true},
  control_collection:{
autoAddReplicas:false,
replicationFactor:1,
router:{name:compositeId},
maxShardsPerNode:1,
shards:{shard1:{
range:8000-7fff,
state:active,
replicas:{core_node1:{
base_url:http://127.0.0.1:49210;,
state:active,
node_name:127.0.0.1:49210_,
core:collection1,
leader:true,
autoCreated:true}}
at 
__randomizedtesting.SeedInfo.seed([E73CA014B7D43940:6F689FCE192854B8]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.ensureAllReplicasAreActive(AbstractFullDistribZkTestBase.java:1931)
at 
org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test(RecoveryAfterSoftCommitTest.java:102)
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 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
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

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2645 - Still Failing

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

6 tests failed.
REGRESSION:  org.apache.solr.handler.component.DistributedMLTComponentTest.test

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:37621//collection1
at 
__randomizedtesting.SeedInfo.seed([8D9956AB6AECCE42:5CD6971C410A3BA]: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.client.solrj.request.QueryRequest.process(QueryRequest.java:91)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:309)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:538)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:586)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:568)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:547)
at 
org.apache.solr.handler.component.DistributedMLTComponentTest.test(DistributedMLTComponentTest.java:126)
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 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
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

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321605#comment-14321605
 ] 

Mark Miller commented on LUCENE-6231:
-

bq. You have hijacked this issue with a bogus technical justification

+1 - jesus, what is wrong with the world.

How the heck this wasn't, cool fix this issue, cool make an issue about 
shrinking the release, cool work gets done, I don't have a clue.

Why does someone have to make every step of the way a living hell? It's 
ridiculous, and useless, and doesn't even change the outcome. This fake rage 
about not being able to make improvements is old, invalid, and annoying as shit.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231-part-3.patch, LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)
 urllib.error.URLError: urlopen error [Errno 60] Operation timed out
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1523, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in main
 smokeTest(c.java, c.url, c.revision,

[jira] [Resolved] (SOLR-7101) JmxMonitoredMap can throw an exception in clear when queryNames fails.

2015-02-14 Thread ASF subversion and git services (JIRA)


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

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

 JmxMonitoredMap can throw an exception in clear when queryNames fails.
 --

 Key: SOLR-7101
 URL: https://issues.apache.org/jira/browse/SOLR-7101
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-7101.patch


 This was added in SOLR-2927 - we should be lienant on failures here like we 
 are in other parts of this class.



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

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

Re: Solr Tests On Our Jenkins Cluster Not Stable

2015-02-14 Thread Shalin Shekhar Mangar

Hi Mark,

I'm on board. Let's see if we can fix some of these failures. Particularly
frequent are the failures from NoHttpResponseException. Do you know why?
There are other failures related to TestReplicationHandler and
TestReplicationHandlerBackup which I'll take up.

On Sat, Feb 14, 2015 at 11:46 PM, Mark Miller markrmil...@gmail.com wrote:

 Tests fails on jenkins seem kind of out of control for quite a while now
 if anyone has an interest.

 I'll see what I can badapple or quickly fix over the next couple days.


 - Mark




-- 
Regards,
Shalin Shekhar Mangar.

[jira] [Commented] (SOLR-1945) Add support for child docs in DocumentObjectBinder


[ 
https://issues.apache.org/jira/browse/SOLR-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321644#comment-14321644
 ] 

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

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

SOLR-1945: Add support for child docs in DocumentObjectBinder

 Add support for child docs in DocumentObjectBinder
 --

 Key: SOLR-1945
 URL: https://issues.apache.org/jira/browse/SOLR-1945
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Noble Paul
Priority: Minor
 Attachments: SOLR-1945.patch, SOLR-1945.patch


 see 
 http://search.lucidimagination.com/search/document/d909d909420aeb4e/does_solrj_support_nested_annotated_beans
 Would be nice to be able to pass an object graph to solrj with @field 
 annotations rather than just a top level class



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

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

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

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

7 tests failed.
REGRESSION:  
org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload

Error Message:
expected:[{indexVersion=1423929401703,generation=2,filelist=[_5in.fdt, 
_5in.fdx, _5in.fnm, _5in.nvd, _5in.nvm, _5in.si, _5in_Memory_0.ram, _5jv.fdt, 
_5jv.fdx, _5jv.fnm, _5jv.nvd, _5jv.nvm, _5jv.si, _5jv_Memory_0.ram, _5jw.cfe, 
_5jw.cfs, _5jw.si, _5jx.fdt, _5jx.fdx, _5jx.fnm, _5jx.nvd, _5jx.nvm, _5jx.si, 
_5jx_Memory_0.ram, _5jy.fdt, _5jy.fdx, _5jy.fnm, _5jy.nvd, _5jy.nvm, _5jy.si, 
_5jy_Memory_0.ram, _5jz.fdt, _5jz.fdx, _5jz.fnm, _5jz.nvd, _5jz.nvm, _5jz.si, 
_5jz_Memory_0.ram, _5k0.fdt, _5k0.fdx, _5k0.fnm, _5k0.nvd, _5k0.nvm, _5k0.si, 
_5k0_Memory_0.ram, _5k1.fdt, _5k1.fdx, _5k1.fnm, _5k1.nvd, _5k1.nvm, _5k1.si, 
_5k1_Memory_0.ram, _5k2.fdt, _5k2.fdx, _5k2.fnm, _5k2.nvd, _5k2.nvm, _5k2.si, 
_5k2_Memory_0.ram, _5k3.fdt, _5k3.fdx, _5k3.fnm, _5k3.nvd, _5k3.nvm, _5k3.si, 
_5k3_Memory_0.ram, _5k4.fdt, _5k4.fdx, _5k4.fnm, _5k4.nvd, _5k4.nvm, _5k4.si, 
_5k4_Memory_0.ram, _5k5.fdt, _5k5.fdx, _5k5.fnm, _5k5.nvd, _5k5.nvm, _5k5.si, 
_5k5_Memory_0.ram, _5k6.fdt, _5k6.fdx, _5k6.fnm, _5k6.nvd, _5k6.nvm, _5k6.si, 
_5k6_Memory_0.ram, _5k7.fdt, _5k7.fdx, _5k7.fnm, _5k7.nvd, _5k7.nvm, _5k7.si, 
_5k7_Memory_0.ram, _5k8.fdt, _5k8.fdx, _5k8.fnm, _5k8.nvd, _5k8.nvm, _5k8.si, 
_5k8_Memory_0.ram, _5k9.fdt, _5k9.fdx, _5k9.fnm, _5k9.nvd, _5k9.nvm, _5k9.si, 
_5k9_Memory_0.ram, _5ka.fdt, _5ka.fdx, _5ka.fnm, _5ka.nvd, _5ka.nvm, _5ka.si, 
_5ka_Memory_0.ram, _5kb.fdt, _5kb.fdx, _5kb.fnm, _5kb.nvd, _5kb.nvm, _5kb.si, 
_5kb_Memory_0.ram, _5kc.fdt, _5kc.fdx, _5kc.fnm, _5kc.nvd, _5kc.nvm, _5kc.si, 
_5kc_Memory_0.ram, _5kd.fdt, _5kd.fdx, _5kd.fnm, _5kd.nvd, _5kd.nvm, _5kd.si, 
_5kd_Memory_0.ram, _5ke.fdt, _5ke.fdx, _5ke.fnm, _5ke.nvd, _5ke.nvm, _5ke.si, 
_5ke_Memory_0.ram, _5kf.fdt, _5kf.fdx, _5kf.fnm, _5kf.nvd, _5kf.nvm, _5kf.si, 
_5kf_Memory_0.ram, _5kg.fdt, _5kg.fdx, _5kg.fnm, _5kg.nvd, _5kg.nvm, _5kg.si, 
_5kg_Memory_0.ram, _5ki.fdt, _5ki.fdx, _5ki.fnm, _5ki.nvd, _5ki.nvm, _5ki.si, 
_5ki_Memory_0.ram, _5kj.fdt, _5kj.fdx, _5kj.fnm, _5kj.nvd, _5kj.nvm, _5kj.si, 
_5kj_Memory_0.ram, _5kk.fdt, _5kk.fdx, _5kk.fnm, _5kk.nvd, _5kk.nvm, _5kk.si, 
_5kk_Memory_0.ram, _5kl.fdt, _5kl.fdx, _5kl.fnm, _5kl.nvd, _5kl.nvm, _5kl.si, 
_5kl_Memory_0.ram, _5km.fdt, _5km.fdx, _5km.fnm, _5km.nvd, _5km.nvm, _5km.si, 
_5km_Memory_0.ram, _5kn.fdt, _5kn.fdx, _5kn.fnm, _5kn.nvd, _5kn.nvm, _5kn.si, 
_5kn_Memory_0.ram, _5ko.fdt, _5ko.fdx, _5ko.fnm, _5ko.nvd, _5ko.nvm, _5ko.si, 
_5ko_Memory_0.ram, segments_2]}] but 
was:[{indexVersion=1423929401703,generation=3,filelist=[_5kg.fdt, _5kg.fdx, 
_5kg.fnm, _5kg.nvd, _5kg.nvm, _5kg.si, _5kg_Memory_0.ram, _5kh.fdt, _5kh.fdx, 
_5kh.fnm, _5kh.nvd, _5kh.nvm, _5kh.si, _5kh_Memory_0.ram, _5ki.fdt, _5ki.fdx, 
_5ki.fnm, _5ki.nvd, _5ki.nvm, _5ki.si, _5ki_Memory_0.ram, _5kj.fdt, _5kj.fdx, 
_5kj.fnm, _5kj.nvd, _5kj.nvm, _5kj.si, _5kj_Memory_0.ram, _5kk.fdt, _5kk.fdx, 
_5kk.fnm, _5kk.nvd, _5kk.nvm, _5kk.si, _5kk_Memory_0.ram, _5kl.fdt, _5kl.fdx, 
_5kl.fnm, _5kl.nvd, _5kl.nvm, _5kl.si, _5kl_Memory_0.ram, _5km.fdt, _5km.fdx, 
_5km.fnm, _5km.nvd, _5km.nvm, _5km.si, _5km_Memory_0.ram, _5kn.fdt, _5kn.fdx, 
_5kn.fnm, _5kn.nvd, _5kn.nvm, _5kn.si, _5kn_Memory_0.ram, _5ko.fdt, _5ko.fdx, 
_5ko.fnm, _5ko.nvd, _5ko.nvm, _5ko.si, _5ko_Memory_0.ram, segments_3]}, 
{indexVersion=1423929401703,generation=2,filelist=[_5in.fdt, _5in.fdx, 
_5in.fnm, _5in.nvd, _5in.nvm, _5in.si, _5in_Memory_0.ram, _5jv.fdt, _5jv.fdx, 
_5jv.fnm, _5jv.nvd, _5jv.nvm, _5jv.si, _5jv_Memory_0.ram, _5jw.cfe, _5jw.cfs, 
_5jw.si, _5jx.fdt, _5jx.fdx, _5jx.fnm, _5jx.nvd, _5jx.nvm, _5jx.si, 
_5jx_Memory_0.ram, _5jy.fdt, _5jy.fdx, _5jy.fnm, _5jy.nvd, _5jy.nvm, _5jy.si, 
_5jy_Memory_0.ram, _5jz.fdt, _5jz.fdx, _5jz.fnm, _5jz.nvd, _5jz.nvm, _5jz.si, 
_5jz_Memory_0.ram, _5k0.fdt, _5k0.fdx, _5k0.fnm, _5k0.nvd, _5k0.nvm, _5k0.si, 
_5k0_Memory_0.ram, _5k1.fdt, _5k1.fdx, _5k1.fnm, _5k1.nvd, _5k1.nvm, _5k1.si, 
_5k1_Memory_0.ram, _5k2.fdt, _5k2.fdx, _5k2.fnm, _5k2.nvd, _5k2.nvm, _5k2.si, 
_5k2_Memory_0.ram, _5k3.fdt, _5k3.fdx, _5k3.fnm, _5k3.nvd, _5k3.nvm, _5k3.si, 
_5k3_Memory_0.ram, _5k4.fdt, _5k4.fdx, _5k4.fnm, _5k4.nvd, _5k4.nvm, _5k4.si, 
_5k4_Memory_0.ram, _5k5.fdt, _5k5.fdx, _5k5.fnm, _5k5.nvd, _5k5.nvm, _5k5.si, 
_5k5_Memory_0.ram, _5k6.fdt, _5k6.fdx, _5k6.fnm, _5k6.nvd, _5k6.nvm, _5k6.si, 
_5k6_Memory_0.ram, _5k7.fdt, _5k7.fdx, _5k7.fnm, _5k7.nvd, _5k7.nvm, _5k7.si, 
_5k7_Memory_0.ram, _5k8.fdt, _5k8.fdx, _5k8.fnm, _5k8.nvd, _5k8.nvm, _5k8.si, 
_5k8_Memory_0.ram, _5k9.fdt, _5k9.fdx, _5k9.fnm, _5k9.nvd, _5k9.nvm, _5k9.si, 
_5k9_Memory_0.ram, _5ka.fdt, _5ka.fdx, _5ka.fnm, _5ka.nvd, _5ka.nvm, _5ka.si, 
_5ka_Memory_0.ram, _5kb.fdt, _5kb.fdx, _5kb.fnm, _5kb.nvd, _5kb.nvm, _5kb.si, 
_5kb_Memory_0.ram, _5kc.fdt, _5kc.fdx, _5kc.fnm, _5kc.nvd, _5kc.nvm, _5kc.si, 
_5kc_Memory_0.ram, _5kd.fdt, _5kd.fdx, _5kd.fnm, _5kd.nvd, _5kd.nvm, _5kd.si, 
_5kd_Memory_0.ram, _5ke.fdt, _5ke.fdx, _5ke.fnm,

[jira] [Commented] (SOLR-7106) Disable dynamic loading by default

2015-02-14 Thread Erik Hatcher (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321557#comment-14321557
 ] 

Erik Hatcher commented on SOLR-7106:


bq. Can you explain in what sense it's a security vulnerability? 

Bad guy could upload a JAR with a request handler that ships back /etc/passwd 
or does other malicious things.

 Disable dynamic loading by default
 --

 Key: SOLR-7106
 URL: https://issues.apache.org/jira/browse/SOLR-7106
 Project: Solr
  Issue Type: Task
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Blocker
 Fix For: 5.0

 Attachments: SOLR-7106.patch, SOLR-7106.patch


 Dynamic loading of jars is enabled by default SOLR-6801. It is a security 
 vulnerability and we should set it to be disabled by default



--
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-6247) artifacts are half a gigabyte

2015-02-14 Thread Erik Hatcher (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321561#comment-14321561
 ] 

Erik Hatcher commented on LUCENE-6247:
--

(from LUCENE-6231)
bq. 2. fix for 5.1: we commit your patch and release 5.0, but we fix download 
size for 5.1. 

I concur that download size is an issue and that it is worth fixing soon, but 
should not be a blocker for 5.0 at this stage.

We all know that 5.1 will be right around the corner, so let's get 5.0 released.

 artifacts are half a gigabyte
 -

 Key: LUCENE-6247
 URL: https://issues.apache.org/jira/browse/LUCENE-6247
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
 Fix For: 5.0


 This is a growing problem and now, its spun out of control.
 The latest release artifacts are half a gigabyte. sorry, I am against adding 
 more retries to the smoke tester and continuing down the same path 
 (LUCENE-6231).
 Instead I open this blocker issue to discuss fixing this. Whenever i tried to 
 fix it before (e.g. removing zips), people complained at me what are you 
 trying to fix and wouldn't let me minimize it in the slightest.
 Now the problem is clear, we have a blocker issue to discuss it.



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

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

[jira] [Commented] (LUCENE-6247) artifacts are half a gigabyte


[ 
https://issues.apache.org/jira/browse/LUCENE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321573#comment-14321573
 ] 

Shalin Shekhar Mangar commented on LUCENE-6247:
---

I agree with you Robert. The download sizes have increased too much. For 
example, why should we ship Javadocs in Solr distributions? It may make sense 
to ship solrj javadocs only but no more.

 artifacts are half a gigabyte
 -

 Key: LUCENE-6247
 URL: https://issues.apache.org/jira/browse/LUCENE-6247
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
 Fix For: 5.0


 This is a growing problem and now, its spun out of control.
 The latest release artifacts are half a gigabyte. sorry, I am against adding 
 more retries to the smoke tester and continuing down the same path 
 (LUCENE-6231).
 Instead I open this blocker issue to discuss fixing this. Whenever i tried to 
 fix it before (e.g. removing zips), people complained at me what are you 
 trying to fix and wouldn't let me minimize it in the slightest.
 Now the problem is clear, we have a blocker issue to discuss it.



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

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

[jira] [Commented] (LUCENE-6244) Approximations on disjunctions

[
https://issues.apache.org/jira/browse/LUCENE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321593#comment-14321593
]

Adrien Grand commented on LUCENE-6244:
--

bq. Can you explain this comment a bit more, I'm not sure I understand:

The first patch worked like conjunctions, the scorer first advanced the
approximation and then called nextDoc() on the approximation until it found a
document that matches. So when scores were not needed, you could just stop
calling matches() as soon as one of the clauses that are positionned on the
current doc matches. I don't think it's an important optimization but was worth
mentioning.

The new patch is different. In the priority queue, we store both a reference to
the sub scorer and its approximation. And the disjunction scorer moves to the
next doc by moving the **scorer** in the pq, while the approximation moves to
the next candidate by moving the **approximation** in the pq.

bq. Why do we pass needsScores to these disjunctions? It seems to only optimize
the case where someone doesnt needScores but calls freq() anyway.

I didn't want to optimize anything in particular, but having the freq computed
eagerly made the two-phase view a bit easier to implement. I can try to make it
lazy again.

Approximations on disjunctions
--

Key: LUCENE-6244
URL: https://issues.apache.org/jira/browse/LUCENE-6244
Project: Lucene - Core
Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Fix For: Trunk, 5.1

Attachments: LUCENE-6244.patch, LUCENE-6244.patch, wikibig.tasks

Like we just did on exact phrases and conjunctions, we should also support
approximations on disjunctions in order to apply matches() lazily.

--
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-6231) smokeTestRelease.py should retry failed downloads


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321609#comment-14321609
 ] 

Robert Muir commented on LUCENE-6231:
-

{quote}
How the heck this wasn't, cool fix this issue, cool make an issue about 
shrinking the release, cool work gets done, I don't have a clue.
{quote}

Because the issues have been opened before, no consensus is ever reached. Those 
issues just sit there doing nothing, and the file size situation gets worse and 
worse, raising the probability downloads will fail. 

If we add a download manager to smokeTestRelease.py, we are masking these 
issues. 

Honestly, I know you do not like my approach here, but if i didn't bring the 
issue to a head, nothing would get done.
There have been issues created on both lucene and solr side (LUCENE-5589, 
LUCENE-5590, SOLR-6806) but go actually read them, nothing gets done, because 
people won't admit there is even a problem.

How big do the downloads have to get before they are over the top? 

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231-part-3.patch, LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1251, in do_open
 raise URLError(err)

[jira] [Commented] (SOLR-6736) A collections-like request handler to manage solr configurations on zookeeper


[ 
https://issues.apache.org/jira/browse/SOLR-6736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321616#comment-14321616
 ] 

Mark Miller commented on SOLR-6736:
---

ZkCli is a command line tool. This is over http. A client has to be able to 
access Solr - it generally does this over http.

If I sent an xslt file to the config directory without command line access and 
trigger code, then perhaps I can get command line access. This is a problem.

 A collections-like request handler to manage solr configurations on zookeeper
 -

 Key: SOLR-6736
 URL: https://issues.apache.org/jira/browse/SOLR-6736
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud
Reporter: Varun Rajput
Assignee: Anshum Gupta
Priority: Minor
 Fix For: 5.0, Trunk

 Attachments: SOLR-6736.patch, SOLR-6736.patch


 Managing Solr configuration files on zookeeper becomes cumbersome while using 
 solr in cloud mode, especially while trying out changes in the 
 configurations. 
 It will be great if there is a request handler that can provide an API to 
 manage the configurations similar to the collections handler that would allow 
 actions like uploading new configurations, linking them to a collection, 
 deleting configurations, etc.
 example : 
 {code}
 #use the following command to upload a new configset called mynewconf. This 
 will fail if there is alredy a conf called 'mynewconf'. The file could be a 
 jar , zip or a tar file which contains all the files for the this conf.
 curl -X POST -H 'Content-Type: application/octet-stream' --data-binary 
 @testconf.zip http://localhost:8983/solr/admin/configs/mynewconf
 {code}
 A GET to http://localhost:8983/solr/admin/configs will give a list of configs 
 available
 A GET to http://localhost:8983/solr/admin/configs/mynewconf would give the 
 list of files in mynewconf



--
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-6247) artifacts are half a gigabyte

2015-02-14 Thread Anshum Gupta (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321624#comment-14321624
 ] 

Anshum Gupta commented on LUCENE-6247:
--

I'm +1 to removing javadocs from the binary release and making that and 
anything more that comes out, in 5.1.
Let's decide on that and move forward?

 artifacts are half a gigabyte
 -

 Key: LUCENE-6247
 URL: https://issues.apache.org/jira/browse/LUCENE-6247
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
 Fix For: 5.0


 This is a growing problem and now, its spun out of control.
 The latest release artifacts are half a gigabyte. sorry, I am against adding 
 more retries to the smoke tester and continuing down the same path 
 (LUCENE-6231).
 Instead I open this blocker issue to discuss fixing this. Whenever i tried to 
 fix it before (e.g. removing zips), people complained at me what are you 
 trying to fix and wouldn't let me minimize it in the slightest.
 Now the problem is clear, we have a blocker issue to discuss it.



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

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

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

2015-02-14 Thread Robert Muir

Has anyone looked into these failures with the concurrentlinkedhashmap
dependency? Its been failing for a while now, something seems to be
wrong with maven dependencies.

But it seems like it should work:
http://search.maven.org/#artifactdetails|com.googlecode.concurrentlinkedhashmap|concurrentlinkedhashmap-lru|1.2|jar


On Sat, Feb 14, 2015 at 12:11 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
 Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1351/

 No tests ran.

 Build Log:
 [...truncated 37062 lines...]
 -validate-maven-dependencies:
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-test-framework:6.0.0-SNAPSHOT: checking for updates 
 from maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-test-framework:6.0.0-SNAPSHOT: checking for updates 
 from releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
 sonatype.releases
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
 maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
 releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-analyzers-common:6.0.0-SNAPSHOT: checking for 
 updates from maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-analyzers-common:6.0.0-SNAPSHOT: checking for 
 updates from releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-analyzers-kuromoji:6.0.0-SNAPSHOT: checking for 
 updates from maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-analyzers-kuromoji:6.0.0-SNAPSHOT: checking for 
 updates from releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-analyzers-phonetic:6.0.0-SNAPSHOT: checking for 
 updates from maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-analyzers-phonetic:6.0.0-SNAPSHOT: checking for 
 updates from releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-backward-codecs:6.0.0-SNAPSHOT: checking for updates 
 from maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-backward-codecs:6.0.0-SNAPSHOT: checking for updates 
 from releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-codecs:6.0.0-SNAPSHOT: checking for updates from 
 maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-codecs:6.0.0-SNAPSHOT: checking for updates from 
 releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-core:6.0.0-SNAPSHOT: checking for updates from 
 maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-core:6.0.0-SNAPSHOT: checking for updates from 
 releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-expressions:6.0.0-SNAPSHOT: checking for updates 
 from maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-expressions:6.0.0-SNAPSHOT: checking for updates 
 from releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-grouping:6.0.0-SNAPSHOT: checking for updates from 
 maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-grouping:6.0.0-SNAPSHOT: checking for updates from 
 releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-highlighter:6.0.0-SNAPSHOT: checking for updates 
 from maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-highlighter:6.0.0-SNAPSHOT: checking for updates 
 from releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-join:6.0.0-SNAPSHOT: checking for updates from 
 maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-join:6.0.0-SNAPSHOT: checking for updates from 
 releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-memory:6.0.0-SNAPSHOT: checking for updates from 
 maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-memory:6.0.0-SNAPSHOT: checking for updates from 
 releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-misc:6.0.0-SNAPSHOT: checking for updates from 
 maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-misc:6.0.0-SNAPSHOT: checking for updates from 
 releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-queries:6.0.0-SNAPSHOT: checking for updates from 
 maven-restlet
 [artifact:dependencies] [INFO] snapshot 
 org.apache.lucene:lucene-queries:6.0.0-SNAPSHOT: checking for updates from 
 releases.cloudera.com
 [artifact:dependencies] [INFO] snapshot

[jira] [Commented] (LUCENE-6231) smokeTestRelease.py should retry failed downloads

2015-02-14 Thread Ryan Ernst (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321575#comment-14321575
 ] 

Ryan Ernst commented on LUCENE-6231:


[~steve_rowe] Regarding the patch, why not use exponential backoff? That allows 
you to start smaller, but still get the desired retries over a larger number of 
seconds.

Now with this particular issue, I think I see merits to both sides.  I have 
seen these download issues in the past (seems to be partly flakiness from the 
p.a.o servers), and they are annoying. Thankfully the apache servers that real 
releases come from are not so flaky.  But regardless of the size of whichever 
file has trouble, the more and larger files there are, the higher the 
likelihood a download issue occurs. And I think that is worth addressing, and 
not masking the issue.

So I am in favor of this patch, but I also think taking a step back and 
addressing LUCENE-6247 is important.  Users will not have these retries when 
downloading through a browser, and the larger the total download, the higher 
the chance something goes wrong.

 smokeTestRelease.py should retry failed downloads
 -

 Key: LUCENE-6231
 URL: https://issues.apache.org/jira/browse/LUCENE-6231
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 5.0, Trunk, 5.1

 Attachments: LUCENE-6231-part-2.patch, LUCENE-6231-part-3.patch, 
 LUCENE-6231-part-3.patch, LUCENE-6231.patch


 In the 5.0 RC2 vote thread, [~anshumg] mentioned that 6 attempts at running 
 the smoke tester against the people.apache.org RC URL all failed because of 
 download failures.
 I had the same problem - my first two attempts also failed because of failed 
 downloads - here's the trace from one of them:
 {noformat}
 Traceback (most recent call last):
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1248, in do_open
 h.request(req.get_method(), req.selector, req.data, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1061, in request
 self._send_request(method, url, body, headers)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1099, in _send_request
 self.endheaders(body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 1057, in endheaders
 self._send_output(message_body)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 902, in _send_output
 self.send(msg)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 840, in send
 self.connect()
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/client.py,
  line 818, in connect
 self.timeout, self.source_address)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 435, in create_connection
 raise err
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socket.py,
  line 426, in create_connection
 sock.connect(sa)
 TimeoutError: [Errno 60] Operation timed out
 During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 117, in download
 fIn = urllib.request.urlopen(urlString)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 156, in urlopen
 return opener.open(url, data, timeout)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 469, in open
 response = self._open(req, data)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 487, in _open
 '_open', req)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 447, in _call_chain
 result = func(*args)
   File 
 /Users/sarowe/homebrew/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/urllib/request.py,
  line 1268, in http_open
 return self.do_open(http.client.HTTPConnection, req)
   File

[jira] [Commented] (LUCENE-6244) Approximations on disjunctions

[
https://issues.apache.org/jira/browse/LUCENE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321618#comment-14321618
]

Robert Muir commented on LUCENE-6244:
-

{quote}
The first patch worked like conjunctions, the scorer first advanced the
approximation and then called nextDoc() on the approximation until it found a
document that matches. So when scores were not needed, you could just stop
calling matches() as soon as one of the clauses that are positionned on the
current doc matches. I don't think it's an important optimization but was worth
mentioning.
{quote}

OK, so it only impacts when scores are not needed. Thanks. I think its ok to
defer.

{quote}
I didn't want to optimize anything in particular, but having the freq computed
eagerly made the two-phase view a bit easier to implement. I can try to make it
lazy again.
{quote}

Less tricky is better. I just didnt understand the motivation. We can just add
a comment that it simplifies things to do this at the moment?

Approximations on disjunctions
--

Key: LUCENE-6244
URL: https://issues.apache.org/jira/browse/LUCENE-6244
Project: Lucene - Core
Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Fix For: Trunk, 5.1

Attachments: LUCENE-6244.patch, LUCENE-6244.patch, wikibig.tasks

Like we just did on exact phrases and conjunctions, we should also support
approximations on disjunctions in order to apply matches() lazily.

--
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-6247) artifacts are half a gigabyte

[
https://issues.apache.org/jira/browse/LUCENE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321628#comment-14321628
]

Robert Muir commented on LUCENE-6247:
-

It would be good to get opinions on the other lucene changes here. Consensus on
removing javadocs from the binary release is great, since its ~23MB we don't
need, but the other proposed changes really get the size to something
reasonable.

For example once we remove the javadocs, .zip and .tar.gz are on par size-wise,
so I propose to remove one of them. I do not care which one it is, but I don't
think having both is really helpful for lucene. The third party jars are also
very large, so we should discuss that too.

NOTE: I didn't do experiments with solr, its an app so it has more complexities
here. I am sure the packaging may need to be different there.

artifacts are half a gigabyte
-

Key: LUCENE-6247
URL: https://issues.apache.org/jira/browse/LUCENE-6247
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
Fix For: 5.0

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

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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b47) - Build # 11800 - Failure!

2015-02-14 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11800/
Java: 64bit/jdk1.9.0-ea-b47 -XX:-UseCompressedOops -XX:+UseG1GC

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

Error Message:
{   responseHeader:{ status:404, QTime:3},   error:{ 
msg:no such blob or version available: test/1, code:404}}

Stack Trace:
java.lang.AssertionError: {
  responseHeader:{
status:404,
QTime:3},
  error:{
msg:no such blob or version available: test/1,
code:404}}
at 
__randomizedtesting.SeedInfo.seed([4383C9DADFCB02F5:9BCEE48D2816A755]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:108)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
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

Re: Solr Tests On Our Jenkins Cluster Not Stable

2015-02-14 Thread Mark Miller


 On Feb 14, 2015, at 1:46 PM, Shalin Shekhar Mangar shalinman...@gmail.com 
 wrote:
 
 Particularly frequent are the failures from NoHttpResponseException. Do you 
 know why?

This used to happen, but very rarely. It was a more common in the issue where I 
took out the httpclient stale check out (not committed).

Some change by someone not long ago (jetty 9? a change from the backup issue? 
IDK) made it start failing always on Windows and more commonly on even linux 
Jenkins runs (my local checkouts have been fine).

Currently, the only thing we can do is retry on these exceptions.

In these particular tests, it’s probably happening much more easily because of 
the Jetty Proxy stuff.

It means the full update has been sent and we got no response - so we don’t 
know if the request was received or not. It can and will happen, probably 
because of the connection pool stuff, there seems to be no way to eliminate it 
entirely that I have found. But it’s rare enough we normally do not have to 
consider - for the jetty proxy tests though, we probably have to look at more 
retries (i put some in the tests that helped when I was removing the httpclient 
stale check, but it didn’t seem to help whatever is happening here now).

- Mark

http://about.me/markrmiller


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

[jira] [Commented] (SOLR-1945) Add support for child docs in DocumentObjectBinder


[ 
https://issues.apache.org/jira/browse/SOLR-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321653#comment-14321653
 ] 

Mark Miller commented on SOLR-1945:
---

+1, looks good.

 Add support for child docs in DocumentObjectBinder
 --

 Key: SOLR-1945
 URL: https://issues.apache.org/jira/browse/SOLR-1945
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Noble Paul
Priority: Minor
 Attachments: SOLR-1945.patch, SOLR-1945.patch


 see 
 http://search.lucidimagination.com/search/document/d909d909420aeb4e/does_solrj_support_nested_annotated_beans
 Would be nice to be able to pass an object graph to solrj with @field 
 annotations rather than just a top level class



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

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

[jira] [Resolved] (SOLR-1945) Add support for child docs in DocumentObjectBinder


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

Noble Paul resolved SOLR-1945.
--
   Resolution: Fixed
Fix Version/s: 5.1
   Trunk

 Add support for child docs in DocumentObjectBinder
 --

 Key: SOLR-1945
 URL: https://issues.apache.org/jira/browse/SOLR-1945
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Noble Paul
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-1945.patch, SOLR-1945.patch


 see 
 http://search.lucidimagination.com/search/document/d909d909420aeb4e/does_solrj_support_nested_annotated_beans
 Would be nice to be able to pass an object graph to solrj with @field 
 annotations rather than just a top level class



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

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

[jira] [Updated] (SOLR-7110) Optimize JavaBinCodec to minimize string Object creation


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

Noble Paul updated SOLR-7110:
-
Priority: Minor  (was: Major)

 Optimize JavaBinCodec to minimize string Object creation
 

 Key: SOLR-7110
 URL: https://issues.apache.org/jira/browse/SOLR-7110
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Minor

 In JavabinCodec we already optimize on strings creation , if they are 
 repeated in the same payload. if we use a cache it is possible to avoid 
 string creation across objects as well.



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

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

[jira] [Commented] (LUCENE-6247) artifacts are half a gigabyte


[ 
https://issues.apache.org/jira/browse/LUCENE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321697#comment-14321697
 ] 

Robert Muir commented on LUCENE-6247:
-

My comment above shows several ways to do this significantly, please look thru 
it: 
https://issues.apache.org/jira/browse/LUCENE-6247?focusedCommentId=14321419page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14321419

Consensus on javadocs isn't enough here. We need to talk about these other 
things, sorry.


 artifacts are half a gigabyte
 -

 Key: LUCENE-6247
 URL: https://issues.apache.org/jira/browse/LUCENE-6247
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
 Fix For: 5.0


 This is a growing problem and now, its spun out of control.
 The latest release artifacts are half a gigabyte. sorry, I am against adding 
 more retries to the smoke tester and continuing down the same path 
 (LUCENE-6231).
 Instead I open this blocker issue to discuss fixing this. Whenever i tried to 
 fix it before (e.g. removing zips), people complained at me what are you 
 trying to fix and wouldn't let me minimize it in the slightest.
 Now the problem is clear, we have a blocker issue to discuss it.



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

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

[jira] [Updated] (SOLR-7110) Optimize JavaBinCodec to minimize string Object creation

2015-02-14 Thread ASF subversion and git services (JIRA)


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

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

 Optimize JavaBinCodec to minimize string Object creation
 

 Key: SOLR-7110
 URL: https://issues.apache.org/jira/browse/SOLR-7110
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Minor
 Attachments: SOLR-7110.patch


 In JavabinCodec we already optimize on strings creation , if they are 
 repeated in the same payload. if we use a cache it is possible to avoid 
 string creation across objects as well.



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

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

[jira] [Commented] (LUCENE-6247) artifacts are half a gigabyte

2015-02-14 Thread Michael McCandless (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321711#comment-14321711
 ] 

Michael McCandless commented on LUCENE-6247:


+1 to remove javadocs from bin release.

+1 to remove 3rd party JARs from lucene.

+1 to build just .zip (not .tar.gz).

 artifacts are half a gigabyte
 -

 Key: LUCENE-6247
 URL: https://issues.apache.org/jira/browse/LUCENE-6247
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Priority: Blocker
 Fix For: 5.0


 This is a growing problem and now, its spun out of control.
 The latest release artifacts are half a gigabyte. sorry, I am against adding 
 more retries to the smoke tester and continuing down the same path 
 (LUCENE-6231).
 Instead I open this blocker issue to discuss fixing this. Whenever i tried to 
 fix it before (e.g. removing zips), people complained at me what are you 
 trying to fix and wouldn't let me minimize it in the slightest.
 Now the problem is clear, we have a blocker issue to discuss it.



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

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

[jira] [Commented] (SOLR-6924) TestSolrConfigHandlerCloud fails frequently.


[ 
https://issues.apache.org/jira/browse/SOLR-6924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321721#comment-14321721
 ] 

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

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

SOLR-6924: messageformat requires strings

 TestSolrConfigHandlerCloud fails frequently.
 

 Key: SOLR-6924
 URL: https://issues.apache.org/jira/browse/SOLR-6924
 Project: Solr
  Issue Type: Test
Reporter: Mark Miller
Assignee: Noble Paul

 I see this fail all the time. Usually something like:
 java.lang.AssertionError: Could not get expected value  P val for path 
 [response, params, y, p] full output {



--
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-6924) TestSolrConfigHandlerCloud fails frequently.

2015-02-14 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321724#comment-14321724
 ] 

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

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

SOLR-6924: messageformat requires strings

 TestSolrConfigHandlerCloud fails frequently.
 

 Key: SOLR-6924
 URL: https://issues.apache.org/jira/browse/SOLR-6924
 Project: Solr
  Issue Type: Test
Reporter: Mark Miller
Assignee: Noble Paul

 I see this fail all the time. Usually something like:
 java.lang.AssertionError: Could not get expected value  P val for path 
 [response, params, y, p] full output {



--
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-1945) Add support for child docs in DocumentObjectBinder

2015-02-14 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321660#comment-14321660
 ] 

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

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

SOLR-1945: Add support for child docs in DocumentObjectBinder

 Add support for child docs in DocumentObjectBinder
 --

 Key: SOLR-1945
 URL: https://issues.apache.org/jira/browse/SOLR-1945
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Noble Paul
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-1945.patch, SOLR-1945.patch


 see 
 http://search.lucidimagination.com/search/document/d909d909420aeb4e/does_solrj_support_nested_annotated_beans
 Would be nice to be able to pass an object graph to solrj with @field 
 annotations rather than just a top level class



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

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

[jira] [Commented] (SOLR-6902) Use JUnit rules instead of inheritance with distributed Solr tests to allow for multiple tests without the same class


[ 
https://issues.apache.org/jira/browse/SOLR-6902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321664#comment-14321664
 ] 

Shalin Shekhar Mangar commented on SOLR-6902:
-

This issue is incorrectly mentioned under 6.0 in the CHANGES.txt on trunk and 
under the Introduction section on branch_5x.

 Use JUnit rules instead of inheritance with distributed Solr tests to allow 
 for multiple tests without the same class
 -

 Key: SOLR-6902
 URL: https://issues.apache.org/jira/browse/SOLR-6902
 Project: Solr
  Issue Type: Improvement
  Components: Tests
Reporter: Ramkumar Aiyengar
Assignee: Erick Erickson
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-6902.patch, SOLR-6902.patch, SOLR-6902.patch, 
 SOLR-6902.patch, SOLR-6902.patch


 Finally got annoyed enough with too many things being clubbed into one test 
 method in all distributed Solr tests (anything inheriting from 
 {{BaseDistributedSearchTestCase}} and currently implementing {{doTest}})..
 This just lays the groundwork really for allowing multiple test methods 
 within the same class, and doesn't split tests as yet or flatten the 
 inheritance hierarchy (when abused for doing multiple tests), as this touches 
 a lot of files by itself. For that reason, the sooner this is picked up the 
 better..



--
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-7112) DeleteInactiveReplicaTest.deleteLiveReplicaTest test failures

2015-02-14 Thread ASF subversion and git services (JIRA)


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

Shalin Shekhar Mangar updated SOLR-7112:

Attachment: SOLR-7112.patch

DeleteInactiveReplicaTest extends AbstractFullDistribZkTestBase instead of 
DeleteReplicaTest.

 DeleteInactiveReplicaTest.deleteLiveReplicaTest test failures
 -

 Key: SOLR-7112
 URL: https://issues.apache.org/jira/browse/SOLR-7112
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 5.0
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
 Fix For: Trunk, 5.1

 Attachments: SOLR-7112.patch


 {code}
 java.lang.AssertionError: Should have had a good message here
   at 
 __randomizedtesting.SeedInfo.seed([E27AFA625D3D168A:4F1A4E694002BEFF]:0)
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.assertTrue(Assert.java:43)
   at 
 org.apache.solr.cloud.DeleteReplicaTest.deleteLiveReplicaTest(DeleteReplicaTest.java:125)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 {code}
 This fails very frequently on jenkins.



--
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-7112) DeleteInactiveReplicaTest.deleteLiveReplicaTest test failures


[ 
https://issues.apache.org/jira/browse/SOLR-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321667#comment-14321667
 ] 

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

Commit 1659850 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1659850 ]

SOLR-7112: Fix DeleteInactiveReplicaTest.deleteLiveReplicaTest test failures

 DeleteInactiveReplicaTest.deleteLiveReplicaTest test failures
 -

 Key: SOLR-7112
 URL: https://issues.apache.org/jira/browse/SOLR-7112
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 5.0
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
 Fix For: Trunk, 5.1

 Attachments: SOLR-7112.patch


 {code}
 java.lang.AssertionError: Should have had a good message here
   at 
 __randomizedtesting.SeedInfo.seed([E27AFA625D3D168A:4F1A4E694002BEFF]:0)
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.assertTrue(Assert.java:43)
   at 
 org.apache.solr.cloud.DeleteReplicaTest.deleteLiveReplicaTest(DeleteReplicaTest.java:125)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 {code}
 This fails very frequently on jenkins.



--
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-6902) Use JUnit rules instead of inheritance with distributed Solr tests to allow for multiple tests without the same class

2015-02-14 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321677#comment-14321677
 ] 

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

Commit 1659853 from sha...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1659853 ]

SOLR-6902: Move change log entry to 5.1 section

 Use JUnit rules instead of inheritance with distributed Solr tests to allow 
 for multiple tests without the same class
 -

 Key: SOLR-6902
 URL: https://issues.apache.org/jira/browse/SOLR-6902
 Project: Solr
  Issue Type: Improvement
  Components: Tests
Reporter: Ramkumar Aiyengar
Assignee: Erick Erickson
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-6902.patch, SOLR-6902.patch, SOLR-6902.patch, 
 SOLR-6902.patch, SOLR-6902.patch


 Finally got annoyed enough with too many things being clubbed into one test 
 method in all distributed Solr tests (anything inheriting from 
 {{BaseDistributedSearchTestCase}} and currently implementing {{doTest}})..
 This just lays the groundwork really for allowing multiple test methods 
 within the same class, and doesn't split tests as yet or flatten the 
 inheritance hierarchy (when abused for doing multiple tests), as this touches 
 a lot of files by itself. For that reason, the sooner this is picked up the 
 better..



--
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-6924) TestSolrConfigHandlerCloud fails frequently.


[ 
https://issues.apache.org/jira/browse/SOLR-6924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321702#comment-14321702
 ] 

Shalin Shekhar Mangar commented on SOLR-6924:
-

Another failure from my local jenkins:
{code}
 [junit4]   2 NOTE: reproduce with: ant test  
-Dtestcase=TestSolrConfigHandlerCloud -Dtests.method=test 
-Dtests.seed=59310820B646978D -Dtests.slow=true -Dtests.locale=th_TH 
-Dtests.timezone=Africa/Sao_Tome -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] FAILURE 37.5s J1 | TestSolrConfigHandlerCloud.test 
   [junit4] Throwable #1: java.lang.AssertionError: Could not get expected 
value  'b' for path 'overlay/requestHandler/\/x/a' full output: {
   [junit4]   responseHeader:{
   [junit4] status:0,
   [junit4] QTime:0},
   [junit4]   overlay:{
   [junit4] znodeVersion:0,
   [junit4] requestHandler:{/x:{
   [junit4] name:/x,
   [junit4] class:org.apache.solr.handler.DumpRequestHandler,
   [junit4] startup:lazy
   [junit4]at 
__randomizedtesting.SeedInfo.seed([59310820B646978D:D16537FA18BAFA75]:0)
   [junit4]at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:399)
   [junit4]at 
org.apache.solr.core.TestSolrConfigHandler.reqhandlertests(TestSolrConfigHandler.java:189)
   [junit4]at 
org.apache.solr.handler.TestSolrConfigHandlerCloud.testReqHandlerAPIs(TestSolrConfigHandlerCloud.java:90)
   [junit4]at 
org.apache.solr.handler.TestSolrConfigHandlerCloud.test(TestSolrConfigHandlerCloud.java:76)
{code}

The root cause seems to be the following:
{code}
   [junit4]   2 1014079 T3226 oasc.ZkController$WatcherImpl$1.run WARN 
listener throws error org.apache.solr.common.SolrException: Unable to reload 
core [collection1]
   [junit4]   2at 
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:615)
   [junit4]   2at 
org.apache.solr.core.SolrCore$11.run(SolrCore.java:2696)
   [junit4]   2at 
org.apache.solr.cloud.ZkController$WatcherImpl$1.run(ZkController.java:2294)
   [junit4]   2 Caused by: org.apache.solr.common.SolrException: Could not 
load conf for core collection1: Error loading solr config from solrconfig.xml
   [junit4]   2at 
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:66)
   [junit4]   2at 
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:608)
   [junit4]   2... 2 more
   [junit4]   2 Caused by: org.apache.solr.common.SolrException: Error loading 
solr config from solrconfig.xml
   [junit4]   2at 
org.apache.solr.core.SolrConfig.readFromResourceLoader(SolrConfig.java:167)
   [junit4]   2at 
org.apache.solr.core.ConfigSetService.createSolrConfig(ConfigSetService.java:80)
   [junit4]   2at 
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:61)
   [junit4]   2... 3 more
   [junit4]   2 Caused by: java.io.IOException: Error opening 
/configs/conf1/solrconfig.xml
   [junit4]   2at 
org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:88)
   [junit4]   2at 
org.apache.solr.core.SolrResourceLoader.openConfig(SolrResourceLoader.java:309)
   [junit4]   2at org.apache.solr.core.Config.init(Config.java:122)
   [junit4]   2at org.apache.solr.core.Config.init(Config.java:92)
   [junit4]   2at 
org.apache.solr.core.SolrConfig.init(SolrConfig.java:180)
   [junit4]   2at 
org.apache.solr.core.SolrConfig.readFromResourceLoader(SolrConfig.java:158)
   [junit4]   2... 5 more
   [junit4]   2 Caused by: 
org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = 
Session expired for /configs/conf1/solrconfig.xml
   [junit4]   2at 
org.apache.zookeeper.KeeperException.create(KeeperException.java:127)
   [junit4]   2at 
org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
   [junit4]   2at 
org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1155)
{code}

Core load/reload etc is not well tested in the face of zk session expiration I 
guess. We should add some (separate) tests for this sort of thing.

 TestSolrConfigHandlerCloud fails frequently.
 

 Key: SOLR-6924
 URL: https://issues.apache.org/jira/browse/SOLR-6924
 Project: Solr
  Issue Type: Test
Reporter: Mark Miller
Assignee: Noble Paul

 I see this fail all the time. Usually something like:
 java.lang.AssertionError: Could not get expected value  P val for path 
 [response, params, y, p] full output {



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

-
To unsubscribe, e-mail:

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2646 - Still Failing