date:20140105

[jira] [Commented] (SOLR-5379) Query-time multi-word synonym expansion

2014-01-05 Thread JIRA


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

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

So what is the next step with this one? Anyone who have tested it and have 
comments?

 Query-time multi-word synonym expansion
 ---

 Key: SOLR-5379
 URL: https://issues.apache.org/jira/browse/SOLR-5379
 Project: Solr
  Issue Type: Improvement
  Components: query parsers
Reporter: Tien Nguyen Manh
  Labels: multi-word, queryparser, synonym
 Fix For: 4.6, 4.7

 Attachments: quoted.patch, synonym-expander.patch


 While dealing with synonym at query time, solr failed to work with multi-word 
 synonyms due to some reasons:
 - First the lucene queryparser tokenizes user query by space so it split 
 multi-word term into two terms before feeding to synonym filter, so synonym 
 filter can't recognized multi-word term to do expansion
 - Second, if synonym filter expand into multiple terms which contains 
 multi-word synonym, The SolrQueryParseBase currently use MultiPhraseQuery to 
 handle synonyms. But MultiPhraseQuery don't work with term have different 
 number of words.
 For the first one, we can extend quoted all multi-word synonym in user query 
 so that lucene queryparser don't split it. There are a jira task related to 
 this one https://issues.apache.org/jira/browse/LUCENE-2605.
 For the second, we can replace MultiPhraseQuery by an appropriate BoleanQuery 
 SHOULD which contains multiple PhraseQuery in case tokens stream have 
 multi-word synonym.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

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

2014-01-05 Thread Erik Hatcher (JIRA)


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

Erik Hatcher commented on SOLR-5507:


Just for the record, the VelocityResponseWriter has always supported templates 
coming from the resource loader, meaning that templates can be packaged into 
plugin .jar files and they are then accessible by name using the v.template 
parameter.  The idea was to allow 3rd party plugins to ship with UI as well as 
behavior.

 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: Stefan Matheis (steffkes)
Priority: Minor

 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.1.5#6160)

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

lucene-solr pull request: change the default of hl.phraseLimit to 5000 per ...

2014-01-05 Thread mdellabitta

Github user mdellabitta closed the pull request at:

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


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

[jira] [Commented] (SOLR-2794) change the default of hl.phraseLimit to 5000

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 156 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r156 ]

SOLR-2794: update changes with issue no. This closes #11 on github.

 change the default of hl.phraseLimit to 5000
 

 Key: SOLR-2794
 URL: https://issues.apache.org/jira/browse/SOLR-2794
 Project: Solr
  Issue Type: Improvement
  Components: highlighter
Affects Versions: 3.4, 4.0-ALPHA
Reporter: Koji Sekiguchi
Priority: Trivial
 Attachments: SOLR-2794.patch


 David Smiley suggested that the default of hl.phraseLimit parameter should be 
 5000 (5000 was suggested by Mike). See LUCENE-3234.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-2794) change the default of hl.phraseLimit to 5000

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 157 from [~thetaphi] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r157 ]

Merged revision(s) 156 from lucene/dev/trunk:
SOLR-2794: update changes with issue no. This closes #11 on github.

 change the default of hl.phraseLimit to 5000
 

 Key: SOLR-2794
 URL: https://issues.apache.org/jira/browse/SOLR-2794
 Project: Solr
  Issue Type: Improvement
  Components: highlighter
Affects Versions: 3.4, 4.0-ALPHA
Reporter: Koji Sekiguchi
Assignee: Robert Muir
Priority: Trivial
 Fix For: 4.7

 Attachments: SOLR-2794.patch


 David Smiley suggested that the default of hl.phraseLimit parameter should be 
 5000 (5000 was suggested by Mike). See LUCENE-3234.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (SOLR-2794) change the default of hl.phraseLimit to 5000

2014-01-05 Thread Uwe Schindler (JIRA)


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

Uwe Schindler resolved SOLR-2794.
-

   Resolution: Fixed
Fix Version/s: 4.7
 Assignee: Robert Muir

 change the default of hl.phraseLimit to 5000
 

 Key: SOLR-2794
 URL: https://issues.apache.org/jira/browse/SOLR-2794
 Project: Solr
  Issue Type: Improvement
  Components: highlighter
Affects Versions: 3.4, 4.0-ALPHA
Reporter: Koji Sekiguchi
Assignee: Robert Muir
Priority: Trivial
 Fix For: 4.7

 Attachments: SOLR-2794.patch


 David Smiley suggested that the default of hl.phraseLimit parameter should be 
 5000 (5000 was suggested by Mike). See LUCENE-3234.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[GitHub] uschindler commented on a pull request (change the default of hl.phraseLimit to 5000 per SOLR-2794.) on GitHub

2014-01-05 Thread ASF Git Services

uschindler has made a comment on pull request no. 11: change the default of 
hl.phraseLimit to 5000 per SOLR-2794.

Link:   https://github.com/apache/lucene-solr/pull/11
Author: uschindler ( https://github.com/uschindler )

This is a test comment to check if comments arrive at dev@lao mailing list.


With regards,
ASF Git Services

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

[jira] [Resolved] (SOLR-5577) indexing delay due to zookeeper election

2014-01-05 Thread Mark Miller (JIRA)


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

Mark Miller resolved SOLR-5577.
---

Resolution: Fixed

Thanks Christine!

 indexing delay due to zookeeper election
 

 Key: SOLR-5577
 URL: https://issues.apache.org/jira/browse/SOLR-5577
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Christine Poerschke
Assignee: Mark Miller
 Fix For: 5.0, 4.7, 4.6.1

 Attachments: SOLR-5577.patch


 The behaviour we observed was that a zookeeper election took about 2s plus 
 1.5s for reading the zoo_data snapshot. During this time solr tried to 
 establish connections to any zookeeper in the ensemble but only succeeded 
 once a leader was elected *and* that leader was done reading the snapshot. 
 Solr document updates were slowed down during this time window.
 Is this expected to happen during and shortly after elections, that is 
 zookeeper closing existing connections, rejecting new connections and thus 
 stalling solr updates?
 Other than avoiding zookeeper elections, are there ways of reducing their 
 impact on solr?
 +zookeeper log extract+
 {noformat}
 08:18:54,968 [QuorumCnxManager.java:762] Connection broken for id ...
 08:18:56,916 [Leader.java:345] LEADING - LEADER ELECTION TOOK - 1941
 08:18:56,918 [FileSnap.java:83] Reading snapshot ...
 ...
 08:18:57,010 [NIOServerCnxnFactory.java:197] Accepted socket connection from 
 ...
 08:18:57,010 [NIOServerCnxn.java:354] Exception causing close of session 0x0 
 due to java.io.IOException: ZooKeeperServer not running
 08:18:57,010 [NIOServerCnxn.java:1001] Closed socket connection for client 
 ... (no session established for client)
 ...
 08:18:58,496 [FileTxnSnapLog.java:240] Snapshotting: ... to ...
 {noformat}
 +solr log extract+
 {noformat}
 08:18:54,968 [ClientCnxn.java:1085] Unable to read additional data from 
 server sessionid ... likely server has closed socket, closing socket 
 connection and attempting reconnect
 08:18:55,068 [ConnectionManager.java:72] Watcher 
 org.apache.solr.common.cloud.ConnectionManager@... name:ZooKeeperConnection 
 Watcher:host1:port1,host2:port2,host3:port3,... got event WatchedEvent 
 state:Disconnected type:None path:null path:null type:None
 08:18:55,068 [ConnectionManager.java:132] zkClient has disconnected
 ...
 08:18:55,961 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:55,961 [ClientCnxn.java:849] Socket connection established to ...
 08:18:55,962 [ClientCnxn.java:1085] Unable to read additional data from 
 server sessionid ... likely server has closed socket, closing socket 
 connection and attempting reconnect
 ...
 08:18:56,714 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:56,715 [ClientCnxn.java:849] Socket connection established to ...
 08:18:56,715 [ClientCnxn.java:1085] Unable to read additional data from ...
 ...
 08:18:57,640 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:57,641 [ClientCnxn.java:849] Socket connection established to ...
 08:18:57,641 [ClientCnxn.java:1085] Unable to read additional data from ...
 ...
 08:18:58,352 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:58,353 [ClientCnxn.java:849] Socket connection established to ...
 08:18:58,353 [ClientCnxn.java:1085] Unable to read additional data from ...
 ...
 08:18:58,749 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:58,749 [ClientCnxn.java:849] Socket connection established to ...
 08:18:58,751 [ClientCnxn.java:1207] Session establishment complete on server 
 ... sessionid = ..., negotiated timeout = ...
 08:18:58,751 ... [ConnectionManager.java:72] Watcher 
 org.apache.solr.common.cloud.ConnectionManager@... name:ZooKeeperConnection 
 Watcher:host1:port1,host2:port2,host3:port3,... got event WatchedEvent 
 state:SyncConnected type:None path:null path:null type:None
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5590) SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some problems

2014-01-05 Thread Mark Miller (JIRA)

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

Mark Miller commented on SOLR-5590:
---

bq. It was a semi-repeatable failure

[~elyograg], can you open a JIRA issue for that if there is not one? Or point
to a failed jenkins run for that? Anything someone sees too often locally, I'm
happy to help harden.

SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some
problems
--

Key: SOLR-5590
URL: https://issues.apache.org/jira/browse/SOLR-5590
Project: Solr
Issue Type: Improvement
Affects Versions: 4.5.1
Reporter: Karl Wright
Assignee: Shawn Heisey
Attachments: SOLR-5590.patch

SolrJ depends on HttpClient 4.2.x right now, but HttpClient 4.2.x has issues
that the ManifoldCF team encountered with handling of form data encoding -
issues which are addressed in HttpClient 4.3.x. We developed a local patch,
but Solr will eventually need to go to the new client. (ManifoldCF would
plan to follow shortly thereafter).
I tried to get Oleg (PMC chair of HttpComponents) to agree to port the fixed
code to the 4.2.x stream but he did not want to do that. So I believe that
that avenue is closed.
See CONNECTORS-623 for a detailed description of the problem.

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

