gmane.comp.jakarta.lucene.devel

[JENKINS] Lucene-trunk - Build # 1942 - Failure

Apache Jenkins Server — 2012-05-26T03:11:10

Build: https://builds.apache.org/job/Lucene-trunk/1942/

1 tests failed.
REGRESSION:  org.apache.lucene.analysis.pattern.TestPatternReplaceCharFilter.testRandomStrings

Error Message:


Stack Trace:
java.lang.AssertionError
at __randomizedtesting.SeedInfo.seed([8E91A6AC395FEED9:618A6129A5BB9EC]:0)
at org.apache.lucene.analysis.MockTokenizer.readCodePoint(MockTokenizer.java:153)
at org.apache.lucene.analysis.MockTokenizer.incrementToken(MockTokenizer.java:123)
at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:558)
at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:488)
at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:430)
at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:424)
at org.apache.lucene.analysis.pattern.TestPatternReplaceCharFilter.testRandomStrings(TestPatternReplaceCharFilter.java:323)
a

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java7-64 #129

2012-05-26T02:56:55

See <http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java7-64/129/>

------------------------------------------
[...truncated 14582 lines...]
   [junit4]   2> 37500 T3312 oasu.CommitTracker.<init> Hard AutoCommit: disabled
   [junit4]   2> 37500 T3312 oasu.CommitTracker.<init> Soft AutoCommit: disabled
   [junit4]   2> 37501 T3312 oashc.SpellCheckComponent.inform Initializing spell checkers
   [junit4]   2> 37512 T3312 oass.DirectSolrSpellChecker.init init: {name=direct,classname=DirectSolrSpellChecker,field=lowerfilt,minQueryLength=3}
   [junit4]   2> 37612 T3312 oashc.HttpShardHandlerFactory.getParameter Setting socketTimeout to: 0
   [junit4]   2> 37613 T3312 oashc.HttpShardHandlerFactory.getParameter Setting urlScheme to: http://
   [junit4]   2> 37613 T3312 oashc.HttpShardHandlerFactory.getParameter Setting connTimeout to: 0
   [junit4]   2> 37613 T3312 oashc.HttpShardHandlerFactory.getParameter Setting maxConnectionsPerHost to: 20
   [junit4]   2> 37613 T3312 oashc.HttpShardHandlerFact

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java7-64 #128

2012-05-26T01:02:01

See <http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java7-64/128/>

------------------------------------------
[...truncated 11441 lines...]
   [junit4]   2> request was:q=ac&spellcheck.count=2&qt=/suggest_tst&spellcheck.onlyMorePopular=true
   [junit4]   2> 476 T3554 oasc.SolrException.log SEVERE REQUEST FAILED: q=ac&spellcheck.count=2&qt=/suggest_tst&spellcheck.onlyMorePopular=true:java.lang.RuntimeException: REQUEST FAILED: xpath=//lst[< at >name='spellcheck']/lst[< at >name='suggestions']/lst[< at >name='ac']/int[< at >name='numFound'][.='2']
   [junit4]   2> xml response was: <?xml version="1.0" encoding="UTF-8"?>
   [junit4]   2> <response>
   [junit4]   2> <lst name="responseHeader"><int name="status">0</int><int name="QTime">1</int></lst><lst name="spellcheck"><lst name="suggestions"/></lst>
   [junit4]   2> </response>
   [junit4]   2> 
   [junit4]   2> request was:q=ac&spellcheck.count=2&qt=/suggest_tst&spellcheck.onlyMorePopular=true
   [junit4]   2> at org.apache.solr.SolrTestCaseJ4.ass

[jira] [Updated] (SOLR-3351) eDismax: ps2 and ps3 params

Jan Høydahl (JIRA — 2012-05-25T23:40:24

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

Jan Høydahl updated SOLR-3351:
------------------------------

    Attachment: SOLR-3351.patch

Patch adding ps2 and ps3 params, including test cases
                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LUCENE-2878) Allow Scorer to expose positions and payloads aka. nuke spans

Simon Willnauer (JIRA — 2012-05-25T22:50:23

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

Simon Willnauer commented on LUCENE-2878:
-----------------------------------------

bq. New patch, implementing positions() for ReqExclScorer and ReqOptSumScorer, with a couple of basic tests.
looks good! I will commit it and we can iterate further. Good to see those additional tests! 
Proximity searches are a different story and I will leave that for later. We can even add that once this is in trunk. In general we need to add a ton of testcases and straight out the api at some point but lets get all queries supporting that stuff first.
                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LUCENE-4055) Refactor SegmentInfo / FieldInfo to make them extensible

