date:20150210


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

Terry Smith commented on LUCENE-6229:
-

Like Stefan, I'm also using this functionality to access child scorers on a per 
document basis. Currently for some custom query enhancements and a custom drill 
sideways implementation.

Like Adrien, I've also had to wrap queries in a custom NonBulkScoringQuery to 
force doc-at-a-time scoring.

It'd be great to simplify this workflow as I've been calling Scorer.freq() to 
position all the child scorers (from a BooleanQuery) and as of the 5.1 nightly 
builds am needing to call Scorer.score() instead for positioning due to changes 
in MinShouldMatchSumScorer.

I'd love to have a way to not only get the child scorers but be confident that 
they were all correctly positioned.


 Remove Scorer.getChildren?
 --

 Key: LUCENE-6229
 URL: https://issues.apache.org/jira/browse/LUCENE-6229
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor

 This API is used in a single place in our code base: 
 ToParentBlockJoinCollector. In addition, the usage is a bit buggy given that 
 using this API from a collector only works if setScorer is called with an 
 actual Scorer (and not eg. FakeScorer or BooleanScorer like you would get in 
 disjunctions) so it needs a custom IndexSearcher that does not use the 
 BulkScorer API.



--
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-6229) Remove Scorer.getChildren?

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


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

Terry Smith commented on LUCENE-6229:
-

h2. freq() vs score()

I think the lazy positioning in MinShouldMatchSumScorer is misbehaving.

Drop these three methods into TestBooleanMinShouldMatch.java to see.
{code:java}
public void testMinNrShouldMatchFreq() throws Exception {
  BooleanQuery q = new BooleanQuery();
  q.add(new TermQuery(new Term(data, 1)), Occur.SHOULD);
  q.add(new TermQuery(new Term(data, 2)), Occur.SHOULD);
  q.add(new TermQuery(new Term(data, 3)), Occur.SHOULD);
  q.add(new TermQuery(new Term(id, 0)), Occur.MUST);
  q.setMinimumNumberShouldMatch(2);
  verifyNrHits(q, 1);
  s.search(q, new SimpleCollector() {
private Scorer scorer;
private CollectionScorer leafScorers;
@Override
public void setScorer(Scorer scorer) throws IOException {
  this.scorer = scorer;
  this.leafScorers = leafScorers(new ArrayListScorer(), scorer);
  assertEquals(4, leafScorers.size());
}

@Override
public void collect(int doc) throws IOException {
  assertEquals(0, doc);
  scorer.freq(); // position leaf scorers
  for (Scorer leafScorer : leafScorers) {
assertEquals(0, leafScorer.docID());
  }
}
  });
}

public void testMinNrShouldMatchScore() throws Exception {
  BooleanQuery q = new BooleanQuery();
  q.add(new TermQuery(new Term(data, 1)), Occur.SHOULD);
  q.add(new TermQuery(new Term(data, 2)), Occur.SHOULD);
  q.add(new TermQuery(new Term(data, 3)), Occur.SHOULD);
  q.add(new TermQuery(new Term(id, 0)), Occur.MUST);
  q.setMinimumNumberShouldMatch(2);
  verifyNrHits(q, 1);
  s.search(q, new SimpleCollector() {
private Scorer scorer;
private CollectionScorer leafScorers;
@Override
public void setScorer(Scorer scorer) throws IOException {
  this.scorer = scorer;
  this.leafScorers = leafScorers(new ArrayListScorer(), scorer);
  assertEquals(4, leafScorers.size());
}

@Override
public void collect(int doc) throws IOException {
  assertEquals(0, doc);
  scorer.score(); // position leaf scorers
  for (Scorer leafScorer : leafScorers) {
assertEquals(0, leafScorer.docID());
  }
}
  });
}

private static CollectionScorer leafScorers(CollectionScorer target, 
Scorer scorer) {
  CollectionChildScorer childScorers = scorer.getChildren();
  if (childScorers.isEmpty()) {
target.add(scorer);
  } else {
for (ChildScorer childScorer : childScorers) {
  leafScorers(target, childScorer.child);
}
  }
  return target;
}
{code}

Here the one that uses freq() to position the sub scorers fails but the one 
that uses score() succeeds.

h2. middle ground

I have Scorer constructors, Weight.scorer(), Weight.explain() and Collectors 
all calling Scorer.getChildren(). But when using my custom Collectors I'm 
careful to wrap the Query in a custom NonBulkScoringQuery that prevents bulk 
scoring to work around the trap. The NonBulkScoringQuery I mention is a simple 
delegating Query that allows Weight.bulkScorer() to use it's default 
implementation instead of allowing the wrapped Query to override it.

I like removing the trap for bulk scoring queries, it's really subtle and it 
took me a while to diagnose the first time I hit it.

Having a separate entry point into IndexSearcher to achieve doc-at-a-time 
scoring that supports getChildren() would be awesome. I'm not so hot on having 
to cast the collector, do you think there could be a way to preserve type 
safety here?


 Remove Scorer.getChildren?
 --

 Key: LUCENE-6229
 URL: https://issues.apache.org/jira/browse/LUCENE-6229
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor

 This API is used in a single place in our code base: 
 ToParentBlockJoinCollector. In addition, the usage is a bit buggy given that 
 using this API from a collector only works if setScorer is called with an 
 actual Scorer (and not eg. FakeScorer or BooleanScorer like you would get in 
 disjunctions) so it needs a custom IndexSearcher that does not use the 
 BulkScorer API.



--
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: [VOTE] 5.0.0 RC2

2015-02-10 Thread Adrien Grand

+1

SUCCESS! [2:20:47.907193]

On Tue, Feb 10, 2015 at 3:58 PM, Erik Hatcher erik.hatc...@gmail.com wrote:
 +1 - I ran through several examples to ensure all was working as expected.
 Ship it! :)

 Erik

 On Feb 9, 2015, at 6:16 PM, Anshum Gupta ans...@anshumgupta.net wrote:

 Please vote for the second release candidate for Lucene/Solr 5.0.0.

 The artifacts can be downloaded here:
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469

 Or you can run the smoke tester directly with this command:
 python3.2 dev-tools/scripts/smokeTestRelease.py
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469


 I could not get the above command to work as downloading some file or the
 other timed out for me (over 6 attempts) so I instead downloaded the entire
 RC as a tgz. I still have it here:

 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469.tgz

 Untar the above folder at a location of choice. Do not change the name of
 the folder as the smokeTestRelease.py extracts information from that.

 and then instead of using http, used file://. Here's the command:

 python3.2 dev-tools/scripts/smokeTestRelease.py
 file://path_to_the_extracted_folder

 and finally, here's my +1:

 SUCCESS! [0:30:50.246761]


 --
 Anshum Gupta
 http://about.me/anshumgupta





-- 
Adrien

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

[jira] [Commented] (SOLR-7094) JsonLoader error reporting fixes


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

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

Commit 1658747 from [~thelabdude] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1658747 ]

SOLR-7094: Better error reporting of JSON parse issues when indexing docs

 JsonLoader error reporting fixes
 

 Key: SOLR-7094
 URL: https://issues.apache.org/jira/browse/SOLR-7094
 Project: Solr
  Issue Type: Improvement
Reporter: Ishan Chattopadhyaya
Assignee: Timothy Potter
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-7094.patch, SOLR-7094.patch


 A misnamed __childDocuments__ attribute (wrongly to childDocuments) 
 leaves the user wondering why the document failed to be indexed because the 
 exception didn't contain the position. 
 Adding the position information to that particular exception, as well as some 
 consistency fixes to other exceptions.



--
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-6228) Do not expose full-fledged scorers in LeafCollector.setScorer

2015-02-10 Thread Ryan Ernst (JIRA)


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

Ryan Ernst commented on LUCENE-6228:


bq. another maybe more intuitive option is Scorable (interface) and keep Scorer 
as is, just implementing the interface.

I like that idea also.  I was only trying to suggest something that would have 
some larger difference in name between the two.

 Do not expose full-fledged scorers in LeafCollector.setScorer
 -

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

 Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch


 Currently LeafCollector.setScorer takes a Scorer, which I don't like because 
 several methods should never be called in the context of a Collector (like 
 nextDoc or advance).
 I think it's even more trappy for methods that might seem to work in some 
 particular cases but will not work in the general case, like getChildren 
 which will not work if you have a specialized BulkScorer or iterating over 
 positions which will not work if you are in a MultiCollector and another leaf 
 collector consumes positions too.
 So I think we should restrict what can be seen from a collector to avoid such 
 traps.



--
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-6233) CheckIndex is dog slow when checking term vectors

2015-02-10 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-6233:


This was introduced with LUCENE-5610

I'll fix the nightly Lucene benchmark to plot CheckIndex time ... we could have 
spotted this performance regression.

 CheckIndex is dog slow when checking term vectors
 -

 Key: LUCENE-6233
 URL: https://issues.apache.org/jira/browse/LUCENE-6233
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless

 I'm working on a test that creates a biggish index and I noticed the 
 CheckIndex takes a surprisingly long time to check term vectors.
 I profiled it and uncovered that we spend a lot of time (not sure this 
 explains all of it) in Terms.getMin/getMax.  Since 
 CompressingTermVectorsReader doesn't impl these methods efficiently (which is 
 fine), we fallback to super's impl, which does a digit-by-digit binary search 
 using seekCeil.
 But for TVs this sometimes results in a linear scan.
 I think CheckIndex should not check Terms.getMin/Max for TVs?



--
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-7094) JsonLoader error reporting fixes

2015-02-10 Thread Timothy Potter (JIRA)


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

Timothy Potter resolved SOLR-7094.
--
   Resolution: Fixed
Fix Version/s: Trunk
 Assignee: Timothy Potter

 JsonLoader error reporting fixes
 

 Key: SOLR-7094
 URL: https://issues.apache.org/jira/browse/SOLR-7094
 Project: Solr
  Issue Type: Improvement
Reporter: Ishan Chattopadhyaya
Assignee: Timothy Potter
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-7094.patch, SOLR-7094.patch


 A misnamed __childDocuments__ attribute (wrongly to childDocuments) 
 leaves the user wondering why the document failed to be indexed because the 
 exception didn't contain the position. 
 Adding the position information to that particular exception, as well as some 
 consistency fixes to other exceptions.



--
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-6226) Allow TermScorer to expose positions, offsets and payloads

2015-02-10 Thread Alan Woodward (JIRA)


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

Alan Woodward commented on LUCENE-6226:
---

OK, let's back up a bit.

The primary purpose of adding this functionality to Scorer is to stop needing a 
parallel Span*Query tree, and make positional queries combine with all our 
other query types more sensibly.  It would also be nice to replace the current 
span scoring implementations with something that scores lazily.

So maybe a better place to start would be to open an issue that adds a 
PositionFilterQuery that actually exercises this API?  Then we can see how 
clients interact with it, and see which changes are necessary and which are 
just me guessing about what might be needed down the road.

 Allow TermScorer to expose positions, offsets and payloads
 --

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

 Attachments: LUCENE-6226.patch, LUCENE-6226.patch, LUCENE-6226.patch, 
 LUCENE-6226.patch, LUCENE-6226.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] [Updated] (LUCENE-6228) Do not expose full-fledged scorers in LeafCollector.setScorer


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

Adrien Grand updated LUCENE-6228:
-
Attachment: LUCENE-6228.patch

Thanks Alan, I applied your suggestions: here is a new patch.

 Do not expose full-fledged scorers in LeafCollector.setScorer
 -

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

 Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch


 Currently LeafCollector.setScorer takes a Scorer, which I don't like because 
 several methods should never be called in the context of a Collector (like 
 nextDoc or advance).
 I think it's even more trappy for methods that might seem to work in some 
 particular cases but will not work in the general case, like getChildren 
 which will not work if you have a specialized BulkScorer or iterating over 
 positions which will not work if you are in a MultiCollector and another leaf 
 collector consumes positions too.
 So I think we should restrict what can be seen from a collector to avoid such 
 traps.



--
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-6226) Allow TermScorer to expose positions, offsets and payloads


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

Robert Muir commented on LUCENE-6226:
-

{quote}
 It would also be nice to replace the current span scoring implementations with 
something that scores lazily.
{quote}

What does this mean? I guess the way I see things, either you need the scoring, 
and you need all the matches... or you do not need scoring and you only care if 
the doc matches the expression or not.

Was this -1 case intended to optimize the latter? Because I think we solved 
that issues with needsScores (or needsFreqs or whatever we want to call it).

 Allow TermScorer to expose positions, offsets and payloads
 --

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

 Attachments: LUCENE-6226.patch, LUCENE-6226.patch, LUCENE-6226.patch, 
 LUCENE-6226.patch, LUCENE-6226.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-6229) Remove Scorer.getChildren?


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

Adrien Grand commented on LUCENE-6229:
--

bq. 

bq. It'd be great to simplify this workflow as I've been calling Scorer.freq() 
to position all the child scorers (from a BooleanQuery) and as of the 5.1 
nightly builds am needing to call Scorer.score() instead for positioning due to 
changes in MinShouldMatchSumScorer.

This is weird, both freq() and score() should position all sub scorers the same 
way with MinShouldMatchSumScorer. What do your query and collector look like?

 Remove Scorer.getChildren?
 --

 Key: LUCENE-6229
 URL: https://issues.apache.org/jira/browse/LUCENE-6229
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor

 This API is used in a single place in our code base: 
 ToParentBlockJoinCollector. In addition, the usage is a bit buggy given that 
 using this API from a collector only works if setScorer is called with an 
 actual Scorer (and not eg. FakeScorer or BooleanScorer like you would get in 
 disjunctions) so it needs a custom IndexSearcher that does not use the 
 BulkScorer API.



--
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=14314243#comment-14314243
 ] 

Steve Rowe commented on LUCENE-6231:


I'll commit now, including to the lucene_solr_5_0 branch.

 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
 Attachments: 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, path,

[jira] [Commented] (LUCENE-6226) Allow TermScorer to expose positions, offsets and payloads

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

Adrien Grand commented on LUCENE-6226:
--

bq. Maybe I should just switch it back to the bitset again, but change
FLAG_POSITIONS so that it doesn't require freqs

I'm not sure how much I like the bitset approach because of all possible
options that it introduces. Even if a comparable enum is less flexible, I like
the fact that it is easier to reason about and test (N options instead of N!).

bq. So if you request positions from a Scorer that doesn't support them at all,
it can just return NO_MORE_POSITIONS immediately.

This sounds error-prone to me, I would really like to have an exception instead.

Something that concerns me about PostingsFeatures.FREQS is that it is not what
most queries actually need. For instance if you want scores on a boolean query,
you don't actually need freqs on the underlying queries, but you need scores on
the other hand, so maybe the name should rather mention scores? I was thinking
that we could start with the following 3 options:
- DOCS
- DOCS_AND_FREQS_AND_SCORES
- DOCS_AND_FREQS_AND_SCORES_AND_POSITIONS

The first option is like today's needsScores=false and the second one is like
today's needsScores=true.

The way I see it, both DOCS and DOCS_AND_FREQS_AND_SCORES should never fail.
Something that is different between freqs/scores and positions is that it is
usually ok to assume a default value of 1 if scores or freqs do not really make
sense (eg. this is what ConstantScoreQuery or QueryWrapperFilter are already
doing today), but it is not the case with positions. So this third option would
raise an error if positions either do not make sense (eg. doc-values based
query), are crazy to implement (eg. MatchAll) or are not available (eg.
TermQuery and positions are not indexed).