Test email #1

2014-01-05 Thread Policeman Jenkins Server

This is test email #1 sent from Jenkins

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

Re: The Old Git Discussion

2014-01-05 Thread Mark Miller

My point here is not really to discuss the merits of Git VS SVN on a
feature / interface basis. We might as well talk about MySQL vs Postgres.

Personally, I prefer GIT. It feels good when I use it. SVN feels like crap.
That doesn't make me want to move. I've used SVN for years with
Lucene/Solr, and like everyone, it's pretty much second nature.

The problem is the world is moving. It may not be clear to everyone yet,
but give it a bit more time and it will be.

Git already owns the open source world. It rivals SVN by most guesses in
the proprietary world. This is a strong hard trend. The same trend that saw
SVN eat CVS. I think clearly, a distributed version control system will
dominate. And clearly Git has won.

I'm not ready to call a vote, because I don't think it's critical we switch
yet. But I wanted to continue the discussion, as obviously, plenty of it
will be needed over time before we made such a switch.

It's not about one thing being better than the other. It's about using what
everyone else uses so you don't provide a barrier to contribution. It's
about the post I linked to when I started this thread.

I personally don't care about pull requests and Github. I don't think any
of it's features are that great, other than it acts as a central repo. Git
is not good because of Github IMO. But Git and Github are eating the world.

Most of the patches I have processed now are made against Git. Jumping from
SVN to Git and back is very annoying IMO though. There are plenty of tools
and workflows for it and they all suck.

Anyway, as the trend continues, it will become even more obvious that
Lucene/Solr will start looking stale on SVN. We have enough image problems
in terms of being modern at Apache. We will need to manage the ones we can.

We should not choose the tools that simply make us fuzzy and comfortable.
 We should choose the tools that are best for the project and future
contributions in the long term.

- Mark


On Sat, Jan 4, 2014 at 4:17 PM, Robert Muir rcm...@gmail.com wrote:

 On Sat, Jan 4, 2014 at 4:13 PM, Jan Høydahl jan@cominvent.com wrote:
 
  Sure, it's just another channel for contributions. We can still work
 with patch files in JIRA. There may be a few git steps (remote add, fetch,
 checkout) to pull down the remote code which takes some time getting used
 to, but all this is made up for due to Git's super-fast branching. No need
 to have a bunch of duplicate svn checkouts lying around or wait for svn to
 checkout or merge...
 

 How is it faster? It takes me 25 seconds to pull down a fresh svn
 checkout. it takes like 30 minutes to run the tests before actually
 committing.

 So, i dont think we should use git for so called speed that doesnt
 matter (please, instead of arguing for git, spend time fixing the solr
 distributed tests to not take ages and ages), or for distributed
 features that dont matter (apache has a centralized repository).

 Given that its distinct from the contributor experience and would only
 impact committers, i currently see *zero* advantages for switching to
 git, only a hell of a lot of disadvantages.

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




-- 
- Mark

[GitHub] uschindler commented on a pull request (Branch 3x) on GitHub

2014-01-05 Thread ASF Git Services

uschindler has made a comment on pull request no. 1: Branch 3x

Link:   https://github.com/apache/lucene-solr/pull/1
Author: uschindler ( https://github.com/uschindler )

Test comment. Please ignore.


With regards,
ASF Git Services

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

[GitHub] uschindler commented on a pull request (Lucene solr 3 6) on GitHub

2014-01-05 Thread ASF Git Services

uschindler has made a comment on pull request no. 4: Lucene solr 3 6

Link:   https://github.com/apache/lucene-solr/pull/4
Author: uschindler ( https://github.com/uschindler )

I have no idea if this is still up to date. If not, please close this pull 
request. Thanks.


With regards,
ASF Git Services

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

[jira] [Commented] (LUCENE-5339) Simplify the facet module APIs

2014-01-05 Thread Michael McCandless (JIRA)

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

Michael McCandless commented on LUCENE-5339:

bq. Do we need to delete the branch?

I'll delete it...

Simplify the facet module APIs
--

Key: LUCENE-5339
URL: https://issues.apache.org/jira/browse/LUCENE-5339
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 5.0, 4.7

Attachments: LUCENE-5339.patch, LUCENE-5339.patch, LUCENE-5339.patch

I'd like to explore simplifications to the facet module's APIs: I
think the current APIs are complex, and the addition of a new feature
(sparse faceting, LUCENE-5333) threatens to add even more classes
(e.g., FacetRequestBuilder). I think we can do better.
So, I've been prototyping some drastic changes; this is very
early/exploratory and I'm not sure where it'll wind up but I think the
new approach shows promise.
The big changes are:
* Instead of *FacetRequest/Params/Result, you directly instantiate
the classes that do facet counting (currently TaxonomyFacetCounts,
RangeFacetCounts or SortedSetDVFacetCounts), passing in the
SimpleFacetsCollector, and then you interact with those classes to
pull labels + values (topN under a path, sparse, specific labels).
* At index time, no more FacetIndexingParams/CategoryListParams;
instead, you make a new SimpleFacetFields and pass it the field it
should store facets + drill downs under. If you want more than
one CLI you create more than one instance of SimpleFacetFields.
* I added a simple schema, where you state which dimensions are
hierarchical or multi-valued. From this we decide how to index
the ordinals (no more OrdinalPolicy).
Sparse faceting is just another method (getAllDims), on both taxonomy
ssdv facet classes.
I haven't created a common base class / interface for all of the
search-time facet classes, but I think this may be possible/clean, and
perhaps useful for drill sideways.
All the new classes are under oal.facet.simple.*.
Lots of things that don't work yet: drill sideways, complements,
associations, sampling, partitions, etc. This is just a start ...

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_60-ea-b02) - Build # 8872 - Failure!

2014-01-05 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8872/
Java: 32bit/jdk1.7.0_60-ea-b02 -server -XX:+UseG1GC

1 tests failed.
REGRESSION:  
org.apache.lucene.analysis.miscellaneous.TestStemmerOverrideFilter.testRandomRealisticKeyword

Error Message:
term 0 expected:[a] but was:[dglaforddm]

Stack Trace:
org.junit.ComparisonFailure: term 0 expected:[a] but was:[dglaforddm]
at 
__randomizedtesting.SeedInfo.seed([75ECDD51E3533BF6:4E3F7E34A1B570EE]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:177)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:292)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:296)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:300)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:312)
at 
org.apache.lucene.analysis.miscellaneous.TestStemmerOverrideFilter.testRandomRealisticKeyword(TestStemmerOverrideFilter.java:142)
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:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
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:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[jira] [Commented] (LUCENE-5339) Simplify the facet module APIs

2014-01-05 Thread ASF subversion and git services (JIRA)

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

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

Commit 190 from [~mikemccand] in branch 'dev/branches/lucene5339'
[ https://svn.apache.org/r190 ]

LUCENE-5339: remove now dead branch (it's merged/committed to trunk)

Simplify the facet module APIs
--

Attachments: LUCENE-5339.patch, LUCENE-5339.patch, LUCENE-5339.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (LUCENE-5339) Simplify the facet module APIs

2014-01-05 Thread ASF subversion and git services (JIRA)

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

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

Commit 192 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r192 ]

LUCENE-5339: also move OrdinalReaders under taxonomy

Simplify the facet module APIs
--

Attachments: LUCENE-5339.patch, LUCENE-5339.patch, LUCENE-5339.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (LUCENE-5339) Simplify the facet module APIs

2014-01-05 Thread ASF subversion and git services (JIRA)

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

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

Commit 195 from [~mikemccand] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r195 ]

LUCENE-5339: also move OrdinalReaders under taxonomy

Simplify the facet module APIs
--

Attachments: LUCENE-5339.patch, LUCENE-5339.patch, LUCENE-5339.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5577) indexing delay due to zookeeper election

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 1555610 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1555610 ]

SOLR-5577: don't start timer thread in constructor

 indexing delay due to zookeeper election
 

 Key: SOLR-5577
 URL: https://issues.apache.org/jira/browse/SOLR-5577
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Christine Poerschke
Assignee: Mark Miller
 Fix For: 5.0, 4.7, 4.6.1

 Attachments: SOLR-5577.patch


 The behaviour we observed was that a zookeeper election took about 2s plus 
 1.5s for reading the zoo_data snapshot. During this time solr tried to 
 establish connections to any zookeeper in the ensemble but only succeeded 
 once a leader was elected *and* that leader was done reading the snapshot. 
 Solr document updates were slowed down during this time window.
 Is this expected to happen during and shortly after elections, that is 
 zookeeper closing existing connections, rejecting new connections and thus 
 stalling solr updates?
 Other than avoiding zookeeper elections, are there ways of reducing their 
 impact on solr?
 +zookeeper log extract+
 {noformat}
 08:18:54,968 [QuorumCnxManager.java:762] Connection broken for id ...
 08:18:56,916 [Leader.java:345] LEADING - LEADER ELECTION TOOK - 1941
 08:18:56,918 [FileSnap.java:83] Reading snapshot ...
 ...
 08:18:57,010 [NIOServerCnxnFactory.java:197] Accepted socket connection from 
 ...
 08:18:57,010 [NIOServerCnxn.java:354] Exception causing close of session 0x0 
 due to java.io.IOException: ZooKeeperServer not running
 08:18:57,010 [NIOServerCnxn.java:1001] Closed socket connection for client 
 ... (no session established for client)
 ...
 08:18:58,496 [FileTxnSnapLog.java:240] Snapshotting: ... to ...
 {noformat}
 +solr log extract+
 {noformat}
 08:18:54,968 [ClientCnxn.java:1085] Unable to read additional data from 
 server sessionid ... likely server has closed socket, closing socket 
 connection and attempting reconnect
 08:18:55,068 [ConnectionManager.java:72] Watcher 
 org.apache.solr.common.cloud.ConnectionManager@... name:ZooKeeperConnection 
 Watcher:host1:port1,host2:port2,host3:port3,... got event WatchedEvent 
 state:Disconnected type:None path:null path:null type:None
 08:18:55,068 [ConnectionManager.java:132] zkClient has disconnected
 ...
 08:18:55,961 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:55,961 [ClientCnxn.java:849] Socket connection established to ...
 08:18:55,962 [ClientCnxn.java:1085] Unable to read additional data from 
 server sessionid ... likely server has closed socket, closing socket 
 connection and attempting reconnect
 ...
 08:18:56,714 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:56,715 [ClientCnxn.java:849] Socket connection established to ...
 08:18:56,715 [ClientCnxn.java:1085] Unable to read additional data from ...
 ...
 08:18:57,640 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:57,641 [ClientCnxn.java:849] Socket connection established to ...
 08:18:57,641 [ClientCnxn.java:1085] Unable to read additional data from ...
 ...
 08:18:58,352 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:58,353 [ClientCnxn.java:849] Socket connection established to ...
 08:18:58,353 [ClientCnxn.java:1085] Unable to read additional data from ...
 ...
 08:18:58,749 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:58,749 [ClientCnxn.java:849] Socket connection established to ...
 08:18:58,751 [ClientCnxn.java:1207] Session establishment complete on server 
 ... sessionid = ..., negotiated timeout = ...
 08:18:58,751 ... [ConnectionManager.java:72] Watcher 
 org.apache.solr.common.cloud.ConnectionManager@... name:ZooKeeperConnection 
 Watcher:host1:port1,host2:port2,host3:port3,... got event WatchedEvent 
 state:SyncConnected type:None path:null path:null type:None
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5577) indexing delay due to zookeeper election

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 1555611 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1555611 ]