Robert Muir (JIRA — 2012-05-25T22:38:23

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

Robert Muir commented on LUCENE-4055:
-------------------------------------

{quote}
My comment was about the lack of easy extensibility of the codec-independent per-segment data (SegmentInfoPerCommit - info about stacked data is per-segment and per-commit), so LUCENE-3837 will need to use for now the codec-independent index-global data (SegmentInfos).
{quote}

Well SegmentInfos is just the list of SegmentInfoPerCommit, so I think in the case of LUCENE-3837 we would just place this data alongside the only other per-segment-per-commit data: deletes (e.g. we would add something like updatesGen and updatesCount or whatever).

Sure, we have to bump the file header and what not, but the file is so simple now in the sense its just a list of segment names, the codec to decode them, with their deletes, that it wouldn't be a big deal.

And I thin

[jira] [Commented] (SOLR-3423) HttpShardHandlerFactory does not shutdown its threadpool

Greg Bowyer (JIRA — 2012-05-25T22:36:23

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

Greg Bowyer commented on SOLR-3423:
-----------------------------------

That sounds like a better approach, do you want me to make the changes ?
                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SOLR-3423) HttpShardHandlerFactory does not shutdown its threadpool

Hoss Man (JIRA — 2012-05-25T22:28:23

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

Hoss Man commented on SOLR-3423:
--------------------------------

FWIW, since this confused me a bit...

* on trunk...
** ShardHandlerFactory has a close() method
** CoreContainer may create a ShardHandlerFactory, and closes it on shutdown
** SearchHandler may create a ShardHandlerFactory (if CoreContainer doesn't have one) and if so, then it registers a CloseHook to close it when the SearchHandler's SolrCore closes
** SOLR-3491 is another problem related to not closing ShardHandlerFactory instances in some cases, but that's unrelated to this issue.
* on 3x...
** ShardHandlerFactory doesn't define a close() method
** SearchHandler is the only thing instantiating ShardHandlerFactory
** SearchHandler doesn't do anything to clean up the resources of the ShardHandlerFactory.

(greg: did i miss anything?)

So with that in mind, it seems like:

[jira] [Updated] (SOLR-3423) HttpShardHandlerFactory does not shutdown its threadpool

Hoss Man (JIRA — 2012-05-25T22:28:23

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

Hoss Man updated SOLR-3423:
---------------------------

    Affects Version/s:     (was: 3.6.1)
                           (was: 4.0)
        Fix Version/s: 3.6.1
             Assignee: Greg Bowyer
    

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (SOLR-3491) PeerSync & SyncStrategy use an HttpShardHandlerFactory that they never close

Hoss Man (JIRA — 2012-05-25T22:03:23

Hoss Man created SOLR-3491:
------------------------------

             Summary: PeerSync & SyncStrategy use an HttpShardHandlerFactory that they never close
                 Key: SOLR-3491
                 URL: https://issues.apache.org/jira/browse/SOLR-3491
             Project: Solr
          Issue Type: Bug
            Reporter: Hoss Man
            Assignee: Yonik Seeley
            Priority: Critical
             Fix For: 4.0


Discovered while making sense of SOLR-3423...

* PeerSync & SyncStrategy each use their own private instance of HttpShardHandlerFactory, which are never close()ed (so the threadpool is never closed)
* should these classes be using the ShardHandler configured on the SolrCore

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (SOLR-3489) Config file replication less error prone

Jan Høydahl (JIRA — 2012-05-25T21:45:23

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

Jan Høydahl reassigned SOLR-3489:
---------------------------------

    Assignee: Jan Høydahl
    

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SOLR-3489) Config file replication less error prone

Jan Høydahl (JIRA — 2012-05-25T21:45:23

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

Jan Høydahl resolved SOLR-3489.
-------------------------------

    Resolution: Fixed

Thanks for reporting. You patch (which is identical with the trunk code) is committed to branch 3_6
                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (LUCENE-4055) Refactor SegmentInfo / FieldInfo to make them extensible

Andrzej Bialecki (JIRA — 2012-05-25T21:33:23

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

Andrzej Bialecki  edited comment on LUCENE-4055 at 5/25/12 9:32 PM:
--------------------------------------------------------------------

bq. stacked segments in LUCENE-3837 that need to do things other than implement encoding/decoding of segment should be above the codec level ..
Certainly, that's why it would make sense to put this extended info in SegmentInfoPerCommit and not in any file handled by Codec. My comment was about the lack of easy extensibility of the codec-independent per-segment data (SegmentInfoPerCommit - info about stacked data is per-segment and per-commit), so LUCENE-3837 will need to use for now the codec-independent index-global data (SegmentInfos). It's not ideal but not a deal breaker either, especially since we now have version info in both of these places.
                
      was (Author: ab):
    bq. stack

[jira] [Commented] (LUCENE-4055) Refactor SegmentInfo / FieldInfo to make them extensible

Andrzej Bialecki (JIRA — 2012-05-25T21:21:23

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

Andrzej Bialecki  commented on LUCENE-4055:
-------------------------------------------

bq. stacked segments in LUCENE-3837 that need to do things other than implement encoding/decoding of segment should be above the codec level ..
Certainly, that's why it would make sense to put this extended info in SegmentInfoPerCommit and not in any file handled by Codec.
                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LUCENE-4055) Refactor SegmentInfo / FieldInfo to make them extensible

Robert Muir (JIRA — 2012-05-25T20:36:23

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

Robert Muir commented on LUCENE-4055:
-------------------------------------

Right, but I think this is correct: the codec should be responsible for encode/decode of inverted index segments only (the whole problem here originally was trying to have it also look after commits).

So it really shouldn't be customizing things about the commit, as that creates a confusing impedance mismatch.

I think things like stacked segments in LUCENE-3837 that need to do things other than implement encoding/decoding of segment should be above the codec level: since its a separate concern, if someone wants to have updatable fields thats unrelated to the integer compression algorithm used or what not.

                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https:/

[jira] [Commented] (LUCENE-4055) Refactor SegmentInfo / FieldInfo to make them extensible

Andrzej Bialecki (JIRA — 2012-05-25T20:15:23

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

Andrzej Bialecki  commented on LUCENE-4055:
-------------------------------------------

+1, this looks very good.

One comment re. SegmentInfoPerCommit. This class is not extensible and contains a fixed set of attributes. In LUCENE-3837 this or similar place would be the ideal mechanism to carry info about stacked segments, since this information is specific to a commit point. Unfortunately, there are no Map<String,String> attributes on this level, so I guess for now this type of aux data will have to be put in SegmentInfos.userData even though it's not index global but segment-specific.
                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, s

Re: [JENKINS] Solr-trunk - Build # 1865 - Failure

Mark Miller — 2012-05-25T19:15:48

On May 25, 2012, at 2:07 PM, Mark Miller wrote:


But I still expected to see an ugly slowdown on many tests (eg even 30 seconds * 10 tests is a significant add).

It may be we simply have to do it in this one test though (add to the graceful exit time) - other tests don't have enough indexing occurring to cause long end merges I think.

- Mark Miller
lucidimagination.com

[jira] [Updated] (LUCENE-2878) Allow Scorer to expose positions and payloads aka. nuke spans

Alan Woodward (JIRA — 2012-05-25T18:58:23

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

Alan Woodward updated LUCENE-2878:
----------------------------------

    Attachment: LUCENE-2878.patch

New patch, implementing positions() for ReqExclScorer and ReqOptSumScorer, with a couple of basic tests.

These just return Conj/Disj PositionIterators, ignoring the excluded Scorers.  It works in the simple cases that I've got here, but they may need to be made more complex when we take proximity searches into account.
                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Jenkins build is back to normal : Lucene-Solr-trunk-Windows-Java6-64 #206

2012-05-25T18:22:42

See <http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java6-64/206/changes>

[jira] [Resolved] (LUCENE-4062) More fine-grained control over the packed integer implementation that is chosen

Michael McCandless (JIRA — 2012-05-25T18:10:25

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

Michael McCandless resolved LUCENE-4062.
----------------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 4.1)
                   4.0

Thanks Adrien!
                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [JENKINS] Solr-trunk - Build # 1865 - Failure

Mark Miller — 2012-05-25T18:07:14

On May 25, 2012, at 12:26 PM, Dawid Weiss wrote:


No, I don't think it would be that easy to make a repeatable test case, so I don't think I'll have near term time for it. This one is not really a practical issue, so low on my priority list. It repeats on jenkins on the rare occasion ;)

Jetty seems more likely than the test framework to me - IW#close happens well before the test is over, and in the main thread, and that is what is interrupted (waiting for merges to finish)...and Jetty will send an interrupt on shutdown after the graceful shutdown timeout. Increasing that timeout will drastically lessen the chances of it happening - but we start and shutdown jetty serially, and that is likely why its so much longer - some tests use a lot of jetties.

Trying to stop jetties in parallel might be one thing to try obviously. 

- Mark Miller
lucidimagination.com