Some examples:
- TermQuery would fail if positions are asked but not indexed
- whatever a PhraseQuery is asked, it would create sub weight with
DOCS_AND_FREQS_AND_SCORES, which would in turn fail if any of the sub queries
does not support positions
- if a constant-score query is asked for DOCS_AND_FREQS_AND_SCORES, it would
pass DOCS to the underlying query (like today with needsScores). However if it
is asked for DOCS_AND_FREQS_AND_SCORES_AND_POSITIONS then it would pass
DOCS_AND_FREQS_AND_SCORES_AND_POSITIONS to the underlying query

I did not suggest anything for offsets/payloads on purpose to reduce the scope
for now, but I don't think anything I suggest would be in the way of adding
them in the future?

Allow TermScorer to expose positions, offsets and payloads
--

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

Attachments: LUCENE-6226.patch, LUCENE-6226.patch, LUCENE-6226.patch,
LUCENE-6226.patch, LUCENE-6226.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-6232) Replace ValueSource context Map with a more concrete data type


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

Terry Smith commented on LUCENE-6232:
-

I have custom code that injects objects into this map. If you refactor this to 
be concrete class could you leave it non-final so a custom FunctionQuery could 
provide it's own subclassed instance of this context?


 Replace ValueSource context Map with a more concrete data type
 --

 Key: LUCENE-6232
 URL: https://issues.apache.org/jira/browse/LUCENE-6232
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Mike Drob

 Inspired by LUCENE-3973
 The context object used by ValueSource and friends is a raw Map that provides 
 no type safety guarantees. In our current state, there are lots of warnings 
 about unchecked casts, raw types, and generally unsafe code from the 
 compiler's perspective.
 There are several common patterns and types of Objects that we store in the 
 context. It would be beneficial to instead use a class with typed methods for 
 get/set of Scorer, Weights, etc.



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

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

[jira] [Created] (LUCENE-6233) CheckIndex is dog slow when checking term vectors

2015-02-10 Thread Michael McCandless (JIRA)

Michael McCandless created LUCENE-6233:
--

 Summary: CheckIndex is dog slow when checking term vectors
 Key: LUCENE-6233
 URL: https://issues.apache.org/jira/browse/LUCENE-6233
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless


I'm working on a test that creates a biggish index and I noticed the CheckIndex 
takes a surprisingly long time to check term vectors.

I profiled it and uncovered that we spend a lot of time (not sure this explains 
all of it) in Terms.getMin/getMax.  Since CompressingTermVectorsReader doesn't 
impl these methods efficiently (which is fine), we fallback to super's impl, 
which does a digit-by-digit binary search using seekCeil.

But for TVs this sometimes results in a linear scan.

I think CheckIndex should not check Terms.getMin/Max for TVs?



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

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

[jira] [Created] (SOLR-7095) Disaster Recovery native online cross-site replication for NRT SolrCloud

2015-02-10 Thread Hari Sekhon (JIRA)

Hari Sekhon created SOLR-7095:
-

 Summary: Disaster Recovery native online cross-site replication 
for NRT SolrCloud
 Key: SOLR-7095
 URL: https://issues.apache.org/jira/browse/SOLR-7095
 Project: Solr
  Issue Type: New Feature
Affects Versions: 4.10
Reporter: Hari Sekhon


Feature request to add native online cross-site DR support for NRT SolrCloud.

Currently NRT DR recovery requires taking down the recovering cluster including 
halting any new indexing, changing zookeeper emsembles to the other datacenter 
for one node per shard to replicate, then taking down again to switch back to 
local DC zookeeper ensemble after shard has caught up. This is a relatively 
difficult/tedious manual operation to perform and seems impossible to get 
completely up to date in scenarios with constant new update requests arriving 
during downtime of switching back to local DC's zookeeper ensemble, therefore 
preventing 100% accurate catch up.

There will be trade-offs such as making cross-site replication async to avoid 
update latency penalty, and may require a last-write-wins type scenario like 
Cassandra.

Regards,

Hari Sekhon
http://www.linkedin.com/in/harisekhon



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

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

[jira] [Comment Edited] (LUCENE-6229) Remove Scorer.getChildren?

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


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

Adrien Grand edited comment on LUCENE-6229 at 2/10/15 2:34 PM:
---

bq. It'd be great to simplify this workflow as I've been calling Scorer.freq() 
to position all the child scorers (from a BooleanQuery) and as of the 5.1 
nightly builds am needing to call Scorer.score() instead for positioning due to 
changes in MinShouldMatchSumScorer.

This is weird, both freq() and score() should position all sub scorers the same 
way with MinShouldMatchSumScorer. What do your query and collector look like?


was (Author: jpountz):
bq. 

bq. It'd be great to simplify this workflow as I've been calling Scorer.freq() 
to position all the child scorers (from a BooleanQuery) and as of the 5.1 
nightly builds am needing to call Scorer.score() instead for positioning due to 
changes in MinShouldMatchSumScorer.

This is weird, both freq() and score() should position all sub scorers the same 
way with MinShouldMatchSumScorer. What do your query and collector look like?

 Remove Scorer.getChildren?
 --

 Key: LUCENE-6229
 URL: https://issues.apache.org/jira/browse/LUCENE-6229
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor

 This API is used in a single place in our code base: 
 ToParentBlockJoinCollector. In addition, the usage is a bit buggy given that 
 using this API from a collector only works if setScorer is called with an 
 actual Scorer (and not eg. FakeScorer or BooleanScorer like you would get in 
 disjunctions) so it needs a custom IndexSearcher that does not use the 
 BulkScorer API.



--
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=14314250#comment-14314250
 ] 

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

Commit 1658725 from [~steve_rowe] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1658725 ]

LUCENE-6231: smokeTestRelease.py should retry failed downloads (merged trunk 
r1658723)

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

[jira] [Commented] (SOLR-6311) SearchHandler should use path when no qt or shard.qt parameter is specified

2015-02-10 Thread Timothy Potter (JIRA)


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

Timothy Potter commented on SOLR-6311:
--

Same issue I stumbled upon trying to fix SOLR-4479.

bq. Most of the time, other handlers were used to add default parameters.

True, but sometimes they also add search components so silently routing shard 
requests to {{/select}} is just plain wrong.

Seems like maybe the the hook to determine if the path should be applied as the 
default for {{shards.qt}} is whether there are custom components defined on 
that instance of SearchHandler? Seems a little nuanced but better for new users 
than the current experience.

 SearchHandler should use path when no qt or shard.qt parameter is specified
 ---

 Key: SOLR-6311
 URL: https://issues.apache.org/jira/browse/SOLR-6311
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.9
Reporter: Steve Molloy
 Attachments: SOLR-6311.patch


 When performing distributed searches, you have to specify shards.qt unless 
 you're on the default /select path for your handler. As this is configurable, 
 even the default search handler could be on another path. The shard requests 
 should thus default to the path if no shards.qt was specified.



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

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

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

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

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

Error Message:
expected:0 but was:1

Stack Trace:
java.lang.AssertionError: expected:0 but was:1
at 
__randomizedtesting.SeedInfo.seed([206CE36B3B21BD98:A838DCB195DDD060]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testDeleteByIdCompositeRouterWithRouterField(FullSolrCloudDistribCmdsTest.java:403)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:146)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
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