SOLR-5577: don't start timer thread in constructor

 indexing delay due to zookeeper election
 

 Key: SOLR-5577
 URL: https://issues.apache.org/jira/browse/SOLR-5577
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Christine Poerschke
Assignee: Mark Miller
 Fix For: 5.0, 4.7, 4.6.1

 Attachments: SOLR-5577.patch


 The behaviour we observed was that a zookeeper election took about 2s plus 
 1.5s for reading the zoo_data snapshot. During this time solr tried to 
 establish connections to any zookeeper in the ensemble but only succeeded 
 once a leader was elected *and* that leader was done reading the snapshot. 
 Solr document updates were slowed down during this time window.
 Is this expected to happen during and shortly after elections, that is 
 zookeeper closing existing connections, rejecting new connections and thus 
 stalling solr updates?
 Other than avoiding zookeeper elections, are there ways of reducing their 
 impact on solr?
 +zookeeper log extract+
 {noformat}
 08:18:54,968 [QuorumCnxManager.java:762] Connection broken for id ...
 08:18:56,916 [Leader.java:345] LEADING - LEADER ELECTION TOOK - 1941
 08:18:56,918 [FileSnap.java:83] Reading snapshot ...
 ...
 08:18:57,010 [NIOServerCnxnFactory.java:197] Accepted socket connection from 
 ...
 08:18:57,010 [NIOServerCnxn.java:354] Exception causing close of session 0x0 
 due to java.io.IOException: ZooKeeperServer not running
 08:18:57,010 [NIOServerCnxn.java:1001] Closed socket connection for client 
 ... (no session established for client)
 ...
 08:18:58,496 [FileTxnSnapLog.java:240] Snapshotting: ... to ...
 {noformat}
 +solr log extract+
 {noformat}
 08:18:54,968 [ClientCnxn.java:1085] Unable to read additional data from 
 server sessionid ... likely server has closed socket, closing socket 
 connection and attempting reconnect
 08:18:55,068 [ConnectionManager.java:72] Watcher 
 org.apache.solr.common.cloud.ConnectionManager@... name:ZooKeeperConnection 
 Watcher:host1:port1,host2:port2,host3:port3,... got event WatchedEvent 
 state:Disconnected type:None path:null path:null type:None
 08:18:55,068 [ConnectionManager.java:132] zkClient has disconnected
 ...
 08:18:55,961 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:55,961 [ClientCnxn.java:849] Socket connection established to ...
 08:18:55,962 [ClientCnxn.java:1085] Unable to read additional data from 
 server sessionid ... likely server has closed socket, closing socket 
 connection and attempting reconnect
 ...
 08:18:56,714 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:56,715 [ClientCnxn.java:849] Socket connection established to ...
 08:18:56,715 [ClientCnxn.java:1085] Unable to read additional data from ...
 ...
 08:18:57,640 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:57,641 [ClientCnxn.java:849] Socket connection established to ...
 08:18:57,641 [ClientCnxn.java:1085] Unable to read additional data from ...
 ...
 08:18:58,352 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:58,353 [ClientCnxn.java:849] Socket connection established to ...
 08:18:58,353 [ClientCnxn.java:1085] Unable to read additional data from ...
 ...
 08:18:58,749 [ClientCnxn.java:966] Opening socket connection to server ...
 08:18:58,749 [ClientCnxn.java:849] Socket connection established to ...
 08:18:58,751 [ClientCnxn.java:1207] Session establishment complete on server 
 ... sessionid = ..., negotiated timeout = ...
 08:18:58,751 ... [ConnectionManager.java:72] Watcher 
 org.apache.solr.common.cloud.ConnectionManager@... name:ZooKeeperConnection 
 Watcher:host1:port1,host2:port2,host3:port3,... got event WatchedEvent 
 state:SyncConnected type:None path:null path:null type:None
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

lucene-solr pull request: Fix API web link for IndexDeletionPolicy (against...

2014-01-05 Thread arafalov

Github user arafalov closed the pull request at:

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


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

lucene-solr pull request: Fixing typo in example schema: 'salves' = 'slave...

2014-01-05 Thread JackDanger

Github user JackDanger closed the pull request at:

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


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

lucene-solr pull request: Branch 3x

2014-01-05 Thread prb

Github user prb closed the pull request at:

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


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

lucene-solr pull request: Lucene solr 4 3

2014-01-05 Thread thrykol

Github user thrykol closed the pull request at:

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


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

lucene-solr pull request: Better logging of undefined field error (SOLR-307...

2014-01-05 Thread astubbs

Github user astubbs closed the pull request at:

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


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

[jira] [Created] (SOLR-5607) Repeatable TestReplicationHandler#doTestStressReplication fail.

2014-01-05 Thread Mark Miller (JIRA)

Mark Miller created SOLR-5607:
-

 Summary: Repeatable TestReplicationHandler#doTestStressReplication 
fail.
 Key: SOLR-5607
 URL: https://issues.apache.org/jira/browse/SOLR-5607
 Project: Solr
  Issue Type: Test
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 5.0, 4.7


-Dtests.seed=2EB96619C2EA2B0C



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5607) Repeatable TestReplicationHandler#doTestStressReplication fail.

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 1555623 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1555623 ]

SOLR-5607: Repeatable TestReplicationHandler#doTestStressReplication fail.

 Repeatable TestReplicationHandler#doTestStressReplication fail.
 ---

 Key: SOLR-5607
 URL: https://issues.apache.org/jira/browse/SOLR-5607
 Project: Solr
  Issue Type: Test
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 5.0, 4.7


 -Dtests.seed=2EB96619C2EA2B0C



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5607) Repeatable TestReplicationHandler#doTestStressReplication fail.

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 1555624 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1555624 ]

SOLR-5607: Repeatable TestReplicationHandler#doTestStressReplication fail.

 Repeatable TestReplicationHandler#doTestStressReplication fail.
 ---

 Key: SOLR-5607
 URL: https://issues.apache.org/jira/browse/SOLR-5607
 Project: Solr
  Issue Type: Test
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 5.0, 4.7


 -Dtests.seed=2EB96619C2EA2B0C



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (SOLR-5607) Repeatable TestReplicationHandler#doTestStressReplication fail.

2014-01-05 Thread Mark Miller (JIRA)


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

Mark Miller resolved SOLR-5607.
---

Resolution: Fixed

 Repeatable TestReplicationHandler#doTestStressReplication fail.
 ---

 Key: SOLR-5607
 URL: https://issues.apache.org/jira/browse/SOLR-5607
 Project: Solr
  Issue Type: Test
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 5.0, 4.7


 -Dtests.seed=2EB96619C2EA2B0C



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-4629) Stronger standard replication testing.

2014-01-05 Thread Mark Miller (JIRA)


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

Mark Miller updated SOLR-4629:
--

Fix Version/s: 5.0

Calling this done for now. Anything else can get it's own issue.

 Stronger standard replication testing.
 --

 Key: SOLR-4629
 URL: https://issues.apache.org/jira/browse/SOLR-4629
 Project: Solr
  Issue Type: Test
  Components: replication (java)
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 5.0, 4.7

 Attachments: 
 SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch, 
 SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch, 
 SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch, 
 SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch, 
 SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch


 I added to these tests recently, but there is a report on the list indicating 
 we may still be missing something. Most reports have been positive so far 
 after the 4.2 fixes, but I'd feel better after adding some more testing.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (SOLR-4629) Stronger standard replication testing.

2014-01-05 Thread Mark Miller (JIRA)


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

Mark Miller resolved SOLR-4629.
---

Resolution: Fixed

 Stronger standard replication testing.
 --

 Key: SOLR-4629
 URL: https://issues.apache.org/jira/browse/SOLR-4629
 Project: Solr
  Issue Type: Test
  Components: replication (java)
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 5.0, 4.7

 Attachments: 
 SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch, 
 SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch, 
 SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch, 
 SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch, 
 SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch


 I added to these tests recently, but there is a report on the list indicating 
 we may still be missing something. Most reports have been positive so far 
 after the 4.2 fixes, but I'd feel better after adding some more testing.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (LUCENE-5339) Simplify the facet module APIs

2014-01-05 Thread ASF subversion and git services (JIRA)

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

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

Commit 1555627 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1555627 ]

LUCENE-5339: also catch invalid components in *FacetField

Simplify the facet module APIs
--

Attachments: LUCENE-5339.patch, LUCENE-5339.patch, LUCENE-5339.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-4669) conf file replication can cause new index to be loaded before new core (with new configs) is loaded.

2014-01-05 Thread Mark Miller (JIRA)

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

Mark Miller commented on SOLR-4669:
---