[jira] [Resolved] (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 resolved LUCENE-6231.

   Resolution: Fixed
Fix Version/s: 5.1
   Trunk
   5.0

Committed to trunk, branch_5x, and lucene_solr_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.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

[JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 237 - Failure

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

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/237/

No tests ran.

Build Log:
[...truncated 53033 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 446 files to 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
   [smoker] NOTE: output encoding is US-ASCII
   [smoker] 
   [smoker] Load release URL 
file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.1 MB in 0.01 sec (14.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.1.0-src.tgz...
   [smoker] 27.9 MB in 0.04 sec (678.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.1.0.tgz...
   [smoker] 64.1 MB in 0.10 sec (661.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.1.0.zip...
   [smoker] 73.6 MB in 0.15 sec (495.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 5653 hits for query lucene
   [smoker] checkindex with 1.7...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.1.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 5653 hits for query lucene
   [smoker] checkindex with 1.7...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.1.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run ant validate
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.jettyConnector=Socket 
-Dtests.multiplier=1 -Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 210 hits for query lucene
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.1 MB in 0.00 sec (55.1 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-5.1.0-src.tgz...
   [smoker] 35.0 MB in 0.11 sec (305.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.1.0.tgz...
   [smoker] 122.0 MB in 0.59 sec (208.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.1.0.zip...
   [smoker] 128.3 MB in 0.68 sec (188.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-5.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-5.1.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.1.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.1.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] verify WAR metadata/contained JAR identity/no javax.* or java.* 
classes...
   [smoker] unpack lucene-5.1.0.tgz...
   [smoker] copying unpacked distribution for Java 7 ...
   [smoker] test solr example w/ Java 7...
   [smoker]   start Solr instance 
(log=/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.1.0-java7/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   starting Solr on port 8983 from 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.1.0-java7
   [smoker]   startup done
   [smoker] 
   [smoker] Setup new core instance directory:
   [smoker] 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.1.0-java7/server/solr/techproducts
   [smoker] 
   [smoker] Creating new core 'techproducts' using command:
   [smoker]

[jira] [Updated] (SOLR-7097) Update other Document in DocTransformer

2015-02-10 Thread yuanyun.cn (JIRA)


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

yuanyun.cn updated SOLR-7097:
-
Summary: Update other Document in DocTransformer  (was: Able to update 
other Document in DocTransformer)

 Update other Document in DocTransformer
 ---

 Key: SOLR-7097
 URL: https://issues.apache.org/jira/browse/SOLR-7097
 Project: Solr
  Issue Type: Improvement
Reporter: yuanyun.cn
Priority: Minor
  Labels: searcher, transformers

 Solr DocTransformer is good, but it only allows us to change current 
 document: add or remove, update fields.
 It would be great if we can update other document(previous especially)  .
 User case:
 We can use flat group mode(group.main=true) to put parent and child close to 
 each other(parent first), then we can use DocTransformer to update parent 
 document when access its child document.
 Some thought about Implementation:
 org.apache.solr.response.TextResponseWriter.writeDocuments(String, 
 ResultContext, ReturnFields)
 when cachMode=true, in the for loop, after transform, we can store the 
 solrdoc in a list, write these doc at the end.
 cachMode = req.getParams().getBool(cachMode, false);
 SolrDocument[] cachedDocs = new SolrDocument[sz];
 for (int i = 0; i  sz; i++) {
  SolrDocument sdoc = toSolrDocument(doc);
  if (transformer != null) {
   transformer.transform(sdoc, id);
  }
  if(cachMode)
  {
 cachedDocs[i] = sdoc;
  }
  else{
 writeSolrDocument( null, sdoc, returnFields, i );
  }
   
 }
 if (transformer != null) {
  transformer.setContext(null);
 }
 if(cachMode) {
  for (int i = 0; i  sz; i++) {
   writeSolrDocument(null, cachedDocs[i], returnFields, i);
  }
 }
 writeEndDocumentList();



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

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

[jira] [Created] (SOLR-7098) Solr Join: Return Parent and Child Documents

2015-02-10 Thread yuanyun.cn (JIRA)

yuanyun.cn created SOLR-7098:


 Summary: Solr Join: Return Parent and Child Documents
 Key: SOLR-7098
 URL: https://issues.apache.org/jira/browse/SOLR-7098
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: yuanyun.cn
Priority: Minor
 Fix For: 5.1


Solr JoinQParserPlugin returns only right side(parent) documents, it would be 
great if we can return all documents.

User case:
If JoinQParserPlugin can return all (parent and child) documents, client can  
group parent and child docs together with same group.field - (optionally) then 
use group.main=true to navigate them.

The implementation in single mode:
(as solr join doesn't support distributed search)

req parameter: {!join from=man_id to=id includeParent=true}

Add includeParent into org.apache.solr.search.JoinQuery
Update JoinQuery's hashCode and equals to include includeParent.

In org.apache.solr.search.JoinQuery.JoinQueryWeight.getDocSet()
DocSet fromSet = fromSearcher.getDocSet(q);

if (includeParent) {
rstDocset = rstDocset.union(fromSet);
}




--
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-7019) Can't change the field key for interval faceting


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

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

Commit 1658860 from [~tomasflobbe] in branch 'dev/trunk'
[ https://svn.apache.org/r1658860 ]

SOLR-7019: Support changing field key when using interval faceting

 Can't change the field key for interval faceting
 

 Key: SOLR-7019
 URL: https://issues.apache.org/jira/browse/SOLR-7019
 Project: Solr
  Issue Type: Bug
Reporter: Tomás Fernández Löbbe
 Attachments: SOLR-7019.patch, SOLR-7019.patch


 Right now it is possible to set the key for each interval when using interval 
 faceting, but it's not possible to change the field key. For example:
 Supported: 
 {noformat}
 ...facet.interval=popularity
 facet.interval.set={!key=bad}[0,5]
 facet.interval.set={!key=good}[5,*]
 facet=true
 {noformat}
 Not Supported: 
 {noformat}
 ...facet.interval={!key=popularity}some_field
 facet.interval.set={!key=bad}[0,5]
 facet.interval.set={!key=good}[5,*]
 facet=true
 {noformat}



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

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

[jira] [Created] (SOLR-7097) Able to update other Document in DocTransformer

2015-02-10 Thread yuanyun.cn (JIRA)

yuanyun.cn created SOLR-7097:


 Summary: Able to update other Document in DocTransformer
 Key: SOLR-7097
 URL: https://issues.apache.org/jira/browse/SOLR-7097
 Project: Solr
  Issue Type: Improvement
Reporter: yuanyun.cn
Priority: Minor


Solr DocTransformer is good, but it only allows us to change current document: 
add or remove, update fields.

It would be great if we can update other document(previous especially)  .

User case:
We can use flat group mode(group.main=true) to put parent and child close to 
each other(parent first), then we can use DocTransformer to update parent 
document when access its child document.

Some thought about Implementation:
org.apache.solr.response.TextResponseWriter.writeDocuments(String, 
ResultContext, ReturnFields)
when cachMode=true, in the for loop, after transform, we can store the solrdoc 
in a list, write these doc at the end.

cachMode = req.getParams().getBool(cachMode, false);
SolrDocument[] cachedDocs = new SolrDocument[sz];
for (int i = 0; i  sz; i++) {
 SolrDocument sdoc = toSolrDocument(doc);
 if (transformer != null) {
  transformer.transform(sdoc, id);
 }
 if(cachMode)
 {
cachedDocs[i] = sdoc;
 }
 else{
writeSolrDocument( null, sdoc, returnFields, i );
 }
  
}
if (transformer != null) {
 transformer.setContext(null);
}
if(cachMode) {
 for (int i = 0; i  sz; i++) {
  writeSolrDocument(null, cachedDocs[i], returnFields, i);
 }
}
writeEndDocumentList();



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

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

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

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11776/
Java: 32bit/jdk1.9.0-ea-b47 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestSolrConfigHandlerCloud.test

Error Message:
Could not get expected value  'P val' for path 'response/params/y/p' full 
output: {   responseHeader:{ status:0, QTime:0},   response:{   
  znodeVersion:2, params:{   x:{ a:A val, 
b:B val, :{v:0}},   y:{ c:CY val modified,
 b:BY val, i:20, d:[   val 1,   
val 2], e:EY val, :{v:0}

Stack Trace:
java.lang.AssertionError: Could not get expected value  'P val' for path 
'response/params/y/p' full output: {
  responseHeader:{
status:0,
QTime:0},
  response:{
znodeVersion:2,
params:{
  x:{
a:A val,
b:B val,
:{v:0}},
  y:{
c:CY val modified,
b:BY val,
i:20,
d:[
  val 1,
  val 2],
e:EY val,
:{v:0}
at 
__randomizedtesting.SeedInfo.seed([4721185DBF0334B0:CF75278711FF5948]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:399)
at 
org.apache.solr.handler.TestSolrConfigHandlerCloud.testReqParams(TestSolrConfigHandlerCloud.java:244)
at 
org.apache.solr.handler.TestSolrConfigHandlerCloud.test(TestSolrConfigHandlerCloud.java:77)
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

Re: Is the Solr CodecFactory doc a bit off-kilter?

2015-02-10 Thread Shawn Heisey

On 2/10/2015 3:23 PM, Benson Margulies wrote:
 http://wiki.apache.org/solr/SimpleTextCodecExample

 Why does it have:

 codecFactory name=CodecFactory class=solr.SchemaCodecFactory /

 and then:

 postingsFormat=SimpleText

 Shouldn't the postingFormat match the codec factory name? For that
 matter, how much of this is obsolete? Is there better doc elsewhere or
 does this need help?

If I am wrong about this, then I can plead ignorance, but from what I
can see, I don't think that the codecFactory and postingsFormat should
match.  A codecFactory seems to be designed to select and manipulate the
Lucene codec that ultimately gets used for the index, while
postingsFormat looks like it's only one small part of a Lucene codec
definition -- and one of the things that can be manipulated by the
codecFactory.

The code in SchemaCodecFactory is very short and deceptively simple,
leveraging a great deal of functionality from other classes.  If I'm
reading it right, that class is required in order for the postingsFormat
and docValuesFormat options in the schema to actually take effect.  If
that codecFactory is not explicitly specified in the schema, those
configs would probably be ignored.

Thanks,
Shawn


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

Re: Is the Solr CodecFactory doc a bit off-kilter?

2015-02-10 Thread Jack Krupansky

The Solr codec factory simply uses the Solr schema to fetch the desired
postings format name., because Lucene knows nothing about the Solr schema.
That postings format name is the name of a Lucene-level codec.

The name attribute of the codecFactory element is simply ignored. In
fact, the example solrconfig codecFactory element simply describes the
default codec factory for Solr and is unneeded - it's simply there for
documentation, and in case some advanced expert user wanted to override it.

-- Jack Krupansky

On Tue, Feb 10, 2015 at 8:54 PM, Shawn Heisey apa...@elyograg.org wrote:

 On 2/10/2015 3:23 PM, Benson Margulies wrote:
  http://wiki.apache.org/solr/SimpleTextCodecExample
 
  Why does it have:
 
  codecFactory name=CodecFactory class=solr.SchemaCodecFactory /
 
  and then:
 
  postingsFormat=SimpleText
 
  Shouldn't the postingFormat match the codec factory name? For that
  matter, how much of this is obsolete? Is there better doc elsewhere or
  does this need help?

 If I am wrong about this, then I can plead ignorance, but from what I
 can see, I don't think that the codecFactory and postingsFormat should
 match.  A codecFactory seems to be designed to select and manipulate the
 Lucene codec that ultimately gets used for the index, while
 postingsFormat looks like it's only one small part of a Lucene codec
 definition -- and one of the things that can be manipulated by the
 codecFactory.

 The code in SchemaCodecFactory is very short and deceptively simple,
 leveraging a great deal of functionality from other classes.  If I'm
 reading it right, that class is required in order for the postingsFormat
 and docValuesFormat options in the schema to actually take effect.  If
 that codecFactory is not explicitly specified in the schema, those
 configs would probably be ignored.

 Thanks,
 Shawn


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

Re: Is the Solr CodecFactory doc a bit off-kilter?

2015-02-10 Thread Shawn Heisey

On 2/10/2015 7:23 PM, Jack Krupansky wrote:
 The Solr codec factory simply uses the Solr schema to fetch the desired
 postings format name., because Lucene knows nothing about the Solr
 schema. That postings format name is the name of a Lucene-level codec.
 
 The name attribute of the codecFactory element is simply ignored. In
 fact, the example solrconfig codecFactory element simply describes the
 default codec factory for Solr and is unneeded - it's simply there for
 documentation, and in case some advanced expert user wanted to override it.

From what I saw in the branch_5x code (this excerpt is from
SolrCore.java), if you don't explicitly choose a factory in your schema,
then you'll get a very simple anonymous factory class which simply
provides the default codec:

} else {
  factory = new CodecFactory() {
@Override
public Codec getCodec() {
  return Codec.getDefault();
}
  };
}

This means that if you want postingsFormat and docValuesFormat to
actually work, you must explicity define the codecFactory in schema.xml
to use solr.SchemaCodecFactory, or possibly a custom class that extends
SchemaCodecFactory.

The code *immediately* after what I quoted above checks whether the
factory implements SolrCoreAware.  If the factory doesn't implement
SolrCoreAware, which would include the anonymous class in the code
above, any postingsFormat or docValuesFormat attributes in the schema
will result in an exception.

Completely unrelated, but interesting to me:  A custom CodecFactory
descended from SchemaCodecFactory could maybe be used to turn off stored
field compression for users in unusual situtations.  Any hints from
Lucene folks on how to modify the codec to disable compression would be
appreciated.

Thanks,
Shawn


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

Re: [VOTE] 5.0.0 RC2

2015-02-10 Thread Michael McCandless

+1

SUCCESS! [0:38:50.050201]

Is this output normal/OK?  I assume it's just extra verbosity?

Creating new core 'techproducts' using command:
http://localhost:8983/solr/admin/cores?action=CREATEname=techproductsinstanceDir=techproducts

{
  responseHeader:{
status:0,
QTime:838},
  core:techproducts}

Mike McCandless

http://blog.mikemccandless.com


On Tue, Feb 10, 2015 at 10:45 AM, Adrien Grand jpou...@gmail.com wrote:
 +1

 SUCCESS! [2:20:47.907193]

 On Tue, Feb 10, 2015 at 3:58 PM, Erik Hatcher erik.hatc...@gmail.com wrote:
 +1 - I ran through several examples to ensure all was working as expected.
 Ship it! :)

 Erik

 On Feb 9, 2015, at 6:16 PM, Anshum Gupta ans...@anshumgupta.net wrote:

 Please vote for the second release candidate for Lucene/Solr 5.0.0.

 The artifacts can be downloaded here:
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469

 Or you can run the smoke tester directly with this command:
 python3.2 dev-tools/scripts/smokeTestRelease.py
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469


 I could not get the above command to work as downloading some file or the
 other timed out for me (over 6 attempts) so I instead downloaded the entire
 RC as a tgz. I still have it here:

 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469.tgz

 Untar the above folder at a location of choice. Do not change the name of
 the folder as the smokeTestRelease.py extracts information from that.

 and then instead of using http, used file://. Here's the command:

 python3.2 dev-tools/scripts/smokeTestRelease.py
 file://path_to_the_extracted_folder

 and finally, here's my +1:

 SUCCESS! [0:30:50.246761]


 --
 Anshum Gupta
 http://about.me/anshumgupta





 --
 Adrien

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


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

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

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

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

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

Error Message:
expected:[{indexVersion=1423583446269,generation=2,filelist=[_5v.fdt, _5v.fdx, 
_5v.fnm, _5v.nvd, _5v.nvm, _5v.si, _5v_LuceneFixedGap_0.doc, 
_5v_LuceneFixedGap_0.tib, _5v_LuceneFixedGap_0.tii, _6a.cfe, _6a.cfs, _6a.si, 
_6o.fdt, _6o.fdx, _6o.fnm, _6o.nvd, _6o.nvm, _6o.si, _6o_LuceneFixedGap_0.doc, 
_6o_LuceneFixedGap_0.tib, _6o_LuceneFixedGap_0.tii, _6p.cfe, _6p.cfs, _6p.si, 
_6q.fdt, _6q.fdx, _6q.fnm, _6q.nvd, _6q.nvm, _6q.si, _6q_LuceneFixedGap_0.doc, 
_6q_LuceneFixedGap_0.tib, _6q_LuceneFixedGap_0.tii, _6r.fdt, _6r.fdx, _6r.fnm, 
_6r.nvd, _6r.nvm, _6r.si, _6r_LuceneFixedGap_0.doc, _6r_LuceneFixedGap_0.tib, 
_6r_LuceneFixedGap_0.tii, _6s.fdt, _6s.fdx, _6s.fnm, _6s.nvd, _6s.nvm, _6s.si, 
_6s_LuceneFixedGap_0.doc, _6s_LuceneFixedGap_0.tib, _6s_LuceneFixedGap_0.tii, 
_6t.fdt, _6t.fdx, _6t.fnm, _6t.nvd, _6t.nvm, _6t.si, _6t_LuceneFixedGap_0.doc, 
_6t_LuceneFixedGap_0.tib, _6t_LuceneFixedGap_0.tii, _6u.fdt, _6u.fdx, _6u.fnm, 
_6u.nvd, _6u.nvm, _6u.si, _6u_LuceneFixedGap_0.doc, _6u_LuceneFixedGap_0.tib, 
_6u_LuceneFixedGap_0.tii, _6v.fdt, _6v.fdx, _6v.fnm, _6v.nvd, _6v.nvm, _6v.si, 
_6v_LuceneFixedGap_0.doc, _6v_LuceneFixedGap_0.tib, _6v_LuceneFixedGap_0.tii, 
_6w.fdt, _6w.fdx, _6w.fnm, _6w.nvd, _6w.nvm, _6w.si, _6w_LuceneFixedGap_0.doc, 
_6w_LuceneFixedGap_0.tib, _6w_LuceneFixedGap_0.tii, _6x.fdt, _6x.fdx, _6x.fnm, 
_6x.nvd, _6x.nvm, _6x.si, _6x_LuceneFixedGap_0.doc, _6x_LuceneFixedGap_0.tib, 
_6x_LuceneFixedGap_0.tii, _6y.fdt, _6y.fdx, _6y.fnm, _6y.nvd, _6y.nvm, _6y.si, 
_6y_LuceneFixedGap_0.doc, _6y_LuceneFixedGap_0.tib, _6y_LuceneFixedGap_0.tii, 
_6z.fdt, _6z.fdx, _6z.fnm, _6z.nvd, _6z.nvm, _6z.si, _6z_LuceneFixedGap_0.doc, 
_6z_LuceneFixedGap_0.tib, _6z_LuceneFixedGap_0.tii, _70.fdt, _70.fdx, _70.fnm, 
_70.nvd, _70.nvm, _70.si, _70_LuceneFixedGap_0.doc, _70_LuceneFixedGap_0.tib, 
_70_LuceneFixedGap_0.tii, _71.fdt, _71.fdx, _71.fnm, _71.nvd, _71.nvm, _71.si, 
_71_LuceneFixedGap_0.doc, _71_LuceneFixedGap_0.tib, _71_LuceneFixedGap_0.tii, 
_72.fdt, _72.fdx, _72.fnm, _72.nvd, _72.nvm, _72.si, _72_LuceneFixedGap_0.doc, 
_72_LuceneFixedGap_0.tib, _72_LuceneFixedGap_0.tii, segments_2]}] but 
was:[{indexVersion=1423583446269,generation=3,filelist=[_5v.fdt, _5v.fdx, 
_5v.fnm, _5v.nvd, _5v.nvm, _5v.si, _5v_LuceneFixedGap_0.doc, 
_5v_LuceneFixedGap_0.tib, _5v_LuceneFixedGap_0.tii, _6a.cfe, _6a.cfs, _6a.si, 
_6p.cfe, _6p.cfs, _6p.si, _73.cfe, _73.cfs, _73.si, segments_3]}, 
{indexVersion=1423583446269,generation=2,filelist=[_5v.fdt, _5v.fdx, _5v.fnm, 
_5v.nvd, _5v.nvm, _5v.si, _5v_LuceneFixedGap_0.doc, _5v_LuceneFixedGap_0.tib, 
_5v_LuceneFixedGap_0.tii, _6a.cfe, _6a.cfs, _6a.si, _6o.fdt, _6o.fdx, _6o.fnm, 
_6o.nvd, _6o.nvm, _6o.si, _6o_LuceneFixedGap_0.doc, _6o_LuceneFixedGap_0.tib, 
_6o_LuceneFixedGap_0.tii, _6p.cfe, _6p.cfs, _6p.si, _6q.fdt, _6q.fdx, _6q.fnm, 
_6q.nvd, _6q.nvm, _6q.si, _6q_LuceneFixedGap_0.doc, _6q_LuceneFixedGap_0.tib, 
_6q_LuceneFixedGap_0.tii, _6r.fdt, _6r.fdx, _6r.fnm, _6r.nvd, _6r.nvm, _6r.si, 
_6r_LuceneFixedGap_0.doc, _6r_LuceneFixedGap_0.tib, _6r_LuceneFixedGap_0.tii, 
_6s.fdt, _6s.fdx, _6s.fnm, _6s.nvd, _6s.nvm, _6s.si, _6s_LuceneFixedGap_0.doc, 
_6s_LuceneFixedGap_0.tib, _6s_LuceneFixedGap_0.tii, _6t.fdt, _6t.fdx, _6t.fnm, 
_6t.nvd, _6t.nvm, _6t.si, _6t_LuceneFixedGap_0.doc, _6t_LuceneFixedGap_0.tib, 
_6t_LuceneFixedGap_0.tii, _6u.fdt, _6u.fdx, _6u.fnm, _6u.nvd, _6u.nvm, _6u.si, 
_6u_LuceneFixedGap_0.doc, _6u_LuceneFixedGap_0.tib, _6u_LuceneFixedGap_0.tii, 
_6v.fdt, _6v.fdx, _6v.fnm, _6v.nvd, _6v.nvm, _6v.si, _6v_LuceneFixedGap_0.doc, 
_6v_LuceneFixedGap_0.tib, _6v_LuceneFixedGap_0.tii, _6w.fdt, _6w.fdx, _6w.fnm, 
_6w.nvd, _6w.nvm, _6w.si, _6w_LuceneFixedGap_0.doc, _6w_LuceneFixedGap_0.tib, 
_6w_LuceneFixedGap_0.tii, _6x.fdt, _6x.fdx, _6x.fnm, _6x.nvd, _6x.nvm, _6x.si, 
_6x_LuceneFixedGap_0.doc, _6x_LuceneFixedGap_0.tib, _6x_LuceneFixedGap_0.tii, 
_6y.fdt, _6y.fdx, _6y.fnm, _6y.nvd, _6y.nvm, _6y.si, _6y_LuceneFixedGap_0.doc, 
_6y_LuceneFixedGap_0.tib, _6y_LuceneFixedGap_0.tii, _6z.fdt, _6z.fdx, _6z.fnm, 
_6z.nvd, _6z.nvm, _6z.si, _6z_LuceneFixedGap_0.doc, _6z_LuceneFixedGap_0.tib, 
_6z_LuceneFixedGap_0.tii, _70.fdt, _70.fdx, _70.fnm, _70.nvd, _70.nvm, _70.si, 
_70_LuceneFixedGap_0.doc, _70_LuceneFixedGap_0.tib, _70_LuceneFixedGap_0.tii, 
_71.fdt, _71.fdx, _71.fnm, _71.nvd, _71.nvm, _71.si, _71_LuceneFixedGap_0.doc, 
_71_LuceneFixedGap_0.tib, _71_LuceneFixedGap_0.tii, _72.fdt, _72.fdx, _72.fnm, 
_72.nvd, _72.nvm, _72.si, _72_LuceneFixedGap_0.doc, _72_LuceneFixedGap_0.tib, 
_72_LuceneFixedGap_0.tii, segments_2]}]

Stack Trace:
java.lang.AssertionError: 
expected:[{indexVersion=1423583446269,generation=2,filelist=[_5v.fdt, _5v.fdx, 
_5v.fnm, _5v.nvd, _5v.nvm, _5v.si, _5v_LuceneFixedGap_0.doc, 
_5v_LuceneFixedGap_0.tib, _5v_LuceneFixedGap_0.tii, _6a.cfe, _6a.cfs, _6a.si, 
_6o.fdt, _6o.fdx, _6o.fnm,

[jira] [Updated] (SOLR-6398) Add IterativeMergeStrategy to support Parallel Iterative Algorithms

2015-02-10 Thread Joel Bernstein (JIRA)


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

Joel Bernstein updated SOLR-6398:
-
Description: 
This ticket builds on the existing AnalyticsQuery / MergeStrategy framework by 
adding the abstract class IterativeMergeStrategy,  which has built-in support 
for call-backs to the shards. By extending this class you can plugin Parallel 
iterative Algorithms, such as Gradient Descent, that will run efficiently 
inside Solr. 




  was:
The main inspiration for this ticket came from this presentation:

http://www.slideshare.net/jpatanooga/hadoop-summit-eu-2013-parallel-linear-regression-iterativereduce-and-yarn

This ticket builds on the existing AnalyticsQuery / MergeStrategy framework by 
adding the abstract class IterativeMergeStrategy,  which has built-in support 
for call-backs to the shards. By extending this class you can plugin parallel 
iterative algorithms that will run efficiently inside Solr.

I will update this ticket with more information about the design soon.




 Add IterativeMergeStrategy to support Parallel Iterative Algorithms
 ---

 Key: SOLR-6398
 URL: https://issues.apache.org/jira/browse/SOLR-6398
 Project: Solr
  Issue Type: Improvement
Reporter: Joel Bernstein
Priority: Minor
 Attachments: SOLR-6398.patch, SOLR-6398.patch, SOLR-6398.patch


 This ticket builds on the existing AnalyticsQuery / MergeStrategy framework 
 by adding the abstract class IterativeMergeStrategy,  which has built-in 
 support for call-backs to the shards. By extending this class you can plugin 
 Parallel iterative Algorithms, such as Gradient Descent, that will run 
 efficiently inside Solr. 



--
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-6227) Add BooleanClause.Occur.FILTER


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

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

Commit 1658769 from [~jpountz] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1658769 ]

LUCENE-6227: Add BooleanClause.Occur.FILTER.

 Add BooleanClause.Occur.FILTER
 --

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

 Attachments: LUCENE-6227.patch, LUCENE-6227.patch, LUCENE-6227.patch, 
 LUCENE-6227.patch, LUCENE-6227.patch


 Now that we have weight-level control of whether scoring is needed or not, we 
 could add a new clause type to BooleanQuery. It would behave like MUST exept 
 that it would not participate in scoring.
 Why do we need it given that we already have FilteredQuery? The idea is that 
 by having a single query that performs conjunctions, we could potentially 
 take better decisions. It's not ready to replace FilteredQuery yet as 
 FilteredQuery has handling of random-access filters that BooleanQuery 
 doesn't, but it's a first step towards that direction and eventually 
 FilteredQuery would just rewrite to a BooleanQuery.
 I've been calling this new clause type FILTER so far, but feel free to 
 propose a better name.



--
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: [VOTE] 5.0.0 RC2

2015-02-10 Thread Chris Hostetter


: That part of the script expects you run from the root of a checkout.  It
: runs the backcompat tests, and scrapes the test output to check all are
: tested.

Everything you said made sense, and i even filed LUCENE-6234 to note that 
we should improve the behavior -- and yet even when i run smokeTester from 
the root of my lucene_solr_5_0 checkout, i get the same error...




hossman@frisbee:~/lucene/branch_5_0$ svn update
Udev-tools/scripts/smokeTestRelease.py
 U   dev-tools
 U   .
Updated to revision 1658755.
hossman@frisbee:~/lucene/branch_5_0$ python3.2 
dev-tools/scripts/smokeTestRelease.py 
http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469
Java 1.7 JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/
NOTE: output encoding is UTF-8

Load release URL 
http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469;...
  unshortened: 
http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469/

Test Lucene...
  test basics...
  get KEYS
0.1 MB in 0.64 sec (0.2 MB/sec)
  check changes HTML...
  download lucene-5.0.0-src.tgz...
27.9 MB in 5.13 sec (5.4 MB/sec)
verify md5/sha1 digests
verify sig
verify trust
  GPG: gpg: WARNING: This key is not certified with a trusted 
signature!
  download lucene-5.0.0.tgz...
64.0 MB in 29.27 sec (2.2 MB/sec)
verify md5/sha1 digests
verify sig
verify trust
  GPG: gpg: WARNING: This key is not certified with a trusted 
signature!
  download lucene-5.0.0.zip...
73.5 MB in 22.35 sec (3.3 MB/sec)
verify md5/sha1 digests
verify sig
verify trust
  GPG: gpg: WARNING: This key is not certified with a trusted 
signature!
  unpack lucene-5.0.0.tgz...
verify JAR metadata/identity/no javax.* or java.* classes...
test demo with 1.7...
  got 5647 hits for query lucene
checkindex with 1.7...
check Lucene's javadoc JAR
  unpack lucene-5.0.0.zip...
verify JAR metadata/identity/no javax.* or java.* classes...
test demo with 1.7...
  got 5647 hits for query lucene
checkindex with 1.7...
check Lucene's javadoc JAR
  unpack lucene-5.0.0-src.tgz...
make sure no JARs/WARs in src dist...
run ant validate
run tests w/ Java 7 and testArgs=''...
test demo with 1.7...
  got 210 hits for query lucene
checkindex with 1.7...
generate javadocs w/ Java 7...

Crawl/parse...

Verify...
  confirm all releases have coverage in TestBackwardsCompatibility
find all past Lucene releases...
run TestBackwardsCompatibility..
Releases that don't seem to be tested:
  2.0.0
  2.1.0
  2.2.0
  2.3.0
  2.4.0
  2.4.1
  2.9.0
  2.9.1
  2.9.2
  2.9.3
  2.9.4
  3.0.0
  3.0.1
  3.0.2
  3.0.3
  3.1.0
  3.2.0
  3.3.0
  3.4.0
  3.5.0
  3.6.0
  3.6.1
  3.6.2
  4.0.0
  4.0.0.0
  4.0.0.1
  4.1.0
  4.2.0
  4.2.1
  4.3.0
  4.3.1
  4.4.0
  4.5.0
  4.5.1
  4.6.0
  4.6.1
  4.7.0
  4.7.1
  4.7.2
  4.8.0
  4.8.1
  4.9.0
  4.9.1
  4.10.0
  4.10.1
  4.10.2
  4.10.3
Traceback (most recent call last):
  File dev-tools/scripts/smokeTestRelease.py, line 1530, in module
main()
  File dev-tools/scripts/smokeTestRelease.py, line 1475, 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 1513, in smokeTest
unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % version, 
svnRevision, version, testArgs, baseURL)
  File dev-tools/scripts/smokeTestRelease.py, line 623, in 
unpackAndVerify
verifyUnpacked(java, project, artifact, unpackPath, svnRevision, 
version, testArgs, tmpDir, baseURL)
  File dev-tools/scripts/smokeTestRelease.py, line 804, in 
verifyUnpacked
confirmAllReleasesAreTestedForBackCompat(unpackPath)
  File dev-tools/scripts/smokeTestRelease.py, line 1468, in 
confirmAllReleasesAreTestedForBackCompat
raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
RuntimeError: some releases are not tested by TestBackwardsCompatibility?
hossman@frisbee:~/lucene/branch_5_0$ svn info .
Path: .
URL: https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_0
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1658755
Node Kind: directory
Schedule: normal
Last Changed Author: sarowe
Last Changed Rev: 1658727
Last Changed Date: 2015-02-10 07:44:56 -0700 (Tue, 10 Feb 2015)








-Hoss
http://www.lucidworks.com/

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

[jira] [Commented] (LUCENE-6232) Replace ValueSource context Map with a more concrete data type

2015-02-10 Thread Mike Drob (JIRA)


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

Mike Drob commented on LUCENE-6232:
---

[~shebiki] - Leaving it non-final is probably fine. There is also the 
possibility of leaving some map-like methods on the class (i.e. {{put(K,V)}} 
and {{get(K)}} with explicit documentation that they are not safe.

 Replace ValueSource context Map with a more concrete data type
 --

 Key: LUCENE-6232
 URL: https://issues.apache.org/jira/browse/LUCENE-6232
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Mike Drob

 Inspired by LUCENE-3973
 The context object used by ValueSource and friends is a raw Map that provides 
 no type safety guarantees. In our current state, there are lots of warnings 
 about unchecked casts, raw types, and generally unsafe code from the 
 compiler's perspective.
 There are several common patterns and types of Objects that we store in the 
 context. It would be beneficial to instead use a class with typed methods for 
 get/set of Scorer, Weights, etc.



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

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

Re: [VOTE] 5.0.0 RC2

2015-02-10 Thread Anshum Gupta

This is strange. It works for me on my mac.

On Tue, Feb 10, 2015 at 9:00 AM, Chris Hostetter hossman_luc...@fucit.org
wrote:


 : That part of the script expects you run from the root of a checkout.  It
 : runs the backcompat tests, and scrapes the test output to check all are
 : tested.

 Everything you said made sense, and i even filed LUCENE-6234 to note that
 we should improve the behavior -- and yet even when i run smokeTester from
 the root of my lucene_solr_5_0 checkout, i get the same error...




 hossman@frisbee:~/lucene/branch_5_0$ svn update
 Udev-tools/scripts/smokeTestRelease.py
  U   dev-tools
  U   .
 Updated to revision 1658755.
 hossman@frisbee:~/lucene/branch_5_0$ python3.2
 dev-tools/scripts/smokeTestRelease.py

 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469
 Java 1.7 JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/
 NOTE: output encoding is UTF-8

 Load release URL
 
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469
 ...
   unshortened:

 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469/

 Test Lucene...
   test basics...
   get KEYS
 0.1 MB in 0.64 sec (0.2 MB/sec)
   check changes HTML...
   download lucene-5.0.0-src.tgz...
 27.9 MB in 5.13 sec (5.4 MB/sec)
 verify md5/sha1 digests
 verify sig
 verify trust
   GPG: gpg: WARNING: This key is not certified with a trusted
 signature!
   download lucene-5.0.0.tgz...
 64.0 MB in 29.27 sec (2.2 MB/sec)
 verify md5/sha1 digests
 verify sig
 verify trust
   GPG: gpg: WARNING: This key is not certified with a trusted
 signature!
   download lucene-5.0.0.zip...
 73.5 MB in 22.35 sec (3.3 MB/sec)
 verify md5/sha1 digests
 verify sig
 verify trust
   GPG: gpg: WARNING: This key is not certified with a trusted
 signature!
   unpack lucene-5.0.0.tgz...
 verify JAR metadata/identity/no javax.* or java.* classes...
 test demo with 1.7...
   got 5647 hits for query lucene
 checkindex with 1.7...
 check Lucene's javadoc JAR
   unpack lucene-5.0.0.zip...
 verify JAR metadata/identity/no javax.* or java.* classes...
 test demo with 1.7...
   got 5647 hits for query lucene
 checkindex with 1.7...
 check Lucene's javadoc JAR
   unpack lucene-5.0.0-src.tgz...
 make sure no JARs/WARs in src dist...
 run ant validate
 run tests w/ Java 7 and testArgs=''...
 test demo with 1.7...
   got 210 hits for query lucene
 checkindex with 1.7...
 generate javadocs w/ Java 7...

 Crawl/parse...

 Verify...
   confirm all releases have coverage in TestBackwardsCompatibility
 find all past Lucene releases...
 run TestBackwardsCompatibility..
 Releases that don't seem to be tested:
   2.0.0
   2.1.0
   2.2.0
   2.3.0
   2.4.0
   2.4.1
   2.9.0
   2.9.1
   2.9.2
   2.9.3
   2.9.4
   3.0.0
   3.0.1
   3.0.2
   3.0.3
   3.1.0
   3.2.0
   3.3.0
   3.4.0
   3.5.0
   3.6.0
   3.6.1
   3.6.2
   4.0.0
   4.0.0.0
   4.0.0.1
   4.1.0
   4.2.0
   4.2.1
   4.3.0
   4.3.1
   4.4.0
   4.5.0
   4.5.1
   4.6.0
   4.6.1
   4.7.0
   4.7.1
   4.7.2
   4.8.0
   4.8.1
   4.9.0
   4.9.1
   4.10.0
   4.10.1
   4.10.2
   4.10.3
 Traceback (most recent call last):
   File dev-tools/scripts/smokeTestRelease.py, line 1530, in module
 main()
   File dev-tools/scripts/smokeTestRelease.py, line 1475, 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 1513, in smokeTest
 unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % version,
 svnRevision, version, testArgs, baseURL)
   File dev-tools/scripts/smokeTestRelease.py, line 623, in
 unpackAndVerify
 verifyUnpacked(java, project, artifact, unpackPath, svnRevision,
 version, testArgs, tmpDir, baseURL)
   File dev-tools/scripts/smokeTestRelease.py, line 804, in
 verifyUnpacked
 confirmAllReleasesAreTestedForBackCompat(unpackPath)
   File dev-tools/scripts/smokeTestRelease.py, line 1468, in
 confirmAllReleasesAreTestedForBackCompat
 raise RuntimeError('some releases are not tested by
 TestBackwardsCompatibility?')
 RuntimeError: some releases are not tested by TestBackwardsCompatibility?
 hossman@frisbee:~/lucene/branch_5_0$ svn info .
 Path: .
 URL: https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_0
 Repository Root: https://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 1658755
 Node Kind: directory
 Schedule: normal
 Last Changed Author: sarowe
 Last Changed Rev: 1658727
 Last Changed Date: 2015-02-10 07:44:56 -0700 (Tue, 10 Feb 2015)








 -Hoss
 http://www.lucidworks.com/

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




-- 
Anshum Gupta
http://about.me/anshumgupta

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

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

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([CED4F5A7FE81A2F8:4680CA7D507DCF00]: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-6233) CheckIndex is dog slow when checking term vectors


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

Robert Muir commented on LUCENE-6233:
-

{quote}
I think CheckIndex should not check Terms.getMin/Max for TVs?
{quote}

+1

 CheckIndex is dog slow when checking term vectors
 -

 Key: LUCENE-6233
 URL: https://issues.apache.org/jira/browse/LUCENE-6233
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless

 I'm working on a test that creates a biggish index and I noticed the 
 CheckIndex takes a surprisingly long time to check term vectors.
 I profiled it and uncovered that we spend a lot of time (not sure this 
 explains all of it) in Terms.getMin/getMax.  Since 
 CompressingTermVectorsReader doesn't impl these methods efficiently (which is 
 fine), we fallback to super's impl, which does a digit-by-digit binary search 
 using seekCeil.
 But for TVs this sometimes results in a linear scan.
 I think CheckIndex should not check Terms.getMin/Max for TVs?



--
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-4479) TermVectorComponent NPE when running Solr Cloud

2015-02-10 Thread Timothy Potter (JIRA)


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

Timothy Potter commented on SOLR-4479:
--

Yes, it applies. I think we have to do something here, so am thinking the 
SearchHandler can keep track of whether it has any custom search components and 
if so, it can apply the path as the default if shards.qt is not supplied.

 TermVectorComponent NPE when running Solr Cloud
 ---

 Key: SOLR-4479
 URL: https://issues.apache.org/jira/browse/SOLR-4479
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.1
Reporter: Vitali Kviatkouski
Assignee: Timothy Potter
 Attachments: SOLR-4479.patch


 When running Solr Cloud (just simply 2 shards - as described in wiki), got NPE
 java.lang.NullPointerException
   at 
 org.apache.solr.handler.component.TermVectorComponent.finishStage(TermVectorComponent.java:437)
   at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:317)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at 
 org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:242)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:448)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:269)
   at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453)
   at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
   at 
 org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:560)
   at 
 org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
   at 
 org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382)
   at 
 org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
   at 
 org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006)
   at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
   at 
 org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
 . Skipped
 To reproduce, follow the guide in wiki 
 (http://wiki.apache.org/solr/SolrCloud), add some documents and then request 
 http://localhost:8983/solr/collection1/tvrh?q=*%3A*
 If I include term search vector component in search handler, I get (on second 
 shard):
 SEVERE: null:java.lang.NullPointerException
 at 
 org.apache.solr.handler.component.TermVectorComponent.process(TermVectorComponent.java:321)
 at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:206)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1699)



--
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-6971) TestRebalanceLeaders fails too often.

2015-02-10 Thread Erick Erickson (JIRA)


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

Erick Erickson updated SOLR-6971:
-
Attachment: SOLR-6971-dumper.patch

[~markrmil...@gmail.com] Here's a patch to dump the ZK buffer when this 
condition is hit. If I could trouble you to put it on your local Jenkins and 
send me the log next time it occurs that would help a lot.

 TestRebalanceLeaders fails too often.
 -

 Key: SOLR-6971
 URL: https://issues.apache.org/jira/browse/SOLR-6971
 Project: Solr
  Issue Type: Test
Reporter: Mark Miller
Assignee: Erick Erickson
Priority: Minor
 Attachments: SOLR-6971-dumper.patch


 I see this fail too much - I've seen 3 different fail types so far.



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

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

[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_31) - Build # 11612 - Failure!

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

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11612/
Java: 32bit/jdk1.8.0_31 -server -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestBadConfig

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

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


FAILED:  org.apache.solr.core.TestBadConfig.testInvalidScriptFile

Error Message:
Test abandoned because suite timeout was reached.

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




Build Log:
[...truncated 10626 lines...]
   [junit4] Suite: org.apache.solr.core.TestBadConfig
   [junit4]   2 Creating dataDir: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J1/temp/solr.core.TestBadConfig
 2D5ABB9F1FB06464-001/init-core-data-001
   [junit4]   2 78065 T294 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl 
(false) and clientAuth (false)
   [junit4]   2 78068 T294 oas.SolrTestCaseJ4.setUp ###Starting 
testInvalidScriptFile
   [junit4]   2 78769 T294 oas.SolrTestCaseJ4.initCore initCore
   [junit4]   2 78770 T294 oasc.SolrResourceLoader.init new 
SolrResourceLoader for directory: 
'/mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/test-files/solr/collection1/'
   [junit4]   2 78771 T294 oasc.SolrResourceLoader.replaceClassLoader Adding 
'file:/mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/test-files/solr/collection1/lib/.svn/'
 to classloader
   [junit4]   2 78771 T294 oasc.SolrResourceLoader.replaceClassLoader Adding 
'file:/mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/test-files/solr/collection1/lib/classes/'
 to classloader
   [junit4]   2 78771 T294 oasc.SolrResourceLoader.replaceClassLoader Adding 
'file:/mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/test-files/solr/collection1/lib/README'
 to classloader
   [junit4]   2 78816 T294 oasc.SolrConfig.refreshRequestParams current 
version of requestparams : -1
   [junit4]   2 78822 T294 oasc.SolrConfig.init Using Lucene MatchVersion: 
5.1.0
   [junit4]   2 78837 T294 oasc.SolrConfig.init Loaded SolrConfig: 
bad-solrconfig-invalid-scriptfile.xml
   [junit4]   2 78838 T294 oass.IndexSchema.readSchema Reading Solr Schema 
from 
/mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/test-files/solr/collection1/conf/schema.xml
   [junit4]   2 78843 T294 oass.IndexSchema.readSchema [null] Schema name=test
   [junit4]   2 78954 T294 oass.OpenExchangeRatesOrgProvider.init Initialized 
with rates=open-exchange-rates.json, refreshInterval=1440.
   [junit4]   2 78958 T294 oass.IndexSchema.readSchema default search field in 
schema is text
   [junit4]   2 78959 T294 oass.IndexSchema.readSchema unique key field: id
   [junit4]   2 78968 T294 oass.FileExchangeRateProvider.reload Reloading 
exchange rates from file currency.xml
   [junit4]   2 78971 T294 oass.FileExchangeRateProvider.reload Reloading 
exchange rates from file currency.xml
   [junit4]   2 78973 T294 oass.OpenExchangeRatesOrgProvider.reload Reloading 
exchange rates from open-exchange-rates.json
   [junit4]   2 78975 T294 
oass.OpenExchangeRatesOrgProvider$OpenExchangeRates.init WARN Unknown key 
IMPORTANT NOTE
   [junit4]   2 78976 T294 
oass.OpenExchangeRatesOrgProvider$OpenExchangeRates.init WARN Expected key, 
got STRING
   [junit4]   2 78976 T294 oass.OpenExchangeRatesOrgProvider.reload Reloading 
exchange rates from open-exchange-rates.json
   [junit4]   2 78977 T294 
oass.OpenExchangeRatesOrgProvider$OpenExchangeRates.init WARN Unknown key 
IMPORTANT NOTE
   [junit4]   2 78977 T294 
oass.OpenExchangeRatesOrgProvider$OpenExchangeRates.init WARN Expected key, 
got STRING
   [junit4]   2 78978 T294 oasc.SolrResourceLoader.locateSolrHome JNDI not 
configured for solr (NoInitialContextEx)
   [junit4]   2 78978 T294 oasc.SolrResourceLoader.locateSolrHome using system 
property solr.solr.home: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/test-files/solr
   [junit4]   2 78978 T294 oasc.SolrResourceLoader.init new 
SolrResourceLoader for directory: 
'/mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/test-files/solr/'
   [junit4]   2 78993 T294 oasc.CoreContainer.init New CoreContainer 31613603
   [junit4]   2 78994 T294 oasc.CoreContainer.load Loading cores into 
CoreContainer 
[instanceDir=/mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/test-files/solr/]
   [junit4]   2 78994 T294 oashc.HttpShardHandlerFactory.getParameter Setting 
socketTimeout to: 60
   [junit4]   2 78995 T294 oashc.HttpShardHandlerFactory.getParameter Setting 
urlScheme to: null
   [junit4]   2 78995 T294 oashc.HttpShardHandlerFactory.getParameter Setting 
connTimeout to: 6
   [junit4]   2 78995 T294 oashc.HttpShardHandlerFactory.getParameter Setting 
maxConnectionsPerHost to:

Re: [VOTE] 5.0.0 RC2

2015-02-10 Thread Timothy Potter

yes, that output is expected since Solr doesn't boot up with any
collections / cores anymore, the smoke tester creates a core on-the-fly and
that is the output from the create command.

On Tue, Feb 10, 2015 at 9:39 AM, Michael McCandless 
luc...@mikemccandless.com wrote:

 +1

 SUCCESS! [0:38:50.050201]

 Is this output normal/OK?  I assume it's just extra verbosity?

 Creating new core 'techproducts' using command:

 http://localhost:8983/solr/admin/cores?action=CREATEname=techproductsinstanceDir=techproducts

 {
   responseHeader:{
 status:0,
 QTime:838},
   core:techproducts}

 Mike McCandless

 http://blog.mikemccandless.com


 On Tue, Feb 10, 2015 at 10:45 AM, Adrien Grand jpou...@gmail.com wrote:
  +1
 
  SUCCESS! [2:20:47.907193]
 
  On Tue, Feb 10, 2015 at 3:58 PM, Erik Hatcher erik.hatc...@gmail.com
 wrote:
  +1 - I ran through several examples to ensure all was working as
 expected.
  Ship it! :)
 
  Erik
 
  On Feb 9, 2015, at 6:16 PM, Anshum Gupta ans...@anshumgupta.net
 wrote:
 
  Please vote for the second release candidate for Lucene/Solr 5.0.0.
 
  The artifacts can be downloaded here:
 
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469
 
  Or you can run the smoke tester directly with this command:
  python3.2 dev-tools/scripts/smokeTestRelease.py
 
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469
 
 
  I could not get the above command to work as downloading some file or
 the
  other timed out for me (over 6 attempts) so I instead downloaded the
 entire
  RC as a tgz. I still have it here:
 
 
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469.tgz
 
  Untar the above folder at a location of choice. Do not change the name
 of
  the folder as the smokeTestRelease.py extracts information from that.
 
  and then instead of using http, used file://. Here's the command:
 
  python3.2 dev-tools/scripts/smokeTestRelease.py
  file://path_to_the_extracted_folder
 
  and finally, here's my +1:
 
  SUCCESS! [0:30:50.246761]
 
 
  --
  Anshum Gupta
  http://about.me/anshumgupta
 
 
 
 
 
  --
  Adrien
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
 

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

[jira] [Commented] (LUCENE-6232) Replace ValueSource context Map with a more concrete data type

2015-02-10 Thread Mike Drob (JIRA)


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

Mike Drob commented on LUCENE-6232:
---

[~rjernst] - I saw that JIRA, but like the comments said I don't think it 
solves all the problems. That's maybe a good start, but we need a much more 
serious refactoring so I thought maybe a separate issue would be more 
appropriate.

 Replace ValueSource context Map with a more concrete data type
 --

 Key: LUCENE-6232
 URL: https://issues.apache.org/jira/browse/LUCENE-6232
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Mike Drob

 Inspired by LUCENE-3973
 The context object used by ValueSource and friends is a raw Map that provides 
 no type safety guarantees. In our current state, there are lots of warnings 
 about unchecked casts, raw types, and generally unsafe code from the 
 compiler's perspective.
 There are several common patterns and types of Objects that we store in the 
 context. It would be beneficial to instead use a class with typed methods for 
 get/set of Scorer, Weights, etc.



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

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

[jira] [Commented] (SOLR-4479) TermVectorComponent NPE when running Solr Cloud

2015-02-10 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-4479:
---

Good to fix this stuff. Getting this to work right used to be kind of like a 
special secret :)

 TermVectorComponent NPE when running Solr Cloud
 ---

 Key: SOLR-4479
 URL: https://issues.apache.org/jira/browse/SOLR-4479
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.1
Reporter: Vitali Kviatkouski
Assignee: Timothy Potter
 Attachments: SOLR-4479.patch


 When running Solr Cloud (just simply 2 shards - as described in wiki), got NPE
 java.lang.NullPointerException
   at 
 org.apache.solr.handler.component.TermVectorComponent.finishStage(TermVectorComponent.java:437)
   at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:317)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at 
 org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:242)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:448)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:269)
   at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453)
   at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
   at 
 org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:560)
   at 
 org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
   at 
 org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382)
   at 
 org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
   at 
 org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006)
   at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
   at 
 org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
 . Skipped
 To reproduce, follow the guide in wiki 
 (http://wiki.apache.org/solr/SolrCloud), add some documents and then request 
 http://localhost:8983/solr/collection1/tvrh?q=*%3A*
 If I include term search vector component in search handler, I get (on second 
 shard):
 SEVERE: null:java.lang.NullPointerException
 at 
 org.apache.solr.handler.component.TermVectorComponent.process(TermVectorComponent.java:321)
 at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:206)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1699)



--
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-6227) Add BooleanClause.Occur.FILTER


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

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

Commit 1658764 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1658764 ]

LUCENE-6227: Add BooleanClause.Occur.FILTER.

 Add BooleanClause.Occur.FILTER
 --

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

 Attachments: LUCENE-6227.patch, LUCENE-6227.patch, LUCENE-6227.patch, 
 LUCENE-6227.patch, LUCENE-6227.patch


 Now that we have weight-level control of whether scoring is needed or not, we 
 could add a new clause type to BooleanQuery. It would behave like MUST exept 
 that it would not participate in scoring.
 Why do we need it given that we already have FilteredQuery? The idea is that 
 by having a single query that performs conjunctions, we could potentially 
 take better decisions. It's not ready to replace FilteredQuery yet as 
 FilteredQuery has handling of random-access filters that BooleanQuery 
 doesn't, but it's a first step towards that direction and eventually 
 FilteredQuery would just rewrite to a BooleanQuery.
 I've been calling this new clause type FILTER so far, but feel free to 
 propose a better name.



--
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: [VOTE] 5.0.0 RC2

2015-02-10 Thread Ryan Ernst

+1

SUCCESS! [0:25:26.339544]

On Tue, Feb 10, 2015 at 7:45 AM, Adrien Grand jpou...@gmail.com wrote:

 +1

 SUCCESS! [2:20:47.907193]

 On Tue, Feb 10, 2015 at 3:58 PM, Erik Hatcher erik.hatc...@gmail.com
 wrote:
  +1 - I ran through several examples to ensure all was working as
 expected.
  Ship it! :)
 
  Erik
 
  On Feb 9, 2015, at 6:16 PM, Anshum Gupta ans...@anshumgupta.net wrote:
 
  Please vote for the second release candidate for Lucene/Solr 5.0.0.
 
  The artifacts can be downloaded here:
 
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469
 
  Or you can run the smoke tester directly with this command:
  python3.2 dev-tools/scripts/smokeTestRelease.py
 
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469
 
 
  I could not get the above command to work as downloading some file or the
  other timed out for me (over 6 attempts) so I instead downloaded the
 entire
  RC as a tgz. I still have it here:
 
 
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469.tgz
 
  Untar the above folder at a location of choice. Do not change the name of
  the folder as the smokeTestRelease.py extracts information from that.
 
  and then instead of using http, used file://. Here's the command:
 
  python3.2 dev-tools/scripts/smokeTestRelease.py
  file://path_to_the_extracted_folder
 
  and finally, here's my +1:
 
  SUCCESS! [0:30:50.246761]
 
 
  --
  Anshum Gupta
  http://about.me/anshumgupta
 
 



 --
 Adrien

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