I wonder if this is a big deal in practice. As far as I can see, it just means
the old configs search for a window with old index, the new configs search for
a window on the new index (generally, simply the old index + a bit more data).
Then you get a window of new configs, new index.

I'm not sure it's a bad tradeoff vs always creating a fully new index folder
and downloading all files (I suppose you could optimize to a local copy
operation though).

I think that would be the likely fix though. Simply force a new index dir on
this condition - you have to do a core reload regardless.

conf file replication can cause new index to be loaded before new core (with
new configs) is loaded.

Key: SOLR-4669
URL: https://issues.apache.org/jira/browse/SOLR-4669
Project: Solr
Issue Type: Bug
Reporter: Hoss Man

Unless i'm smoking crack, some behavior i noticed working on SOLR-4629
indicates that when solr replication detects both a changed index, and
changed config files, the index is copied over and put into use by the
current solr core, then the conig files are copied over, and then the solr
core is reloaded with the modified configs.
which means there is a window of time in which the new index is being
searched using the old configs -- which could have bizare consequences.

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (LUCENE-5339) Simplify the facet module APIs

2014-01-05 Thread ASF subversion and git services (JIRA)

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

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

Commit 1555628 from [~mikemccand] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1555628 ]

LUCENE-5339: also catch invalid components in *FacetField

Simplify the facet module APIs
--

Attachments: LUCENE-5339.patch, LUCENE-5339.patch, LUCENE-5339.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[JENKINS] Lucene-4x-Linux-Java6-64-test-only - Build # 9310 - Failure!

2014-01-05 Thread builder

Build: builds.flonkings.com/job/Lucene-4x-Linux-Java6-64-test-only/9310/

All tests passed

Build Log:
[...truncated 460 lines...]
   [junit4] JVM J2: stdout was not empty, see: 
/var/lib/jenkins/workspace/Lucene-4x-Linux-Java6-64-test-only/checkout/lucene/build/core/test/temp/junit4-J2-20140105_215014_101.sysout
   [junit4]  JVM J2: stdout (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  SIGSEGV (0xb) at pc=0x7f0ae101857d, pid=29877, 
tid=139683674679040
   [junit4] #
   [junit4] # JRE version: 6.0_45-b06
   [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.45-b01 mixed mode 
linux-amd64 compressed oops)
   [junit4] # Problematic frame:
   [junit4] # j  
org.apache.lucene.codecs.compressing.CompressingTermVectorsWriter.addProx(ILorg/apache/lucene/store/DataInput;Lorg/apache/lucene/store/DataInput;)V+284
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/var/lib/jenkins/workspace/Lucene-4x-Linux-Java6-64-test-only/checkout/lucene/build/core/test/J2/hs_err_pid29877.log
   [junit4] #
   [junit4] # If you would like to submit a bug report, please visit:
   [junit4] #   http://java.sun.com/webapps/bugreport/crash.jsp
   [junit4] #
   [junit4]  JVM J2: EOF 

[...truncated 971 lines...]
   [junit4] ERROR: JVM J2 ended with an exception, command line: 
/var/lib/jenkins/tools/hudson.model.JDK/Java_6_64bit_u45/jre/bin/java 
-Dtests.prefix=tests -Dtests.seed=4CE27CFE7011AEF5 -Xmx512M -Dtests.iters= 
-Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
-Dtests.postingsformat=random -Dtests.docvaluesformat=random 
-Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random 
-Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=4.7 
-Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/var/lib/jenkins/workspace/Lucene-4x-Linux-Java6-64-test-only/checkout/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true 
-Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. 
-Djava.io.tmpdir=. 
-Djunit4.tempDir=/var/lib/jenkins/workspace/Lucene-4x-Linux-Java6-64-test-only/checkout/lucene/build/core/test/temp
 
-Dclover.db.dir=/var/lib/jenkins/workspace/Lucene-4x-Linux-Java6-64-test-only/checkout/lucene/build/clover/db
 -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Djava.security.policy=/var/lib/jenkins/workspace/Lucene-4x-Linux-Java6-64-test-only/checkout/lucene/tools/junit4/tests.policy
 -Dlucene.version=4.7-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 -Dfile.encoding=UTF-8 
-classpath

[jira] [Resolved] (SOLR-5504) We need better testing for SolrCmdDistributor retry logic.

2014-01-05 Thread Mark Miller (JIRA)


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

Mark Miller resolved SOLR-5504.
---

Resolution: Fixed

 We need better testing for SolrCmdDistributor retry logic.
 --

 Key: SOLR-5504
 URL: https://issues.apache.org/jira/browse/SOLR-5504
 Project: Solr
  Issue Type: Test
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 5.0, 4.7

 Attachments: SOLR-5504.patch






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (SOLR-5552) Leader recovery process can select the wrong leader if all replicas for a shard are down and trying to recover as well as lose updates that should have been recovered.

2014-01-05 Thread Mark Miller (JIRA)


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

Mark Miller resolved SOLR-5552.
---

Resolution: Fixed

 Leader recovery process can select the wrong leader if all replicas for a 
 shard are down and trying to recover as well as lose updates that should have 
 been recovered.
 ---

 Key: SOLR-5552
 URL: https://issues.apache.org/jira/browse/SOLR-5552
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Timothy Potter
Assignee: Mark Miller
Priority: Critical
  Labels: leader, recovery
 Fix For: 5.0, 4.7, 4.6.1

 Attachments: SOLR-5552.patch, SOLR-5552.patch


 One particular issue that leads to out-of-sync shards, related to SOLR-4260
 Here's what I know so far, which admittedly isn't much:
 As cloud85 (replica before it crashed) is initializing, it enters the wait 
 process in ShardLeaderElectionContext#waitForReplicasToComeUp; this is 
 expected and a good thing.
 Some short amount of time in the future, cloud84 (leader before it crashed) 
 begins initializing and gets to a point where it adds itself as a possible 
 leader for the shard (by creating a znode under 
 /collections/cloud/leaders_elect/shard1/election), which leads to cloud85 
 being able to return from waitForReplicasToComeUp and try to determine who 
 should be the leader.
 cloud85 then tries to run the SyncStrategy, which can never work because in 
 this scenario the Jetty HTTP listener is not active yet on either node, so 
 all replication work that uses HTTP requests fails on both nodes ... PeerSync 
 treats these failures as indicators that the other replicas in the shard are 
 unavailable (or whatever) and assumes success. Here's the log message:
 2013-12-11 11:43:25,936 [coreLoadExecutor-3-thread-1] WARN 
 solr.update.PeerSync - PeerSync: core=cloud_shard1_replica1 
 url=http://cloud85:8985/solr couldn't connect to 
 http://cloud84:8984/solr/cloud_shard1_replica2/, counting as success
 The Jetty HTTP listener doesn't start accepting connections until long after 
 this process has completed and already selected the wrong leader.
 From what I can see, we seem to have a leader recovery process that is based 
 partly on HTTP requests to the other nodes, but the HTTP listener on those 
 nodes isn't active yet. We need a leader recovery process that doesn't rely 
 on HTTP requests. Perhaps, leader recovery for a shard w/o a current leader 
 may need to work differently than leader election in a shard that has 
 replicas that can respond to HTTP requests? All of what I'm seeing makes 
 perfect sense for leader election when there are active replicas and the 
 current leader fails.
 All this aside, I'm not asserting that this is the only cause for the 
 out-of-sync issues reported in this ticket, but it definitely seems like it 
 could happen in a real cluster.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (SOLR-5576) ZkController.java registerAllCoresAsDown multiple cores logic

2014-01-05 Thread Mark Miller (JIRA)


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

Mark Miller resolved SOLR-5576.
---

Resolution: Fixed

Thanks Christine!

 ZkController.java registerAllCoresAsDown multiple cores logic
 -

 Key: SOLR-5576
 URL: https://issues.apache.org/jira/browse/SOLR-5576
 Project: Solr
  Issue Type: Improvement
Reporter: Christine Poerschke
Assignee: Mark Miller
 Fix For: 5.0, 4.7, 4.6.1

 Attachments: SOLR-5576.patch


 The behaviour we saw was that considerable time elapsed between
 different cores within the same solr instance publishing themselves as down.
 Separately it appears from the code that some cores would not be published as 
 down if another core returns from the function early because it will be its
 shard leader (return vs. continue in for loop).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (SOLR-5532) SolrJ Content-Type validation is too strict for some webcontainers / proxies, breaks on equivilent content types

2014-01-05 Thread Mark Miller (JIRA)


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

Mark Miller resolved SOLR-5532.
---

Resolution: Fixed

Thanks all!

 SolrJ Content-Type validation is too strict for some webcontainers / proxies, 
 breaks on equivilent content types
 

 Key: SOLR-5532
 URL: https://issues.apache.org/jira/browse/SOLR-5532
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.6
 Environment: Windows 7, Java 1.7.0_45 (64bit), solr-solrj-4.6.0.jar
Reporter: Jakob Furrer
Assignee: Mark Miller
 Fix For: 5.0, 4.7, 4.6.1

 Attachments: SOLR-5532-elyograg-eclipse-screenshot.png, 
 SOLR-5532.patch


 due to SOLR-3530, HttpSolrServer now does a string equivilence check between 
 the Content-Type returned by the server, and a getContentTYpe() method 
 declared by the ResponseParser .. but string equivilence is too strict, and 
 can result in errors like this one reported by a user
 
 I just upgraded my Solr instance and with it I also upgraded the solrj 
 library in our custom application which sends diverse requests and queries to 
 Solr.
 I use the ping method to determine whether Solr started correctly under the 
 configured address. Since the upgrade the ping response results in an error:
 {code:xml}
 Cause: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: 
 Expected content type application/xml; charset=UTF-8 but got 
 application/xml;charset=UTF-8.
 ?xml version=1.0 encoding=UTF-8?
 response
 lst name=responseHeaderint name=status0/intint 
 name=QTime0/intlst name=paramsstr name=dfsearchtext/strstr 
 name=echoParamsall/strstr name=rows10/strstr 
 name=echoParamsall/strstr name=wtxml/strstr 
 name=version2.2/strstr name=qsolrpingquery/strstr 
 name=distribfalse/str/lst/lststr name=statusOK/str
 /response
 {code}
 The Solr application itself works fine.
 Using an older version of the solrj library than solr-solrj-4.6.0.jar (e.g. 
 solr-solrj-4.5.1.jar) in the custom application does not produce this error.
 The Exception is produced in a Code block (_HttpSolrServer.java_, method 
 _request(...)_, around. line 140) which has been introduced with version 
 4.6.0.
 Code to reproduce the error:
 {code}
 try {
   HttpSolrServer solrServer = new 
 HttpSolrServer(http://localhost:8080/Solr/collection;);
   solrServer.setParser(new XMLResponseParser()); // this line is making 
 all the difference
   solrServer.ping();
 } catch (Exception e) {
   e.printStackTrace();
 }
 {code}
 A global search for charset=UTF-8 on the source code of solrj indicates 
 that other functions besides ping might be affected as well, because there 
 are several places where application/xml; charset=UTF-8 is spelled without 
 a space after the semicolon.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (LUCENE-5376) Add a demo search server

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 1555629 from [~mikemccand] in branch 'dev/branches/lucene5376'
[ https://svn.apache.org/r1555629 ]

LUCENE-5376: sync trunk changes, cutover to new facets APIs, simplify search 
handler

 Add a demo search server
 

 Key: LUCENE-5376
 URL: https://issues.apache.org/jira/browse/LUCENE-5376
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Attachments: lucene-demo-server.tgz


 I think it'd be useful to have a demo search server for Lucene.
 Rather than being fully featured, like Solr, it would be minimal, just 
 wrapping the existing Lucene modules to show how you can make use of these 
 features in a server setting.
 The purpose is to demonstrate how one can build a minimal search server on 
 top of APIs like SearchManager, SearcherLifetimeManager, etc.
 This is also useful for finding rough edges / issues in Lucene's APIs that 
 make building a server unnecessarily hard.
 I don't think it should have back compatibility promises (except Lucene's 
 index back compatibility), so it's free to improve as Lucene's APIs change.
 As a starting point, I'll post what I built for the eating your own dog 
 food search app for Lucene's  Solr's jira issues 
 http://jirasearch.mikemccandless.com (blog: 
 http://blog.mikemccandless.com/2013/05/eating-dog-food-with-lucene.html ). It 
 uses Netty to expose basic indexing  searching APIs via JSON, but it's very 
 rough (lots nocommits).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch

2014-01-05 Thread Shawn Heisey (JIRA)

Shawn Heisey created SOLR-5608:
--

 Summary: Frequently reproducible failures in 
CollectionsAPIDistributedZkTest#testDistribSearch
 Key: SOLR-5608
 URL: https://issues.apache.org/jira/browse/SOLR-5608
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 4.7
 Environment: uname -a:
Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 GNU/Linux

java -version:
java version 1.7.0_25
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

svn info:
Path: .
Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1555600
Node Kind: directory
Schedule: normal
Last Changed Author: uschindler
Last Changed Rev: 157
Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)

Reporter: Shawn Heisey
 Fix For: 5.0, 4.7


This is what looks like the relevant piece of the failure.

{noformat}
   [junit4]   2 NOTE: reproduce with: ant test  
-Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch 
-Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT 
-Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
   [junit4] FAILURE  179s | CollectionsAPIDistributedZkTest.testDistribSearch 

   [junit4] Throwable #1: java.lang.AssertionError
   [junit4]at 
__randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
   [junit4]at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
   [junit4]at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
   [junit4]at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
   [junit4]at java.lang.Thread.run(Thread.java:724)
{noformat}

This jenkins failure looks like it may be similar:

http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch

2014-01-05 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-5608:
---

Thanks Shawn.


 Frequently reproducible failures in 
 CollectionsAPIDistributedZkTest#testDistribSearch
 -

 Key: SOLR-5608
 URL: https://issues.apache.org/jira/browse/SOLR-5608
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 4.7
 Environment: uname -a:
 Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 
 GNU/Linux
 java -version:
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 svn info:
 Path: .
 Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
 URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
 Repository Root: https://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 1555600
 Node Kind: directory
 Schedule: normal
 Last Changed Author: uschindler
 Last Changed Rev: 157
 Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
 Fix For: 5.0, 4.7


 This is what looks like the relevant piece of the failure.
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch 
 -Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT 
 -Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE  179s | CollectionsAPIDistributedZkTest.testDistribSearch 
 
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at 
 __randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
 {noformat}
 This jenkins failure looks like it may be similar:
 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Assigned] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch

2014-01-05 Thread Mark Miller (JIRA)


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

Mark Miller reassigned SOLR-5608:
-

Assignee: Mark Miller

 Frequently reproducible failures in 
 CollectionsAPIDistributedZkTest#testDistribSearch
 -

 Key: SOLR-5608
 URL: https://issues.apache.org/jira/browse/SOLR-5608
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 4.7
 Environment: uname -a:
 Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 
 GNU/Linux
 java -version:
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 svn info:
 Path: .
 Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
 URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
 Repository Root: https://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 1555600
 Node Kind: directory
 Schedule: normal
 Last Changed Author: uschindler
 Last Changed Rev: 157
 Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
 Fix For: 5.0, 4.7


 This is what looks like the relevant piece of the failure.
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch 
 -Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT 
 -Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE  179s | CollectionsAPIDistributedZkTest.testDistribSearch 
 
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at 
 __randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
 {noformat}
 This jenkins failure looks like it may be similar:
 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch

2014-01-05 Thread Shawn Heisey (JIRA)


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

Shawn Heisey updated SOLR-5608:
---

Attachment: SOLR-5608-lshw.txt
SOLR-5608-failure3.txt
SOLR-5608-failure2.txt
SOLR-5608-failure1.txt

Attaching full logs from three failures seen on this test.  They are pretty big 
files.  They use unicode character encoding and they're in Windows/DOS format, 
but the session log is from a Linux machine.  I'm also including more 
information about that Linux machine than anyone probably wanted to know.

 Frequently reproducible failures in 
 CollectionsAPIDistributedZkTest#testDistribSearch
 -

 Key: SOLR-5608
 URL: https://issues.apache.org/jira/browse/SOLR-5608
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 4.7
 Environment: uname -a:
 Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 
 GNU/Linux
 java -version:
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 svn info:
 Path: .
 Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
 URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
 Repository Root: https://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 1555600
 Node Kind: directory
 Schedule: normal
 Last Changed Author: uschindler
 Last Changed Rev: 157
 Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
 Fix For: 5.0, 4.7

 Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt, 
 SOLR-5608-failure3.txt, SOLR-5608-lshw.txt


 This is what looks like the relevant piece of the failure.
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch 
 -Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT 
 -Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE  179s | CollectionsAPIDistributedZkTest.testDistribSearch 
 
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at 
 __randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
 {noformat}
 This jenkins failure looks like it may be similar:
 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Comment Edited] (LUCENE-5372) IntArray toString has O(n^2) performance

2014-01-05 Thread Uwe Schindler (JIRA)


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

Uwe Schindler edited comment on LUCENE-5372 at 1/5/14 10:52 PM:


Here is a new patch that was created from scratch by using Eclipse search for 
java.lang.StringBuffer:
- The queryparser problems are autogen'ed code. I modified the build.xml to do 
a replacement in ParseException.java and TokenMgrError.java (queryparser module 
and solr-core)
- Some tests called StringWriter.getBuffer().toString() - this was only 
detected by forbidden-apis
- Some code parts using regex.Matcher have to use StringBuilder, because 
Matcher internally also uses this, so appendReplacement() and appendTail() have 
to stay
- I removed some useless methods in Solr's commons-csv fork. I hope we can 
remove that soon!
- In some tests, Solr used StringBuffer, but synchronization seems to be 
needed, I left untouched.

Because we *have to use StringBuffer* quite often, I did not add it to 
forbidden apis, because the exclusions would prevent other forbidden stuff in 
the excluded files to be detected.

I will commit this later and close this issue. Since the facet APIs were 
cleaned up, the original issue in IntArray disappeared, right? (the class is no 
longer there).


was (Author: thetaphi):
Here is a new patch that was created from scratch by using Eclipse search for 
java.lang.StringBuffer:
- The queryparser problems are autogen'ed code. I modified the build.xml to do 
a replacement in ParseException.java and TokenMgrError.java (queryparser module 
and solr-core)
- Some tests called StringWriter.getBuffer().toString() - this was only 
detected by forbidden-apis
- Some code parts using regex.Matcher have to use StringBuilder, because 
Matcher internally also uses this, so appendReplacement() and appendTail() have 
to stay

Because we *have to use StringBuffer* quite often, I did not add it to 
forbidden apis, because the exclusions would prevent other forbidden stuff in 
the excluded files to be detected.

I will commit this later and close this issue. Since the facet APIs were 
cleaned up, the original issue in IntArray disappeared, right? (the class is no 
longer there).

 IntArray toString has O(n^2) performance
 

 Key: LUCENE-5372
 URL: https://issues.apache.org/jira/browse/LUCENE-5372
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Reporter: Joshua Hartman
Assignee: Dawid Weiss
Priority: Minor
 Fix For: 5.0, 4.7

 Attachments: 5372-lucene5339.patch, 5372-v2.patch, 5372.patch, 
 LUCENE-5372-StringBuffer.patch, LUCENE-5372-forbidden.patch


 This is pretty minor, but I found a few issues with the toString 
 implementations while looking through the facet data structures.
 The most egregious is the use of string concatenation in the IntArray class. 
 I have fixed that using StringBuilders. I also noticed that other classes 
 were using StringBuffer instead of StringBuilder. According to the javadoc,
 This class is designed for use as a drop-in replacement for StringBuffer in 
 places where the string buffer was being used by a single thread (as is 
 generally the case). Where possible, it is recommended that this class be 
 used in preference to StringBuffer as it will be faster under most 
 implementations.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (LUCENE-5372) IntArray toString has O(n^2) performance

2014-01-05 Thread Uwe Schindler (JIRA)


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

Uwe Schindler updated LUCENE-5372:
--

Attachment: LUCENE-5372-StringBuffer.patch