[jira] [Updated] (SOLR-6398) Add IterativeMergeStrategy to support Parallel Iterative Algorithms

2015-02-10 Thread Joel Bernstein (JIRA)


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

Joel Bernstein updated SOLR-6398:
-
Description: 
This ticket builds on the existing AnalyticsQuery / MergeStrategy framework by 
adding the abstract class IterativeMergeStrategy,  which has built-in support 
for call-backs to the shards. The IterativeMergeStrategy is designed to support 
the execution of Parallel iterative Algorithms, such as Gradient Descent, 
inside of Solr.




  was:
This ticket builds on the existing AnalyticsQuery / MergeStrategy framework by 
adding the abstract class IterativeMergeStrategy,  which has built-in support 
for call-backs to the shards. By extending this class you can plugin Parallel 
iterative Algorithms, such as Gradient Descent, that will run efficiently 
inside Solr. 





 Add IterativeMergeStrategy to support Parallel Iterative Algorithms
 ---

 Key: SOLR-6398
 URL: https://issues.apache.org/jira/browse/SOLR-6398
 Project: Solr
  Issue Type: Improvement
Reporter: Joel Bernstein
Priority: Minor
 Fix For: 5.1

 Attachments: SOLR-6398.patch, SOLR-6398.patch, SOLR-6398.patch


 This ticket builds on the existing AnalyticsQuery / MergeStrategy framework 
 by adding the abstract class IterativeMergeStrategy,  which has built-in 
 support for call-backs to the shards. The IterativeMergeStrategy is designed 
 to support the execution of Parallel iterative Algorithms, such as Gradient 
 Descent, inside of Solr.