Here is a new patch that was created from scratch by using Eclipse search for 
java.lang.StringBuffer:
- The queryparser problems are autogen'ed code. I modified the build.xml to do 
a replacement in ParseException.java and TokenMgrError.java (queryparser module 
and solr-core)
- Some tests called StringWriter.getBuffer().toString() - this was only 
detected by forbidden-apis
- Some code parts using regex.Matcher have to use StringBuilder, because 
Matcher internally also uses this, so appendReplacement() and appendTail() have 
to stay

Because we *have to use StringBuffer* quite often, I did not add it to 
forbidden apis, because the exclusions would prevent other forbidden stuff in 
the excluded files to be detected.

I will commit this later and close this issue. Since the facet APIs were 
cleaned up, the original issue in IntArray disappeared, right? (the class is no 
longer there).

 IntArray toString has O(n^2) performance
 

 Key: LUCENE-5372
 URL: https://issues.apache.org/jira/browse/LUCENE-5372
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Reporter: Joshua Hartman
Assignee: Dawid Weiss
Priority: Minor
 Fix For: 5.0, 4.7

 Attachments: 5372-lucene5339.patch, 5372-v2.patch, 5372.patch, 
 LUCENE-5372-StringBuffer.patch, LUCENE-5372-forbidden.patch


 This is pretty minor, but I found a few issues with the toString 
 implementations while looking through the facet data structures.
 The most egregious is the use of string concatenation in the IntArray class. 
 I have fixed that using StringBuilders. I also noticed that other classes 
 were using StringBuffer instead of StringBuilder. According to the javadoc,
 This class is designed for use as a drop-in replacement for StringBuffer in 
 places where the string buffer was being used by a single thread (as is 
 generally the case). Where possible, it is recommended that this class be 
 used in preference to StringBuffer as it will be faster under most 
 implementations.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Assigned] (LUCENE-5372) IntArray toString has O(n^2) performance

2014-01-05 Thread Uwe Schindler (JIRA)


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

Uwe Schindler reassigned LUCENE-5372:
-

Assignee: Uwe Schindler  (was: Dawid Weiss)

 IntArray toString has O(n^2) performance
 

 Key: LUCENE-5372
 URL: https://issues.apache.org/jira/browse/LUCENE-5372
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Reporter: Joshua Hartman
Assignee: Uwe Schindler
Priority: Minor
 Fix For: 5.0, 4.7

 Attachments: 5372-lucene5339.patch, 5372-v2.patch, 5372.patch, 
 LUCENE-5372-StringBuffer.patch, LUCENE-5372-forbidden.patch


 This is pretty minor, but I found a few issues with the toString 
 implementations while looking through the facet data structures.
 The most egregious is the use of string concatenation in the IntArray class. 
 I have fixed that using StringBuilders. I also noticed that other classes 
 were using StringBuffer instead of StringBuilder. According to the javadoc,
 This class is designed for use as a drop-in replacement for StringBuffer in 
 places where the string buffer was being used by a single thread (as is 
 generally the case). Where possible, it is recommended that this class be 
 used in preference to StringBuffer as it will be faster under most 
 implementations.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (LUCENE-5372) Replace StringBuffer with StringBuilder where possible, add to forbidden-apis

2014-01-05 Thread Uwe Schindler (JIRA)


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

Uwe Schindler updated LUCENE-5372:
--

Summary: Replace StringBuffer with StringBuilder where possible, add to 
forbidden-apis  (was: IntArray toString has O(n^2) performance)

 Replace StringBuffer with StringBuilder where possible, add to forbidden-apis
 -

 Key: LUCENE-5372
 URL: https://issues.apache.org/jira/browse/LUCENE-5372
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Reporter: Joshua Hartman
Assignee: Uwe Schindler
Priority: Minor
 Fix For: 5.0, 4.7

 Attachments: 5372-lucene5339.patch, 5372-v2.patch, 5372.patch, 
 LUCENE-5372-StringBuffer.patch, LUCENE-5372-forbidden.patch


 This is pretty minor, but I found a few issues with the toString 
 implementations while looking through the facet data structures.
 The most egregious is the use of string concatenation in the IntArray class. 
 I have fixed that using StringBuilders. I also noticed that other classes 
 were using StringBuffer instead of StringBuilder. According to the javadoc,
 This class is designed for use as a drop-in replacement for StringBuffer in 
 places where the string buffer was being used by a single thread (as is 
 generally the case). Where possible, it is recommended that this class be 
 used in preference to StringBuffer as it will be faster under most 
 implementations.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (LUCENE-5372) Replace StringBuffer with StringBuilder where possible, add to forbidden-apis

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 1555645 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1555645 ]

LUCENE-5372: Replace StringBuffer by StringBuilder, where possible

 Replace StringBuffer with StringBuilder where possible, add to forbidden-apis
 -

 Key: LUCENE-5372
 URL: https://issues.apache.org/jira/browse/LUCENE-5372
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Reporter: Joshua Hartman
Assignee: Uwe Schindler
Priority: Minor
 Fix For: 5.0, 4.7

 Attachments: 5372-lucene5339.patch, 5372-v2.patch, 5372.patch, 
 LUCENE-5372-StringBuffer.patch, LUCENE-5372-forbidden.patch


 This is pretty minor, but I found a few issues with the toString 
 implementations while looking through the facet data structures.
 The most egregious is the use of string concatenation in the IntArray class. 
 I have fixed that using StringBuilders. I also noticed that other classes 
 were using StringBuffer instead of StringBuilder. According to the javadoc,
 This class is designed for use as a drop-in replacement for StringBuffer in 
 places where the string buffer was being used by a single thread (as is 
 generally the case). Where possible, it is recommended that this class be 
 used in preference to StringBuffer as it will be faster under most 
 implementations.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (LUCENE-5372) Replace StringBuffer with StringBuilder where possible, add to forbidden-apis

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 1555646 from [~thetaphi] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1555646 ]

Merged revision(s) 1555645 from lucene/dev/trunk:
LUCENE-5372: Replace StringBuffer by StringBuilder, where possible

 Replace StringBuffer with StringBuilder where possible, add to forbidden-apis
 -

 Key: LUCENE-5372
 URL: https://issues.apache.org/jira/browse/LUCENE-5372
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Reporter: Joshua Hartman
Assignee: Uwe Schindler
Priority: Minor
 Fix For: 5.0, 4.7

 Attachments: 5372-lucene5339.patch, 5372-v2.patch, 5372.patch, 
 LUCENE-5372-StringBuffer.patch, LUCENE-5372-forbidden.patch


 This is pretty minor, but I found a few issues with the toString 
 implementations while looking through the facet data structures.
 The most egregious is the use of string concatenation in the IntArray class. 
 I have fixed that using StringBuilders. I also noticed that other classes 
 were using StringBuffer instead of StringBuilder. According to the javadoc,
 This class is designed for use as a drop-in replacement for StringBuffer in 
 places where the string buffer was being used by a single thread (as is 
 generally the case). Where possible, it is recommended that this class be 
 used in preference to StringBuffer as it will be faster under most 
 implementations.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (LUCENE-5372) Replace StringBuffer with StringBuilder where possible, add to forbidden-apis

2014-01-05 Thread Uwe Schindler (JIRA)


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

Uwe Schindler resolved LUCENE-5372.
---

Resolution: Fixed

Thanks Joshua!

If somebody has an idea how to add StringBuffer to forbidden without excluding 
tons of files, reopen.


One idea for forbidden-apis would be: Add some new @IgnoreForbidden 
annotation (class file, not runtime visible), which makes the forbidden-api 
checker ignore methods or classes with that ann. This would allow to ignore 
only very specific code parts! Backside: You need a JAR file while compiling 
with the annotation...

 Replace StringBuffer with StringBuilder where possible, add to forbidden-apis
 -

 Key: LUCENE-5372
 URL: https://issues.apache.org/jira/browse/LUCENE-5372
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Reporter: Joshua Hartman
Assignee: Uwe Schindler
Priority: Minor
 Fix For: 5.0, 4.7

 Attachments: 5372-lucene5339.patch, 5372-v2.patch, 5372.patch, 
 LUCENE-5372-StringBuffer.patch, LUCENE-5372-forbidden.patch


 This is pretty minor, but I found a few issues with the toString 
 implementations while looking through the facet data structures.
 The most egregious is the use of string concatenation in the IntArray class. 
 I have fixed that using StringBuilders. I also noticed that other classes 
 were using StringBuffer instead of StringBuilder. According to the javadoc,
 This class is designed for use as a drop-in replacement for StringBuffer in 
 places where the string buffer was being used by a single thread (as is 
 generally the case). Where possible, it is recommended that this class be 
 used in preference to StringBuffer as it will be faster under most 
 implementations.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

RE: [JENKINS] Lucene-4x-Linux-Java6-64-test-only - Build # 9310 - Failure!

2014-01-05 Thread Uwe Schindler

Oh, oh. This is a new one with Oracle Java 6u45. I don't think they will fix 
this, unless this also happens with Java 7.

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


 -Original Message-
 From: buil...@flonkings.com [mailto:buil...@flonkings.com]
 Sent: Sunday, January 05, 2014 9:55 PM
 To: dev@lucene.apache.org; sim...@apache.org
 Subject: [JENKINS] Lucene-4x-Linux-Java6-64-test-only - Build # 9310 -
 Failure!
 
 Build: builds.flonkings.com/job/Lucene-4x-Linux-Java6-64-test-only/9310/
 
 All tests passed
 
 Build Log:
 [...truncated 460 lines...]
[junit4] JVM J2: stdout was not empty, see:
 /var/lib/jenkins/workspace/Lucene-4x-Linux-Java6-64-test-
 only/checkout/lucene/build/core/test/temp/junit4-J2-
 20140105_215014_101.sysout
[junit4]  JVM J2: stdout (verbatim) 
[junit4] #
[junit4] # A fatal error has been detected by the Java Runtime
 Environment:
[junit4] #
[junit4] #  SIGSEGV (0xb) at pc=0x7f0ae101857d, pid=29877,
 tid=139683674679040
[junit4] #
[junit4] # JRE version: 6.0_45-b06
[junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.45-b01 mixed
 mode linux-amd64 compressed oops)
[junit4] # Problematic frame:
[junit4] # j
 org.apache.lucene.codecs.compressing.CompressingTermVectorsWriter.add
 Prox(ILorg/apache/lucene/store/DataInput;Lorg/apache/lucene/store/DataI
 nput;)V+284
[junit4] #
[junit4] # An error report file with more information is saved as:
[junit4] # /var/lib/jenkins/workspace/Lucene-4x-Linux-Java6-64-test-
 only/checkout/lucene/build/core/test/J2/hs_err_pid29877.log
[junit4] #
[junit4] # If you would like to submit a bug report, please visit:
[junit4] #   http://java.sun.com/webapps/bugreport/crash.jsp
[junit4] #
[junit4]  JVM J2: EOF 
 
 [...truncated 971 lines...]
[junit4] ERROR: JVM J2 ended with an exception, command line:
 /var/lib/jenkins/tools/hudson.model.JDK/Java_6_64bit_u45/jre/bin/java -
 Dtests.prefix=tests -Dtests.seed=4CE27CFE7011AEF5 -Xmx512M -
 Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -
 Dtests.codec=random -Dtests.postingsformat=random -
 Dtests.docvaluesformat=random -Dtests.locale=random -
 Dtests.timezone=random -Dtests.directory=random -
 Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=4.7 -
 Dtests.cleanthreads=perMethod -
 Djava.util.logging.config.file=/var/lib/jenkins/workspace/Lucene-4x-Linux-
 Java6-64-test-only/checkout/lucene/tools/junit4/logging.properties -
 Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -
 Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. -
 Djava.io.tmpdir=. -Djunit4.tempDir=/var/lib/jenkins/workspace/Lucene-4x-
 Linux-Java6-64-test-only/checkout/lucene/build/core/test/temp -
 Dclover.db.dir=/var/lib/jenkins/workspace/Lucene-4x-Linux-Java6-64-test-
 only/checkout/lucene/build/clover/db -
 Djava.security.manager=org.apache.lucene.util.TestSecurityManager -
 Djava.security.policy=/var/lib/jenkins/workspace/Lucene-4x-Linux-Java6-64-
 test-only/checkout/lucene/tools/junit4/tests.policy -Dlucene.version=4.7-
 SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -
 Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -
 Djava.awt.headless=true -Djdk.map.althashing.threshold=0 -
 Dfile.encoding=UTF-8 -classpath /var/lib/jenkins/workspace/Lucene-4x-
 Linux-Java6-64-test-only/checkout/lucene/build/test-
 framework/classes/java:/var/lib/jenkins/workspace/Lucene-4x-Linux-Java6-
 64-test-
 only/checkout/lucene/build/codecs/classes/java:/var/lib/jenkins/workspace
 /Lucene-4x-Linux-Java6-64-test-only/checkout/lucene/test-
 framework/lib/junit-4.10.jar:/var/lib/jenkins/workspace/Lucene-4x-Linux-
 Java6-64-test-only/checkout/lucene/test-framework/lib/randomizedtesting-
 runner-2.0.13.jar:/var/lib/jenkins/workspace/Lucene-4x-Linux-Java6-64-
 test-
 only/checkout/lucene/build/core/classes/java:/var/lib/jenkins/workspace/L
 ucene-4x-Linux-Java6-64-test-
 only/checkout/lucene/build/core/classes/test:/var/lib/jenkins/tools/hudson
 .tasks.Ant_AntInstallation/Ant_1.8.3/lib/ant-
 launcher.jar:/var/lib/jenkins/.ant/lib/apache-rat-tasks-
 0.8.jar:/var/lib/jenkins/.ant/lib/ivy-2.2.0.jar:/var/lib/jenkins/.ant/lib/apache-
 rat-0.8.jar:/var/lib/jenkins/.ant/lib/apache-rat-plugin-
 0.8.jar:/var/lib/jenkins/.ant/lib/apache-rat-core-
 0.8.jar:/var/lib/jenkins/.ant/lib/clover-
 2.6.3.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/Ant_1.8.3/l
 ib/ant-apache-
 regexp.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/Ant_1.8.
 3/lib/ant-
 jmf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/Ant_1.8.3/li
 b/ant-apache-
 log4j.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/Ant_1.8.3/l
 ib/ant-
 jdepend.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/Ant_1.
 8.3/lib/ant-
 swing.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/Ant_1.8.3
 /lib/ant-

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

2014-01-05 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: SOLR-5507.patch

First pass. This patch works alongside the existing UI. It:

 * brings in a basic Angular framework
 * enables the 'cores' menu
 * starts getting the main 'index' page infrastructure ready.

A lot more to come, but hopefully this gives folks an idea of what it might 
look like.

I imagine at the point where we scrap the old one and switch, we'll move all 
the files out of angular directories to one level up.

My next task is to get the index page actually working correctly. The work 
involved is really understanding what all the necessary parts are on the 
existing page, and porting it over to the new framework.

 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: Stefan Matheis (steffkes)
Priority: Minor
 Attachments: SOLR-5507.patch


 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.1.5#6160)

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

[jira] [Created] (LUCENE-5384) Analysis overview could mention clearAttributes and end

2014-01-05 Thread Benson Margulies (JIRA)

Benson Margulies created LUCENE-5384:


 Summary: Analysis overview could mention clearAttributes and end
 Key: LUCENE-5384
 URL: https://issues.apache.org/jira/browse/LUCENE-5384
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Benson Margulies
Assignee: Benson Margulies


It would be helpful to tokenizer implementors for the analysis package overview 
to mention more things. I'll supply a patch.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

lucene-solr pull request: Here is more doc for LUCENE-5384.

2014-01-05 Thread benson-basis

GitHub user benson-basis opened a pull request:

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

Here is more doc for LUCENE-5384.

Here are some additions to the analysis overview that mention the random 
data test and some of the things that it enforces.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/benson-basis/lucene-solr lucene-5384

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/12.patch


commit 31988b929087372094321f7f5075709dce024942
Author: Benson Margulies ben...@basistech.com
Date:   2014-01-06T01:02:17Z

Here is more doc for LUCENE-5384.




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

[jira] [Commented] (LUCENE-5384) Analysis overview could mention clearAttributes and end

2014-01-05 Thread Benson Margulies (JIRA)


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

Benson Margulies commented on LUCENE-5384:
--

https://github.com/apache/lucene-solr/pull/12 contains some more documentation.

Yes, this is offered under the terms of the Apache license, in case anyone is 
still uncertain as to the relationship of github pull requests to the AL.


 Analysis overview could mention clearAttributes and end
 ---

 Key: LUCENE-5384
 URL: https://issues.apache.org/jira/browse/LUCENE-5384
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Benson Margulies
Assignee: Benson Margulies

 It would be helpful to tokenizer implementors for the analysis package 
 overview to mention more things. I'll supply a patch.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-1301) Add a Solr contrib that allows for building Solr indexes via Hadoop's Map-Reduce.

2014-01-05 Thread ASF subversion and git services (JIRA)

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

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

Commit 1555647 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1555647 ]

SOLR-1301: make debugging these tests a whole lot easier by sending map reduce
job logging to std out

Add a Solr contrib that allows for building Solr indexes via Hadoop's
Map-Reduce.
-

Key: SOLR-1301
URL: https://issues.apache.org/jira/browse/SOLR-1301
Project: Solr
Issue Type: New Feature
Reporter: Andrzej Bialecki
Assignee: Mark Miller
Fix For: 5.0, 4.7

Attachments: README.txt, SOLR-1301-hadoop-0-20.patch,
SOLR-1301-hadoop-0-20.patch, SOLR-1301-maven-intellij.patch, SOLR-1301.patch,
SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch,
SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch,
SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch,
SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch,
SOLR-1301.patch, SolrRecordWriter.java, commons-logging-1.0.4.jar,
commons-logging-api-1.0.4.jar, hadoop-0.19.1-core.jar,
hadoop-0.20.1-core.jar, hadoop-core-0.20.2-cdh3u3.jar, hadoop.patch,
log4j-1.2.15.jar

This patch contains a contrib module that provides distributed indexing
(using Hadoop) to Solr EmbeddedSolrServer. The idea behind this module is
twofold:
* provide an API that is familiar to Hadoop developers, i.e. that of
OutputFormat
* avoid unnecessary export and (de)serialization of data maintained on HDFS.
SolrOutputFormat consumes data produced by reduce tasks directly, without
storing it in intermediate files. Furthermore, by using an
EmbeddedSolrServer, the indexing task is split into as many parts as there
are reducers, and the data to be indexed is not sent over the network.
Design
--
Key/value pairs produced by reduce tasks are passed to SolrOutputFormat,
which in turn uses SolrRecordWriter to write this data. SolrRecordWriter
instantiates an EmbeddedSolrServer, and it also instantiates an
implementation of SolrDocumentConverter, which is responsible for turning
Hadoop (key, value) into a SolrInputDocument. This data is then added to a
batch, which is periodically submitted to EmbeddedSolrServer. When reduce
task completes, and the OutputFormat is closed, SolrRecordWriter calls
commit() and optimize() on the EmbeddedSolrServer.
The API provides facilities to specify an arbitrary existing solr.home
directory, from which the conf/ and lib/ files will be taken.
This process results in the creation of as many partial Solr home directories
as there were reduce tasks. The output shards are placed in the output
directory on the default filesystem (e.g. HDFS). Such part-N directories
can be used to run N shard servers. Additionally, users can specify the
number of reduce tasks, in particular 1 reduce task, in which case the output
will consist of a single shard.
An example application is provided that processes large CSV files and uses
this API. It uses a custom CSV processing to avoid (de)serialization overhead.
This patch relies on hadoop-core-0.19.1.jar - I attached the jar to this
issue, you should put it in contrib/hadoop/lib.
Note: the development of this patch was sponsored by an anonymous contributor
and approved for release under Apache License.

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-1301) Add a Solr contrib that allows for building Solr indexes via Hadoop's Map-Reduce.

2014-01-05 Thread Mark Miller (JIRA)

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