--
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-6398) Add IterativeMergeStrategy to support Parallel Iterative Algorithms

2015-02-10 Thread Joel Bernstein (JIRA)


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

Joel Bernstein updated SOLR-6398:
-
Fix Version/s: 5.1

 Add IterativeMergeStrategy to support Parallel Iterative Algorithms
 ---

 Key: SOLR-6398
 URL: https://issues.apache.org/jira/browse/SOLR-6398
 Project: Solr
  Issue Type: Improvement
Reporter: Joel Bernstein
Priority: Minor
 Fix For: 5.1

 Attachments: SOLR-6398.patch, SOLR-6398.patch, SOLR-6398.patch


 This ticket builds on the existing AnalyticsQuery / MergeStrategy framework 
 by adding the abstract class IterativeMergeStrategy,  which has built-in 
 support for call-backs to the shards. The IterativeMergeStrategy is designed 
 to support the execution of Parallel iterative Algorithms, such as Gradient 
 Descent, inside of Solr.



--
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-6227) Add BooleanClause.Occur.FILTER


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

Adrien Grand resolved LUCENE-6227.
--
Resolution: Fixed

 Add BooleanClause.Occur.FILTER
 --

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

 Attachments: LUCENE-6227.patch, LUCENE-6227.patch, LUCENE-6227.patch, 
 LUCENE-6227.patch, LUCENE-6227.patch


 Now that we have weight-level control of whether scoring is needed or not, we 
 could add a new clause type to BooleanQuery. It would behave like MUST exept 
 that it would not participate in scoring.
 Why do we need it given that we already have FilteredQuery? The idea is that 
 by having a single query that performs conjunctions, we could potentially 
 take better decisions. It's not ready to replace FilteredQuery yet as 
 FilteredQuery has handling of random-access filters that BooleanQuery 
 doesn't, but it's a first step towards that direction and eventually 
 FilteredQuery would just rewrite to a BooleanQuery.
 I've been calling this new clause type FILTER so far, but feel free to 
 propose a better name.



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

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

[jira] [Created] (LUCENE-6234) harden smokeTestRelease.py's expectations regarding CWD

Hoss Man created LUCENE-6234:


 Summary: harden smokeTestRelease.py's expectations regarding CWD
 Key: LUCENE-6234
 URL: https://issues.apache.org/jira/browse/LUCENE-6234
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Hoss Man


smokeTestRelease.py changed at some point to require/expect that you run it 
from the root of the checkout of the branch you are smoke testing, per rernst's 
comments in mail...

bq. That part of the script expects you run from the root of a checkout.  It 
runs the backcompat tests, and scrapes the test output to check all are tested.

The context was that i (out of habit from older versions of this script) was 
trying to do this in my personal tmp space (expecting the script to create it's 
RC specific tmp dir in the CWD)...

{noformat}
hossman@frisbee:~/tmp$ python3.2 
~/lucene/branch_5_0/dev-tools/scripts/smokeTestRelease.py 
http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469
{noformat}

If smokeTestRelease.py is going to have expectations about it's CWD, then it 
should either enforce those expectations (ie: do a simple assert in main() that 
the CWD meets some expectations, and/or check $0) or it should use $0 to 
figure out where the root svn checkout is and cd to that directory itself.



--
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: [VOTE] 5.0.0 RC2

2015-02-10 Thread Michael McCandless

On Tue, Feb 10, 2015 at 11:45 AM, Timothy Potter thelabd...@gmail.com wrote:

 yes, that output is expected since Solr doesn't boot up with any collections
 / cores anymore, the smoke tester creates a core on-the-fly and that is the
 output from the create command.

OK, thanks for explaining...

Mike McCandless

http://blog.mikemccandless.com

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

[jira] [Commented] (SOLR-6775) Creating backup snapshot null pointer exception

2015-02-10 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-6775:
---

I think a lot of tests even not on windows started failing with this...

 Creating backup snapshot null pointer exception
 ---

 Key: SOLR-6775
 URL: https://issues.apache.org/jira/browse/SOLR-6775
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 4.10
 Environment: Linux Server, Java version 1.7.0_21, Solr version 
 4.10.0
Reporter: Ryan Hesson
Assignee: Shalin Shekhar Mangar
  Labels: snapshot, solr
 Fix For: Trunk, 5.1

 Attachments: SOLR-6775.patch, SOLR-6775.patch


 I set up Solr Replication. I have one master on a server, one slave on 
 another server. The replication of data appears functioning correctly. The 
 issue is when the master SOLR tries to create a snapshot backup it gets a 
 null pointer exception. 
 org.apache.solr.handler.SnapShooter createSnapshot method calls 
 org.apache.solr.handler.SnapPuller.delTree(snapShotDir); at line 162 and the 
 exception happens within  org.apache.solr.handler.SnapPuller at line 1026 
 because snapShotDir is null. 
 Here is the actual log output:
 58319963 [qtp12610551-16] INFO  org.apache.solr.core.SolrCore  - newest 
 commit generation = 349
 58319983 [Thread-19] INFO  org.apache.solr.handler.SnapShooter  - Creating 
 backup snapshot...
 Exception in thread Thread-19 java.lang.NullPointerException
 at org.apache.solr.handler.SnapPuller.delTree(SnapPuller.java:1026)
 at 
 org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:162)
 at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:91)
 I may have missed how to set the directory in the documentation but I've 
 looked around without much luck. I thought the process was to use the same 
 directory as the index data for the snapshots. Is this a known issue with 
 this release or am I missing how to set the value? If someone could tell me 
 how to set snapshotdir or confirm that it is an issue and a different way of 
 backing up the index is needed it would be much appreciated. 



--
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-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-2.patch

patch that retries all downloads.

I'm running the smoke tester now, and it has already successfully retried twice 
within the lucene section, so I'm hopeful this will do the trick.

 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

[jira] [Updated] (LUCENE-6227) Add BooleanClause.Occur.FILTER

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

Adrien Grand updated LUCENE-6227:
-
Attachment: LUCENE-6227.patch

Patch:
- more comments
- added assertion that scorers is a subset of required in ConjunctionScorer
- added unit test decicated to the single filter clause, with two cases: 1.
when BooleanQuery rewrite to a single term query and 2. when Boolean cannot
rewrite because of SHOULD clauses that return a null scorer.

Add BooleanClause.Occur.FILTER
--

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

Attachments: LUCENE-6227.patch, LUCENE-6227.patch, LUCENE-6227.patch,
LUCENE-6227.patch, LUCENE-6227.patch

Now that we have weight-level control of whether scoring is needed or not, we
could add a new clause type to BooleanQuery. It would behave like MUST exept
that it would not participate in scoring.
Why do we need it given that we already have FilteredQuery? The idea is that
by having a single query that performs conjunctions, we could potentially
take better decisions. It's not ready to replace FilteredQuery yet as
FilteredQuery has handling of random-access filters that BooleanQuery
doesn't, but it's a first step towards that direction and eventually
FilteredQuery would just rewrite to a BooleanQuery.
I've been calling this new clause type FILTER so far, but feel free to
propose a better name.

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

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

No tests ran.

Build Log:
[...truncated 37443 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]

Re: kicking github sync?

2015-02-10 Thread Ryan McKinley

I just posted:
https://issues.apache.org/jira/browse/INFRA-9155



On Mon, Feb 9, 2015 at 6:48 PM, Mark Miller markrmil...@gmail.com wrote:

 Anyone filed an infra ticket? It should be synced close to right away with
 our git mirror and usually no more than a couple hours on github. Neither
 are updating properly.

 Mark

 On Mon, Feb 9, 2015 at 9:42 PM Ryan McKinley ryan...@gmail.com wrote:

 It looks like the last github sync was 5 days ago :(
 https://github.com/apache/lucene-solr/commits/trunk

 I know this tends to lag the apache mirror, but 5 days is more than usual

 Any idea what (if anything) we can do to kick it?

 Thanks
 ryan

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


I'm still getting download timeouts.

Not all downloads go through the retry logic.

I'm testing another patch the retries every failed download.

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

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

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

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([62773CE31F7C010F:EA230339B1806CF7]: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

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

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1945/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseParallelGC

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

Error Message:
Captured an uncaught exception in thread: Thread[id=16408, 
name=SocketProxy-Response-59874:60083, state=RUNNABLE, 
group=TGRP-HttpPartitionTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=16408, name=SocketProxy-Response-59874:60083, 
state=RUNNABLE, group=TGRP-HttpPartitionTest]
at 
__randomizedtesting.SeedInfo.seed([84AFCF1E3A0E92F1:CFBF0C494F2FF09]:0)
Caused by: java.lang.RuntimeException: java.net.SocketException: Socket is 
closed
at __randomizedtesting.SeedInfo.seed([84AFCF1E3A0E92F1]:0)
at 
org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:344)
Caused by: java.net.SocketException: Socket is closed
at java.net.Socket.setSoTimeout(Socket.java:1101)
at 
org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:341)




Build Log:
[...truncated 10736 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2 Creating dataDir: 
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/solr/build/solr-core/test/J0/temp/solr.cloud.HttpPartitionTest
 84AFCF1E3A0E92F1-001/init-core-data-001
   [junit4]   2 4987940 T16014 
oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext system 
property: /
   [junit4]   2 4987946 T16014 oasc.ZkTestServer.run STARTING ZK TEST SERVER
   [junit4]   1 client port:0.0.0.0/0.0.0.0:0
   [junit4]   2 4987947 T16015 oasc.ZkTestServer$ZKServerMain.runFromConfig 
Starting server
   [junit4]   2 4988048 T16014 oasc.ZkTestServer.run start zk server on 
port:59870
   [junit4]   2 4988049 T16014 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2 4988056 T16014 oascc.ConnectionManager.waitForConnected 
Waiting for client to connect to ZooKeeper
   [junit4]   2 4988068 T16022 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@48348e4b 
name:ZooKeeperConnection Watcher:127.0.0.1:59870 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2 4988069 T16014 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2 4988069 T16014 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2 4988070 T16014 oascc.SolrZkClient.makePath makePath: /solr
   [junit4]   2 4988086 T16014 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2 4988089 T16014 oascc.ConnectionManager.waitForConnected 
Waiting for client to connect to ZooKeeper
   [junit4]   2 4988094 T16025 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@a73d9a3 name:ZooKeeperConnection 
Watcher:127.0.0.1:59870/solr got event WatchedEvent state:SyncConnected 
type:None path:null path:null type:None
   [junit4]   2 4988095 T16014 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2 4988095 T16014 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2 4988096 T16014 oascc.SolrZkClient.makePath makePath: 
/collections/collection1
   [junit4]   2 4988106 T16014 oascc.SolrZkClient.makePath makePath: 
/collections/collection1/shards
   [junit4]   2 4988115 T16014 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection
   [junit4]   2 4988120 T16014 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection/shards
   [junit4]   2 4988129 T16014 oasc.AbstractZkTestCase.putConfig put 
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2 4988129 T16014 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.xml
   [junit4]   2 4988139 T16014 oasc.AbstractZkTestCase.putConfig put 
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/solr/core/src/test-files/solr/collection1/conf/schema.xml
 to /configs/conf1/schema.xml
   [junit4]   2 4988139 T16014 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/schema.xml
   [junit4]   2 4988148 T16014 oasc.AbstractZkTestCase.putConfig put 
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2 4988149 T16014 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2 4988158 T16014 oasc.AbstractZkTestCase.putConfig put 
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/solr/core/src/test-files/solr/collection1/conf/stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2 4988159 T16014 oascc.SolrZkClient.makePath

[jira] [Commented] (SOLR-6648) AnalyzingInfixLookupFactory always highlights suggestions

2015-02-10 Thread Boon Low (JIRA)


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

Boon Low commented on SOLR-6648:


Glad to see this committed into the code base. Thanks Tomás and Varun.

 AnalyzingInfixLookupFactory always highlights suggestions
 -

 Key: SOLR-6648
 URL: https://issues.apache.org/jira/browse/SOLR-6648
 Project: Solr
  Issue Type: Sub-task
Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1
Reporter: Varun Thacker
Assignee: Tomás Fernández Löbbe
  Labels: suggester
 Fix For: Trunk, 5.1

 Attachments: SOLR-6648-v4.10.3.patch, SOLR-6648.patch


 When using AnalyzingInfixLookupFactory suggestions always return with the 
 match term as highlighted and 'allTermsRequired' is always set to true.
 We should be able to configure those.
 Steps to reproduce - 
 schema additions
 {code}
 searchComponent name=suggest class=solr.SuggestComponent
 lst name=suggester
   str name=namemySuggester/str
   str name=lookupImplAnalyzingInfixLookupFactory/str
   str name=dictionaryImplDocumentDictionaryFactory/str 
   str name=fieldsuggestField/str
   str name=weightFieldweight/str
   str name=suggestAnalyzerFieldTypetextSuggest/str
 /lst
   /searchComponent
   requestHandler name=/suggest class=solr.SearchHandler startup=lazy
 lst name=defaults
   str name=suggesttrue/str
   str name=suggest.count10/str
 /lst
 arr name=components
   strsuggest/str
 /arr
   /requestHandler
 {code}
 solrconfig changes -
 {code}
 fieldType class=solr.TextField name=textSuggest 
 positionIncrementGap=100
analyzer
   tokenizer class=solr.StandardTokenizerFactory/
   filter class=solr.StandardFilterFactory/
   filter class=solr.LowerCaseFilterFactory/
/analyzer
   /fieldType
field name=suggestField type=textSuggest indexed=true 
 stored=true/
 {code}
 Add 3 documents - 
 {code}
 curl http://localhost:8983/solr/update/json?commit=true -H 
 'Content-type:application/json' -d '
 [ {id : 1, suggestField : bass fishing}, {id : 2, suggestField 
 : sea bass}, {id : 3, suggestField : sea bass fishing} ]
 '
 {code}
 Query -
 {code}
 http://localhost:8983/solr/collection1/suggest?suggest.build=truesuggest.dictionary=mySuggesterq=basswt=jsonindent=on
 {code}
 Response 
 {code}
 {
   responseHeader:{
 status:0,
 QTime:25},
   command:build,
   suggest:{mySuggester:{
   bass:{
 numFound:3,
 suggestions:[{
 term:bbass/b fishing,
 weight:0,
 payload:},
   {
 term:sea bbass/b,
 weight:0,
 payload:},
   {
 term:sea bbass/b fishing,
 weight:0,
 payload:}]
 {code}
 The problem is in SolrSuggester Line 200 where we say lookup.lookup()
 This constructor does not take allTermsRequired and doHighlight since it's 
 only tuneable to AnalyzingInfixSuggester and not the other lookup 
 implementations.
 If different Lookup implementations have different params as their 
 constructors, these sort of issues will always keep happening. Maybe we 
 should not keep it generic and do instanceof checks and set params 
 accordingly?



--
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-6229) Remove Scorer.getChildren?


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

Adrien Grand commented on LUCENE-6229:
--

bq. Could this functionality be provided in a different way that doesn't have 
the problems you want to address here? E.g. could users hint the search to 
require this functionality (needClauses?), which in turn leads to not using 
optimized implementations that cannot (easily) provide this information?

I'm not sure I would like an additional parameter. In the join module, we 
worked around the fact that boolean queries do not always expose getChildren() 
by creating a dedicated IndexSearcher impl that always uses scorers instead of 
bulk scorers (ToParentBlockJoinIndexSearcher in lucene/join). Maybe this thing 
could be moved to a more general-purpose like lucene/misc and we could document 
that this is the way to go if you want to have access to information about 
child scorers from a collector, at the cost of some potential slow down?

 Remove Scorer.getChildren?
 --

 Key: LUCENE-6229
 URL: https://issues.apache.org/jira/browse/LUCENE-6229
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor

 This API is used in a single place in our code base: 
 ToParentBlockJoinCollector. In addition, the usage is a bit buggy given that 
 using this API from a collector only works if setScorer is called with an 
 actual Scorer (and not eg. FakeScorer or BooleanScorer like you would get in 
 disjunctions) so it needs a custom IndexSearcher that does not use the 
 BulkScorer API.



--
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-6226) Allow TermScorer to expose positions, offsets and payloads

2015-02-10 Thread Alan Woodward (JIRA)


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

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

Updated patch, using a new PostingsFeatures enum instead of a bitmask.  I tried 
using the already-existing IndexOptions, but it doesn't deal with payloads 
directly - maybe we could look at merging the two enums later on?

 Allow TermScorer to expose positions, offsets and payloads
 --

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

 Attachments: LUCENE-6226.patch, LUCENE-6226.patch, LUCENE-6226.patch, 
 LUCENE-6226.patch, LUCENE-6226.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

2015-02-10 Thread Anshum Gupta (JIRA)


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

Anshum Gupta commented on LUCENE-6231:
--

Works for me with the patch. Thanks for fixing this Steve!

 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
 Attachments: 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] [Commented] (LUCENE-6228) Do not expose full-fledged scorers in LeafCollector.setScorer

2015-02-10 Thread Alan Woodward (JIRA)


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

Alan Woodward commented on LUCENE-6228:
---

I like this, particularly if I'm about to start adding more position-aware 
methods to ScoringEnum.

I think FilterScorer should be FilterScoringEnum now?  Similarly with 
AssertingScorer.

The javadocs on LeafCollector should still refer to Scorer, not ScoringEnum

Can we get rid of the FakeScorers in the taxonomy and expression modules, and 
in the index Sorter now?

 Do not expose full-fledged scorers in LeafCollector.setScorer
 -

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

 Attachments: LUCENE-6228.patch, LUCENE-6228.patch


 Currently LeafCollector.setScorer takes a Scorer, which I don't like because 
 several methods should never be called in the context of a Collector (like 
 nextDoc or advance).
 I think it's even more trappy for methods that might seem to work in some 
 particular cases but will not work in the general case, like getChildren 
 which will not work if you have a specialized BulkScorer or iterating over 
 positions which will not work if you are in a MultiCollector and another leaf 
 collector consumes positions too.
 So I think we should restrict what can be seen from a collector to avoid such 
 traps.



--
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-6228) Do not expose full-fledged scorers in LeafCollector.setScorer


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

Adrien Grand updated LUCENE-6228:
-
Attachment: LUCENE-6228.patch

This is a great suggestion as it makes collectors easier to migrate and is also 
consistent with the fact that Scorer(ScoringEnum in the patch) extends 
PostingsEnum. Here is a new patch.

 Do not expose full-fledged scorers in LeafCollector.setScorer
 -

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

 Attachments: LUCENE-6228.patch, LUCENE-6228.patch


 Currently LeafCollector.setScorer takes a Scorer, which I don't like because 
 several methods should never be called in the context of a Collector (like 
 nextDoc or advance).
 I think it's even more trappy for methods that might seem to work in some 
 particular cases but will not work in the general case, like getChildren 
 which will not work if you have a specialized BulkScorer or iterating over 
 positions which will not work if you are in a MultiCollector and another leaf 
 collector consumes positions too.
 So I think we should restrict what can be seen from a collector to avoid such 
 traps.



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

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

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

No tests ran.

Build Log:
[...truncated 37630 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] (SOLR-7076) TikaEntityProcessor should have support for onError=skip


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

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

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

SOLR-7076: TikaEntityProcessor should have support for onError=skip

 TikaEntityProcessor should have support for onError=skip
 

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


 There is no reason why we can't continue if one doc failed



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

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

[jira] [Commented] (SOLR-7076) TikaEntityProcessor should have support for onError=skip

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


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

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

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

SOLR-7076: CHANGES.txt update

 TikaEntityProcessor should have support for onError=skip
 

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


 There is no reason why we can't continue if one doc failed



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

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

[jira] [Commented] (SOLR-4479) TermVectorComponent NPE when running Solr Cloud

2015-02-10 Thread Varun Thacker (JIRA)


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

Varun Thacker commented on SOLR-4479:
-

Hi Tim,

Not entirely sure, but this comment applies here as well ? 
https://issues.apache.org/jira/browse/SOLR-6311?focusedCommentId=14085258page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14085258

 TermVectorComponent NPE when running Solr Cloud
 ---

 Key: SOLR-4479
 URL: https://issues.apache.org/jira/browse/SOLR-4479
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.1
Reporter: Vitali Kviatkouski
Assignee: Timothy Potter
 Attachments: SOLR-4479.patch


 When running Solr Cloud (just simply 2 shards - as described in wiki), got NPE
 java.lang.NullPointerException
   at 
 org.apache.solr.handler.component.TermVectorComponent.finishStage(TermVectorComponent.java:437)
   at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:317)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at 
 org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:242)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:448)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:269)
   at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453)
   at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
   at 
 org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:560)
   at 
 org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
   at 
 org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382)
   at 
 org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
   at 
 org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006)
   at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
   at 
 org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
 . Skipped
 To reproduce, follow the guide in wiki 
 (http://wiki.apache.org/solr/SolrCloud), add some documents and then request 
 http://localhost:8983/solr/collection1/tvrh?q=*%3A*
 If I include term search vector component in search handler, I get (on second 
 shard):
 SEVERE: null:java.lang.NullPointerException
 at 
 org.apache.solr.handler.component.TermVectorComponent.process(TermVectorComponent.java:321)
 at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:206)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1699)



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

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

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_31) - Build # 4476 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4476/
Java: 32bit/jdk1.8.0_31 -server -XX:+UseParallelGC