Mark Miller commented on SOLR-1301:
---

Bah - I think the above commit only works on map reduce one as far as sending
the logs to std out. Tried to write some code to do it for map reduce 2, but I
have not been able to figure out how to programmaticly get the secret key to
hash the request url for the http logs API.

Add a Solr contrib that allows for building Solr indexes via Hadoop's
Map-Reduce.
-

Key: SOLR-1301
URL: https://issues.apache.org/jira/browse/SOLR-1301
Project: Solr
Issue Type: New Feature
Reporter: Andrzej Bialecki
Assignee: Mark Miller
Fix For: 5.0, 4.7

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 1555659 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1555659 ]

SOLR-5608: Don't allow a closed SolrCore to publish state to ZooKeeper.

 Frequently reproducible failures in 
 CollectionsAPIDistributedZkTest#testDistribSearch
 -

 Key: SOLR-5608
 URL: https://issues.apache.org/jira/browse/SOLR-5608
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 4.7
 Environment: uname -a:
 Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 
 GNU/Linux
 java -version:
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 svn info:
 Path: .
 Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
 URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
 Repository Root: https://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 1555600
 Node Kind: directory
 Schedule: normal
 Last Changed Author: uschindler
 Last Changed Rev: 157
 Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
 Fix For: 5.0, 4.7

 Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt, 
 SOLR-5608-failure3.txt, SOLR-5608-lshw.txt


 This is what looks like the relevant piece of the failure.
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch 
 -Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT 
 -Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE  179s | CollectionsAPIDistributedZkTest.testDistribSearch 
 
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at 
 __randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
 {noformat}
 This jenkins failure looks like it may be similar:
 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 1555660 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1555660 ]

SOLR-5608: Don't allow a closed SolrCore to publish state to ZooKeeper.

 Frequently reproducible failures in 
 CollectionsAPIDistributedZkTest#testDistribSearch
 -

 Key: SOLR-5608
 URL: https://issues.apache.org/jira/browse/SOLR-5608
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 4.7
 Environment: uname -a:
 Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 
 GNU/Linux
 java -version:
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 svn info:
 Path: .
 Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
 URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
 Repository Root: https://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 1555600
 Node Kind: directory
 Schedule: normal
 Last Changed Author: uschindler
 Last Changed Rev: 157
 Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
 Fix For: 5.0, 4.7

 Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt, 
 SOLR-5608-failure3.txt, SOLR-5608-lshw.txt


 This is what looks like the relevant piece of the failure.
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch 
 -Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT 
 -Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE  179s | CollectionsAPIDistributedZkTest.testDistribSearch 
 
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at 
 __randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
 {noformat}
 This jenkins failure looks like it may be similar:
 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 1555661 from [~markrmil...@gmail.com] in branch 
'dev/branches/lucene_solr_4_6'
[ https://svn.apache.org/r1555661 ]

SOLR-5608: Don't allow a closed SolrCore to publish state to ZooKeeper.

 Frequently reproducible failures in 
 CollectionsAPIDistributedZkTest#testDistribSearch
 -

 Key: SOLR-5608
 URL: https://issues.apache.org/jira/browse/SOLR-5608
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 4.7
 Environment: uname -a:
 Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 
 GNU/Linux
 java -version:
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 svn info:
 Path: .
 Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
 URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
 Repository Root: https://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 1555600
 Node Kind: directory
 Schedule: normal
 Last Changed Author: uschindler
 Last Changed Rev: 157
 Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
 Fix For: 5.0, 4.7

 Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt, 
 SOLR-5608-failure3.txt, SOLR-5608-lshw.txt


 This is what looks like the relevant piece of the failure.
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch 
 -Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT 
 -Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE  179s | CollectionsAPIDistributedZkTest.testDistribSearch 
 
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at 
 __randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
 {noformat}
 This jenkins failure looks like it may be similar:
 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch

2014-01-05 Thread Mark Miller (JIRA)


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

Mark Miller updated SOLR-5608:
--

Fix Version/s: 4.6.1

 Frequently reproducible failures in 
 CollectionsAPIDistributedZkTest#testDistribSearch
 -

 Key: SOLR-5608
 URL: https://issues.apache.org/jira/browse/SOLR-5608
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 4.7
 Environment: uname -a:
 Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 
 GNU/Linux
 java -version:
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 svn info:
 Path: .
 Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
 URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
 Repository Root: https://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 1555600
 Node Kind: directory
 Schedule: normal
 Last Changed Author: uschindler
 Last Changed Rev: 157
 Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
 Fix For: 5.0, 4.7, 4.6.1

 Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt, 
 SOLR-5608-failure3.txt, SOLR-5608-lshw.txt


 This is what looks like the relevant piece of the failure.
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch 
 -Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT 
 -Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE  179s | CollectionsAPIDistributedZkTest.testDistribSearch 
 
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at 
 __randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
 {noformat}
 This jenkins failure looks like it may be similar:
 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 1555685 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1555685 ]

SOLR-5608: Unregister core from cloud state after closing in unload.

 Frequently reproducible failures in 
 CollectionsAPIDistributedZkTest#testDistribSearch
 -

 Key: SOLR-5608
 URL: https://issues.apache.org/jira/browse/SOLR-5608
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 4.7
 Environment: uname -a:
 Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 
 GNU/Linux
 java -version:
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 svn info:
 Path: .
 Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
 URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
 Repository Root: https://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 1555600
 Node Kind: directory
 Schedule: normal
 Last Changed Author: uschindler
 Last Changed Rev: 157
 Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
 Fix For: 5.0, 4.7, 4.6.1

 Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt, 
 SOLR-5608-failure3.txt, SOLR-5608-lshw.txt


 This is what looks like the relevant piece of the failure.
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch 
 -Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT 
 -Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE  179s | CollectionsAPIDistributedZkTest.testDistribSearch 
 
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at 
 __randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
 {noformat}
 This jenkins failure looks like it may be similar:
 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 1555686 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1555686 ]

SOLR-5608: Unregister core from cloud state after closing in unload.

 Frequently reproducible failures in 
 CollectionsAPIDistributedZkTest#testDistribSearch
 -

 Key: SOLR-5608
 URL: https://issues.apache.org/jira/browse/SOLR-5608
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 4.7
 Environment: uname -a:
 Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 
 GNU/Linux
 java -version:
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 svn info:
 Path: .
 Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
 URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
 Repository Root: https://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 1555600
 Node Kind: directory
 Schedule: normal
 Last Changed Author: uschindler
 Last Changed Rev: 157
 Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
 Fix For: 5.0, 4.7, 4.6.1

 Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt, 
 SOLR-5608-failure3.txt, SOLR-5608-lshw.txt


 This is what looks like the relevant piece of the failure.
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch 
 -Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT 
 -Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE  179s | CollectionsAPIDistributedZkTest.testDistribSearch 
 
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at 
 __randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
 {noformat}
 This jenkins failure looks like it may be similar:
 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch

2014-01-05 Thread ASF subversion and git services (JIRA)


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

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

Commit 1555687 from [~markrmil...@gmail.com] in branch 
'dev/branches/lucene_solr_4_6'
[ https://svn.apache.org/r1555687 ]

SOLR-5608: Unregister core from cloud state after closing in unload.

 Frequently reproducible failures in 
 CollectionsAPIDistributedZkTest#testDistribSearch
 -

 Key: SOLR-5608
 URL: https://issues.apache.org/jira/browse/SOLR-5608
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 4.7
 Environment: uname -a:
 Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 
 GNU/Linux
 java -version:
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 svn info:
 Path: .
 Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
 URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
 Repository Root: https://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 1555600
 Node Kind: directory
 Schedule: normal
 Last Changed Author: uschindler
 Last Changed Rev: 157
 Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
 Fix For: 5.0, 4.7, 4.6.1

 Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt, 
 SOLR-5608-failure3.txt, SOLR-5608-lshw.txt


 This is what looks like the relevant piece of the failure.
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch 
 -Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT 
 -Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE  179s | CollectionsAPIDistributedZkTest.testDistribSearch 
 
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at 
 __randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
 {noformat}
 This jenkins failure looks like it may be similar:
 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch

2014-01-05 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-5608:
---

Hopefully the two above changes takes care of this.

 Frequently reproducible failures in 
 CollectionsAPIDistributedZkTest#testDistribSearch
 -

 Key: SOLR-5608
 URL: https://issues.apache.org/jira/browse/SOLR-5608
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 4.7
 Environment: uname -a:
 Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 
 GNU/Linux
 java -version:
 java version 1.7.0_25
 Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
 Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
 svn info:
 Path: .
 Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
 URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
 Repository Root: https://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 1555600
 Node Kind: directory
 Schedule: normal
 Last Changed Author: uschindler
 Last Changed Rev: 157
 Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
 Fix For: 5.0, 4.7, 4.6.1

 Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt, 
 SOLR-5608-failure3.txt, SOLR-5608-lshw.txt


 This is what looks like the relevant piece of the failure.
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch 
 -Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT 
 -Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE  179s | CollectionsAPIDistributedZkTest.testDistribSearch 
 
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at 
 __randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at 
 org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
 {noformat}
 This jenkins failure looks like it may be similar:
 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (LUCENE-5384) Analysis overview could mention clearAttributes and end

2014-01-05 Thread Uwe Schindler (JIRA)


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

Uwe Schindler commented on LUCENE-5384:
---

Hi Benson,
thank you for the patch! I would suggest to change the sentence that mentions 
clearAttributes() to be more clear, some ideas:
- every Tokenizer must call clearAttributes (as we have already in the text)
- every TokenFilter that inserts new tokens into the stream must also call 
clearAttributes(). Alternatively use captureState()/restoreState() to clone the 
previous token and modify it afterwards (this is the recommended way to insert 
tokens from TokenFilters).

Uwe

 Analysis overview could mention clearAttributes and end
 ---

 Key: LUCENE-5384
 URL: https://issues.apache.org/jira/browse/LUCENE-5384
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Benson Margulies
Assignee: Benson Margulies

 It would be helpful to tokenizer implementors for the analysis package 
 overview to mention more things. I'll supply a patch.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

67 matches

Mail list logo