6 tests failed.
FAILED:  org.apache.solr.spelling.suggest.SuggesterFSTTest.testSuggestions

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([FEE4850D728ED3B7:5838BCF8BCBA8449]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:748)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:715)
at 
org.apache.solr.spelling.suggest.SuggesterTest.testSuggestions(SuggesterTest.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at

[jira] [Updated] (LUCENE-6227) Add BooleanClause.Occur.FILTER


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

Adrien Grand updated LUCENE-6227:
-
Attachment: LUCENE-6227.patch

Here is a new patch with improved naming: I renamed MUST_NOT to FILTER_NOT to 
make it clear that it is conceptually closed to FILTER than to MUST. The patch 
applies to 5.x and keeps backward compatibility for MUST_NOT.

 Add BooleanClause.Occur.FILTER
 --

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

 Attachments: LUCENE-6227.patch, LUCENE-6227.patch, LUCENE-6227.patch, 
 LUCENE-6227.patch


 Now that we have weight-level control of whether scoring is needed or not, we 
 could add a new clause type to BooleanQuery. It would behave like MUST exept 
 that it would not participate in scoring.
 Why do we need it given that we already have FilteredQuery? The idea is that 
 by having a single query that performs conjunctions, we could potentially 
 take better decisions. It's not ready to replace FilteredQuery yet as 
 FilteredQuery has handling of random-access filters that BooleanQuery 
 doesn't, but it's a first step towards that direction and eventually 
 FilteredQuery would just rewrite to a BooleanQuery.
 I've been calling this new clause type FILTER so far, but feel free to 
 propose a better name.



--
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-6226) Allow TermScorer to expose positions, offsets and payloads


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

Robert Muir commented on LUCENE-6226:
-

We also need semantics for doesnt make sense at all. For example if i request 
positions from a MatchAllDocsScorer, what happens?

 Allow TermScorer to expose positions, offsets and payloads
 --

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

 Attachments: LUCENE-6226.patch, LUCENE-6226.patch, LUCENE-6226.patch, 
 LUCENE-6226.patch, LUCENE-6226.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-6227) Add BooleanClause.Occur.FILTER

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

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

Robert Muir commented on LUCENE-6227:
-

Renaming of MUST_NOT is a big scope creep to this issue. I think it should be
done elsewhere instead of adding any confusion to this patch. its unrelated.
this patch just adds FILTER. completely unrelated to the name of MUST_NOT.

Add BooleanClause.Occur.FILTER
--

Attachments: LUCENE-6227.patch, LUCENE-6227.patch, LUCENE-6227.patch,
LUCENE-6227.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] (SOLR-5147) Support child documents in DIH

2015-02-10 Thread Harish Raghavan (JIRA)


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

Harish Raghavan commented on SOLR-5147:
---

Does this patch also cover support for FileDataSource/XPathEntityProcessor ? 

 Support child documents in DIH
 --

 Key: SOLR-5147
 URL: https://issues.apache.org/jira/browse/SOLR-5147
 Project: Solr
  Issue Type: Sub-task
Reporter: Vadim Kirilchuk
Assignee: Noble Paul
 Fix For: Trunk, 5.1

 Attachments: SOLR-5147-5x.patch, SOLR-5147.patch, SOLR-5147.patch, 
 dih-oome-fix.patch


 DIH should be able to index hierarchical documents, i.e. it should be able to 
 work with SolrInputDocuments#addChildDocument.
 There was patch in SOLR-3076: 
 https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch
 But it is not uptodate and far from being complete.



--
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: [VOTE] 5.0.0 RC2

2015-02-10 Thread Alan Woodward

+1

SUCCESS! [0:48:00.712689]

Alan Woodward
www.flax.co.uk


On 10 Feb 2015, at 03:20, Steve Rowe wrote:

 +1
 
 SUCCESS! [0:54:06.294759]
 
 Steve
 
 On Feb 9, 2015, at 6:16 PM, Anshum Gupta ans...@anshumgupta.net wrote:
 
 Please vote for the second release candidate for Lucene/Solr 5.0.0.
 
 The artifacts can be downloaded here:
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469
 
 Or you can run the smoke tester directly with this command:
 python3.2 dev-tools/scripts/smokeTestRelease.py 
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469
 
 
 I could not get the above command to work as downloading some file or the 
 other timed out for me (over 6 attempts) so I instead downloaded the entire 
 RC as a tgz. I still have it here:
 
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469.tgz
 
 Untar the above folder at a location of choice. Do not change the name of 
 the folder as the smokeTestRelease.py extracts information from that.
 
 and then instead of using http, used file://. Here's the command:
 
 python3.2 dev-tools/scripts/smokeTestRelease.py 
 file://path_to_the_extracted_folder
 
 and finally, here's my +1:
 
 SUCCESS! [0:30:50.246761]
 
 
 -- 
 Anshum Gupta
 http://about.me/anshumgupta
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 


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

[jira] [Commented] (SOLR-7076) TikaEntityProcessor should have support for onError=skip


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

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

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

SOLR-7076: TikaEntityProcessor should have support for onError=skip

 TikaEntityProcessor should have support for onError=skip
 

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

 Attachments: SOLR-7076.patch, SOLR-7076.patch


 There is no reason why we can't continue if one doc failed



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

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

[jira] [Updated] (SOLR-5507) Admin UI - Refactoring using AngularJS

2015-02-10 Thread Upayavira (JIRA)


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

Upayavira updated SOLR-5507:

Attachment: SOLR5507.patch.gz

Cloud tab is almost there. Just need to complete the 'debug/dump' and clipboard 
copying.

 Admin UI - Refactoring using AngularJS
 --

 Key: SOLR-5507
 URL: https://issues.apache.org/jira/browse/SOLR-5507
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Erick Erickson
Priority: Minor
 Attachments: SOLR-5507.patch, SOLR5507.patch, SOLR5507.patch, 
 SOLR5507.patch, SOLR5507.patch, SOLR5507.patch, SOLR5507.patch, 
 SOLR5507.patch.gz, SOLR5507.patch.gz


 On the LSR in Dublin, i've talked again to [~upayavira] and this time we 
 talked about Refactoring the existing UI - using AngularJS: providing (more, 
 internal) structure and what not ;
 He already started working on the Refactoring, so this is more a 'tracking' 
 issue about the progress he/we do there.
 Will extend this issue with a bit more context  additional information, w/ 
 thoughts about the possible integration in the existing UI and more (:



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

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

[jira] [Resolved] (SOLR-7076) TikaEntityProcessor should have support for onError=skip

2015-02-10 Thread Noble Paul (JIRA)


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

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

 TikaEntityProcessor should have support for onError=skip
 

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

 Attachments: SOLR-7076.patch, SOLR-7076.patch


 There is no reason why we can't continue if one doc failed



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

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

[jira] [Comment Edited] (SOLR-5507) Admin UI - Refactoring using AngularJS

2015-02-10 Thread Upayavira (JIRA)


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

Upayavira edited comment on SOLR-5507 at 2/10/15 11:34 AM:
---

Cloud tab is almost there. Just need to complete the 'debug/dump' and clipboard 
copying. (uploaded new patch)


was (Author: upayavira):
Cloud tab is almost there. Just need to complete the 'debug/dump' and clipboard 
copying.

 Admin UI - Refactoring using AngularJS
 --

 Key: SOLR-5507
 URL: https://issues.apache.org/jira/browse/SOLR-5507
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Erick Erickson
Priority: Minor
 Attachments: SOLR-5507.patch, SOLR5507.patch, SOLR5507.patch, 
 SOLR5507.patch, SOLR5507.patch, SOLR5507.patch, SOLR5507.patch, 
 SOLR5507.patch.gz, SOLR5507.patch.gz


 On the LSR in Dublin, i've talked again to [~upayavira] and this time we 
 talked about Refactoring the existing UI - using AngularJS: providing (more, 
 internal) structure and what not ;
 He already started working on the Refactoring, so this is more a 'tracking' 
 issue about the progress he/we do there.
 Will extend this issue with a bit more context  additional information, w/ 
 thoughts about the possible integration in the existing UI and more (:



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

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

[jira] [Commented] (LUCENE-6226) Allow TermScorer to expose positions, offsets and payloads

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

Robert Muir commented on LUCENE-6226:
-

Hmm, I am a little confused. I am unsure about this new enum for the low level
postings api (versus scorers).

Realistically, they are different. The new enum is a little bogus in that it
pretends to be comparable, but Offsets and Payloads and All is a mess. I don't
think we should bring this into our postings api? Maybe its ok for Scorer, but
we should keep that contained. I do think its nice to have a unified api across
them, but i don't think our codec api should suffer from problems in
scorer-land :)

And I still don't have an understanding of the proposed semantics for scorers.
If I only have documents in the index, but i ask for frequencies, what happens?
If i only have positions and ask for payloads, etc.

It can't really be consistent with postings, which return null in unsupported
cases, since returning null already has a special meaning for Weight.scorer().

Allow TermScorer to expose positions, offsets and payloads
--

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

Attachments: LUCENE-6226.patch, LUCENE-6226.patch, LUCENE-6226.patch,
LUCENE-6226.patch, LUCENE-6226.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-6226) Allow TermScorer to expose positions, offsets and payloads


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

Robert Muir commented on LUCENE-6226:
-

One solution to simplify the enum, is to drop offsets from it. No scorers or 
anything use them today, so it would eliminate the confusion and be an ordered 
enum, docs - freqs - positions - payloads.

 Allow TermScorer to expose positions, offsets and payloads
 --

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

 Attachments: LUCENE-6226.patch, LUCENE-6226.patch, LUCENE-6226.patch, 
 LUCENE-6226.patch, LUCENE-6226.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-6227) Add BooleanClause.Occur.FILTER

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

Robert Muir commented on LUCENE-6227:
-

I also personally think MUST_NOT's name is just fine. I dont think adding
something else, FILTER makes this confusing at all. I dont think we should
rename it.

Add BooleanClause.Occur.FILTER
--

Attachments: LUCENE-6227.patch, LUCENE-6227.patch, LUCENE-6227.patch,
LUCENE-6227.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-6232) Replace ValueSource context Map with a more concrete data type


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

Terry Smith commented on LUCENE-6232:
-

[~mdrob] Thanks, either would work.

 Replace ValueSource context Map with a more concrete data type
 --

 Key: LUCENE-6232
 URL: https://issues.apache.org/jira/browse/LUCENE-6232
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Mike Drob

 Inspired by LUCENE-3973
 The context object used by ValueSource and friends is a raw Map that provides 
 no type safety guarantees. In our current state, there are lots of warnings 
 about unchecked casts, raw types, and generally unsafe code from the 
 compiler's perspective.
 There are several common patterns and types of Objects that we store in the 
 context. It would be beneficial to instead use a class with typed methods for 
 get/set of Scorer, Weights, etc.



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

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

[jira] [Commented] (SOLR-6775) Creating backup snapshot null pointer exception

2015-02-10 Thread Varun Thacker (JIRA)


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

Varun Thacker commented on SOLR-6775:
-

Looking at one of the Jenkins here are the stack traces - 

{code}
[junit4] ERROR   3.52s | TestReplicationHandlerBackup.doTestBackup 
   [junit4] Throwable #1: java.io.IOException: Could not remove the 
following files (in the order of attempts):
   [junit4]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup
 E514A9DF49C1148E-001\solr-instance-001\collection1: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup
 E514A9DF49C1148E-001\solr-instance-001\collection1
   [junit4]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup
 E514A9DF49C1148E-001\solr-instance-001: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup
 E514A9DF49C1148E-001\solr-instance-001
   [junit4]at 
__randomizedtesting.SeedInfo.seed([E514A9DF49C1148E:A49F89BA6E7FE7C1]:0)
   [junit4]at org.apache.lucene.util.IOUtils.rm(IOUtils.java:294)
   [junit4]at 
org.apache.solr.handler.TestReplicationHandler$SolrInstance.tearDown(TestReplicationHandler.java:1509)
   [junit4]at 
org.apache.solr.handler.TestReplicationHandlerBackup.tearDown(TestReplicationHandlerBackup.java:115)
   [junit4]at java.lang.Thread.run(Thread.java:745)
{code}

and 
{code}
junit4]   2 NOTE: reproduce with: ant test  
-Dtestcase=TestReplicationHandlerBackup -Dtests.method=testBackupOnCommit 
-Dtests.seed=E514A9DF49C1148E -Dtests.slow=true -Dtests.locale=pt_PT 
-Dtests.timezone=Africa/Lubumbashi -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   3.18s | TestReplicationHandlerBackup.testBackupOnCommit 
   [junit4] Throwable #1: java.io.IOException: Could not remove the 
following files (in the order of attempts):
   [junit4]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup
 E514A9DF49C1148E-001\solr-instance-002\collection1: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup
 E514A9DF49C1148E-001\solr-instance-002\collection1
   [junit4]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup
 E514A9DF49C1148E-001\solr-instance-002: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandlerBackup
 E514A9DF49C1148E-001\solr-instance-002
   [junit4]at 
__randomizedtesting.SeedInfo.seed([E514A9DF49C1148E:CCFC47343639A897]:0)
   [junit4]at org.apache.lucene.util.IOUtils.rm(IOUtils.java:294)
   [junit4]at 
org.apache.solr.handler.TestReplicationHandler$SolrInstance.tearDown(TestReplicationHandler.java:1509)
   [junit4]at 
org.apache.solr.handler.TestReplicationHandlerBackup.tearDown(TestReplicationHandlerBackup.java:115)
{code}

It happened because we added this to the solrconfig files - {{str 
name=backupAftercommit/str}} which means an extra backup got created which 
we forgot to remove. I'll put up a patch to fix it.

One question though - Why doesn't it reproduce on my mac? 

 Creating backup snapshot null pointer exception
 ---

 Key: SOLR-6775
 URL: https://issues.apache.org/jira/browse/SOLR-6775
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 4.10
 Environment: Linux Server, Java version 1.7.0_21, Solr version 
 4.10.0
Reporter: Ryan Hesson
Assignee: Shalin Shekhar Mangar
  Labels: snapshot, solr
 Fix For: Trunk, 5.1

 Attachments: SOLR-6775.patch, SOLR-6775.patch


 I set up Solr Replication. I have one master on a server, one slave on 
 another server. The replication of data appears functioning correctly. The 
 issue is when the master SOLR tries to create a snapshot backup it gets a 
 null pointer exception. 
 org.apache.solr.handler.SnapShooter createSnapshot method calls 
 org.apache.solr.handler.SnapPuller.delTree(snapShotDir); at line 162 and the 
 exception happens within  org.apache.solr.handler.SnapPuller at line 1026 
 because snapShotDir is null. 
 Here is

[jira] [Resolved] (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 resolved LUCENE-6231.

Resolution: Fixed

Committed the part-2 patch to trunk, branch_5x and lucene_solr_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.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

Re: [VOTE] 5.0.0 RC2

2015-02-10 Thread Chris Hostetter


: : That part of the script expects you run from the root of a checkout.  It
: : runs the backcompat tests, and scrapes the test output to check all are
: : tested.
: 
: Everything you said made sense, and i even filed LUCENE-6234 to note that 

I tracked down the root problem to LUCENE-6235 - the regex matching on 
ant's output freaks out if you have ant configured to use the 
AnsiColorLogger.

I'm pretty sure Ryan's initial diagnoses was wrong - i don't think the 
script has any opinions about the CWD you run  it in (but i'll wait to 
Resolve:INVALID LUCENE-6234 after i've had a chance to test -- still 
waiting to see the smoke tester pass at all)


-Hoss
http://www.lucidworks.com/

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

[jira] [Commented] (SOLR-6311) SearchHandler should use path when no qt or shard.qt parameter is specified


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

Hoss Man commented on SOLR-6311:


doesn't the initParam stuff noble added improve the situation with vanity 
handler paths that have defaults? and doesn't it play nice with distibuted 
requests? (so that it only adds the defaults on the initial request, not the 
per-shard requests -- if not it should)

i think we should just bite the bullet on making the switch...

straw man:

* make behavior conditional on LUCENE_MATCH_VERSION
** if  X, shards.qt defaults to /select
** if  X, shards.qt defaults to current handler
* users who want to upgrade LUCENE_MATCH_VERSION but still get legacy behavior 
for vanity handler defaults should make hte burden of adding shards.qt=/select 
to the invariants for each of their vanity handlers

 SearchHandler should use path when no qt or shard.qt parameter is specified
 ---

 Key: SOLR-6311
 URL: https://issues.apache.org/jira/browse/SOLR-6311
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.9
Reporter: Steve Molloy
 Attachments: SOLR-6311.patch


 When performing distributed searches, you have to specify shards.qt unless 
 you're on the default /select path for your handler. As this is configurable, 
 even the default search handler could be on another path. The shard requests 
 should thus default to the path if no shards.qt was specified.



--
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-6234) harden smokeTestRelease.py's expectations regarding CWD


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

Hoss Man commented on LUCENE-6234:
--

This may be a red herring -- pretty sure the root error is: LUCENE-6235

my reading of the code is that it's running TestBackwardsCompatibility in the 
unpacked directory of a lucene-src release.  I suspect smoke tester doesn't 
actaully care anywhere about the CWD that the user initially used to run 
smokeTestRelease.py ... but i still need to test that.



 harden smokeTestRelease.py's expectations regarding CWD
 ---

 Key: LUCENE-6234
 URL: https://issues.apache.org/jira/browse/LUCENE-6234
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Hoss Man

 smokeTestRelease.py changed at some point to require/expect that you run it 
 from the root of the checkout of the branch you are smoke testing, per 
 rernst's comments in mail...
 bq. That part of the script expects you run from the root of a checkout.  It 
 runs the backcompat tests, and scrapes the test output to check all are 
 tested.
 The context was that i (out of habit from older versions of this script) was 
 trying to do this in my personal tmp space (expecting the script to create 
 it's RC specific tmp dir in the CWD)...
 {noformat}
 hossman@frisbee:~/tmp$ python3.2 
 ~/lucene/branch_5_0/dev-tools/scripts/smokeTestRelease.py 
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469
 {noformat}
 If smokeTestRelease.py is going to have expectations about it's CWD, then it 
 should either enforce those expectations (ie: do a simple assert in main() 
 that the CWD meets some expectations, and/or check $0) or it should use 
 $0 to figure out where the root svn checkout is and cd to that directory 
 itself.



--
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-6235) smokeTestRelease.py's regex for TestBackwardsCompatibility is brittle, breaks if user uses ant's ANT_ARGS

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


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

Hoss Man commented on LUCENE-6235:
--


FWIW: I tried hacking this particular ant call in smokeTestRelease.py so that 
it would a command line override for the the logger internally (independent of 
what the user's env might have) but ant won't allow that...

{noformat}
RuntimeError: ant -logger org.apache.tools.ant.DefaultLogger test 
-Dtestcase=TestBackwardsCompatibility -Dtests.verbose=true failed:
b'Only one logger class may be specified.\n'
{noformat}


 smokeTestRelease.py's regex for TestBackwardsCompatibility is brittle, breaks 
 if user uses ant's ANT_ARGS
 -

 Key: LUCENE-6235
 URL: https://issues.apache.org/jira/browse/LUCENE-6235
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Hoss Man

 smokeTestRelease.py has always exec'ed ant on source releases to smoke 
 check the build - but the changes intorduced in LUCENE-5863 also do a regex 
 over the output of the ant call to run TestBackwardsCompatibility.
 This regex doesn't play nicely however if the user has ANT_ARGS configured to 
 use an alternative logger - in particular i (and i'm guessing i'm not alone 
 among the general ant using populace) have this in my shell...
 {noformat}
 $ env | grep ANT
 ANT_HOME=/opt/ant/default/
 ANT_ARGS=-logger org.apache.tools.ant.listener.AnsiColorLogger
 {noformat}
 The AnsiColorLogger, and the control characters it outputs to color the 
 output lines, seems to break the regex matching for 
 TestBackwardsCompatibility's output.
 Workarround (seems to be - still testing) for smoke testers to force their 
 environment to specify the DefaultLogger...
 {noformat}
 $ ANT_ARGS='-logger org.apache.tools.ant.DefaultLogger' python3.2 
 dev-tools/scripts/smokeTestRelease.py 
 http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469
 {noformat}



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

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

[jira] [Commented] (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=14314567#comment-14314567
 ] 

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

Commit 1658774 from [~steve_rowe] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1658774 ]

LUCENE-6231: retry all downloads in smokeTestRelease.py (merged trunk r1658772)

 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,

[jira] [Commented] (SOLR-6311) SearchHandler should use path when no qt or shard.qt parameter is specified

2015-02-10 Thread Noble Paul (JIRA)


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

Noble Paul commented on SOLR-6311:
--

[~hossman] 
With InitParams , the behavior is exacly similar as if we have specified the 
the config in the requestHandler itself

But, as you said, I expect users to configure a lot more paths with the 
useParams feature with each mapping to a SearchHandler itself but a different 
set of params and a nice descriptive name. Coupled with the fact that you can 
change the params themselves pretty easily it will be more common. So you may 
see paths like {{/bestproducts-by-rating}} {{/best-products-by-sale}} etc. 

So it should not really hurt moving to shards.qt=qt




 SearchHandler should use path when no qt or shard.qt parameter is specified
 ---

 Key: SOLR-6311
 URL: https://issues.apache.org/jira/browse/SOLR-6311
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.9
Reporter: Steve Molloy
 Attachments: SOLR-6311.patch


 When performing distributed searches, you have to specify shards.qt unless 
 you're on the default /select path for your handler. As this is configurable, 
 even the default search handler could be on another path. The shard requests 
 should thus default to the path if no shards.qt was specified.



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

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

[jira] [Created] (LUCENE-6235) smokeTestRelease.py's regex for TestBackwardsCompatibility is brittle, breaks if user uses ant's ANT_ARGS

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

Hoss Man created LUCENE-6235:


 Summary: smokeTestRelease.py's regex for 
TestBackwardsCompatibility is brittle, breaks if user uses ant's ANT_ARGS
 Key: LUCENE-6235
 URL: https://issues.apache.org/jira/browse/LUCENE-6235
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Hoss Man


smokeTestRelease.py has always exec'ed ant on source releases to smoke check 
the build - but the changes intorduced in LUCENE-5863 also do a regex over the 
output of the ant call to run TestBackwardsCompatibility.

This regex doesn't play nicely however if the user has ANT_ARGS configured to 
use an alternative logger - in particular i (and i'm guessing i'm not alone 
among the general ant using populace) have this in my shell...

{noformat}
$ env | grep ANT
ANT_HOME=/opt/ant/default/
ANT_ARGS=-logger org.apache.tools.ant.listener.AnsiColorLogger
{noformat}

The AnsiColorLogger, and the control characters it outputs to color the output 
lines, seems to break the regex matching for TestBackwardsCompatibility's 
output.

Workarround (seems to be - still testing) for smoke testers to force their 
environment to specify the DefaultLogger...

{noformat}
$ ANT_ARGS='-logger org.apache.tools.ant.DefaultLogger' python3.2 
dev-tools/scripts/smokeTestRelease.py 
http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469
{noformat}




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

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

[jira] [Commented] (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=14314562#comment-14314562
 ] 

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

Commit 1658772 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1658772 ]

LUCENE-6231: retry all downloads in smokeTestRelease.py

 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

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

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


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

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

Commit 1658775 from [~steve_rowe] in branch 'dev/branches/lucene_solr_5_0'
[ https://svn.apache.org/r1658775 ]

LUCENE-6231: retry all downloads in smokeTestRelease.py (merged trunk r1658772)

 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,

Re: [VOTE] 5.0.0 RC2

2015-02-10 Thread Timothy Potter

+1
SUCCESS! [0:31:59.118067]

Also verified the Solr bin\solr.cmd on Windows works as intended!

Great work Anshum!

On Tue, Feb 10, 2015 at 8:36 PM, Tomás Fernández Löbbe 
tomasflo...@gmail.com wrote:

 +1
 SUCCESS! [0:46:17.627920]

 On Tue, Feb 10, 2015 at 11:33 AM, Ryan Ernst r...@iernst.net wrote:

  I'm pretty sure Ryan's initial diagnoses was wrong

 Entirely possible. I just quickly looked at the script and saw ant test
 being invoked.  It would make sense on second though that it is running it
 from the downloaded source version? :)

 On Tue, Feb 10, 2015 at 11:04 AM, Chris Hostetter 
 hossman_luc...@fucit.org wrote:


 : : That part of the script expects you run from the root of a
 checkout.  It
 : : runs the backcompat tests, and scrapes the test output to check all
 are
 : : tested.
 :
 : Everything you said made sense, and i even filed LUCENE-6234 to note
 that

 I tracked down the root problem to LUCENE-6235 - the regex matching on
 ant's output freaks out if you have ant configured to use the
 AnsiColorLogger.

 I'm pretty sure Ryan's initial diagnoses was wrong - i don't think the
 script has any opinions about the CWD you run  it in (but i'll wait to
 Resolve:INVALID LUCENE-6234 after i've had a chance to test -- still
 waiting to see the smoke tester pass at all)


 -Hoss
 http://www.lucidworks.com/

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

[jira] [Updated] (SOLR-7091) Data-driven schema and block-join style update requests don't play well together