date:20120214

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12415/

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

Error Message:
ERROR: SolrIndexSearcher opens=101 closes=100

Stack Trace:
junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=101 
closes=100
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:152)
at 
org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:76)


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

Error Message:
ERROR: SolrIndexSearcher opens=13 closes=12

Stack Trace:
junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=13 
closes=12
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:152)
at 
org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:76)




Build Log (for compile errors):
[...truncated 7587 lines...]



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

[jira] [Assigned] (LUCENE-3777) trapping overloaded ctors/setters in Field/NumericField/DocValuesField

2012-02-14 Thread Michael McCandless (Assigned) (JIRA)


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

Michael McCandless reassigned LUCENE-3777:
--

Assignee: Michael McCandless

 trapping overloaded ctors/setters in Field/NumericField/DocValuesField
 --

 Key: LUCENE-3777
 URL: https://issues.apache.org/jira/browse/LUCENE-3777
 Project: Lucene - Java
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir
Assignee: Michael McCandless
Priority: Blocker

 In trunk, these apis let you easily create a field, but my concern is this:
 {code}
 public NumericField(String name, int value)
 public NumericField(String name, long value)
 ..
 public Field(String name, int value, FieldType type)
 public Field(String name, long value, FieldType type)
 ..
 public void setValue(int value)
 public void setValue(long value)
 ..
 public DocValuesField(String name, int value, DocValues.Type docValueType)
 public DocValuesField(String name, long value, DocValues.Type docValueType)
 {code}
 I really don't like overloaded ctors/setters where the compiler can 
 type-promote you,
 I think it makes the apis hard to use.
 Instead for the setters I think we sohuld have setIntValue, setLongValue, ...
 For the ctors, I see two other options:
 # factories like DocValuesField.newIntField()
 # subclasses like IntField
 I don't have any patch for this, but I think we should discuss and fix before 
 these apis are released.

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



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

[jira] [Updated] (SOLR-3005) Content-Type disappear

2012-02-14 Thread Chris Male (Updated) (JIRA)


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

Chris Male updated SOLR-3005:
-

Affects Version/s: 4.0

 Content-Type disappear
 --

 Key: SOLR-3005
 URL: https://issues.apache.org/jira/browse/SOLR-3005
 Project: Solr
  Issue Type: Bug
  Components: Response Writers
Affects Versions: 3.5, 4.0
 Environment: Solr 3.5.0
Reporter: Gasol Wu
Assignee: Chris Male
 Attachments: SOLR-3005.patch, SOLR-3005.patch


 i expect that query always return Content-Type, but after SOLR-1123 had 
 committed, it got chance to return nothing if you leave out all of 
 queryResponseWriter in solrconfig.xml. however i attach a small patch that 
 will correct this situation.
 It look like DEFAULT_RESPONSE_WRITERS never called init method in 
 org.apache.solr.core.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



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

[jira] [Resolved] (SOLR-3005) Content-Type disappear

2012-02-14 Thread Chris Male (Resolved) (JIRA)


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

Chris Male resolved SOLR-3005.
--

   Resolution: Fixed
Fix Version/s: 4.0
   3.6

3x: Committed revision 1243874

 Content-Type disappear
 --

 Key: SOLR-3005
 URL: https://issues.apache.org/jira/browse/SOLR-3005
 Project: Solr
  Issue Type: Bug
  Components: Response Writers
Affects Versions: 3.5, 4.0
 Environment: Solr 3.5.0
Reporter: Gasol Wu
Assignee: Chris Male
 Fix For: 3.6, 4.0

 Attachments: SOLR-3005.patch, SOLR-3005.patch


 i expect that query always return Content-Type, but after SOLR-1123 had 
 committed, it got chance to return nothing if you leave out all of 
 queryResponseWriter in solrconfig.xml. however i attach a small patch that 
 will correct this situation.
 It look like DEFAULT_RESPONSE_WRITERS never called init method in 
 org.apache.solr.core.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



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

[jira] [Updated] (LUCENE-3731) Create a analysis/uima module for UIMA based tokenizers/analyzers

2012-02-14 Thread Tommaso Teofili (Updated) (JIRA)


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

Tommaso Teofili updated LUCENE-3731:


Attachment: LUCENE-3731_4.patch

patch with finalOffset setting in the end() method.

 Create a analysis/uima module for UIMA based tokenizers/analyzers
 -

 Key: LUCENE-3731
 URL: https://issues.apache.org/jira/browse/LUCENE-3731
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/analysis
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3731.patch, LUCENE-3731_2.patch, 
 LUCENE-3731_3.patch, LUCENE-3731_4.patch


 As discussed in SOLR-3013 the UIMA Tokenizers/Analyzer should be refactored 
 out in a separate module (modules/analysis/uima) as they can be used in plain 
 Lucene. Then the solr/contrib/uima will contain only the related factories.

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



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

[jira] [Commented] (LUCENE-3758) Allow the ComplexPhraseQueryParser to search order or un-order proximity queries.

2012-02-14 Thread Dmitry Kan (Commented) (JIRA)


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

Dmitry Kan commented on LUCENE-3758:


Hello!

If I were to implement two different versions of span near queries: with order 
and without order, would this class be the right point to start?
I'm thinking to add support for new query operator that would support order of 
terms in the near query, as (if I correctly understand), ~ operator doesn't 
preserve the order.

 Allow the ComplexPhraseQueryParser to search order or un-order proximity 
 queries.
 -

 Key: LUCENE-3758
 URL: https://issues.apache.org/jira/browse/LUCENE-3758
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/queryparser
Affects Versions: 4.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Fix For: 4.0

 Attachments: LUCENE-3758.patch


 The ComplexPhraseQueryParser use SpanNearQuery, but always set the inOrder 
 value hardcoded to true. This could be configurable.

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



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

[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12417 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12417/

1 tests failed.
REGRESSION:  org.apache.solr.cloud.FullSolrCloudTest.testDistribSearch

Error Message:
http://localhost:51425/solr/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
http://localhost:51425/solr/collection1
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:481)
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:251)
at 
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:104)
at 
org.apache.solr.cloud.FullSolrCloudTest.index_specific(FullSolrCloudTest.java:498)
at 
org.apache.solr.cloud.FullSolrCloudTest.brindDownShardIndexSomeDocsAndRecover(FullSolrCloudTest.java:745)
at 
org.apache.solr.cloud.FullSolrCloudTest.doTest(FullSolrCloudTest.java:550)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:663)
at 
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:700)
at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:599)
at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:504)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:562)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:146)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
at 
org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at 
org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
at 
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1413)
at 
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
at 
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
at 
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:425)




Build Log (for compile errors):
[...truncated 8760 lines...]



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

[jira] [Commented] (LUCENE-3762) Upgrade JUnit to 4.10, refactor state-machine of detecting setUp/tearDown call chaining.

2012-02-14 Thread Dawid Weiss (Commented) (JIRA)


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

Dawid Weiss commented on LUCENE-3762:
-

I've committed to the trunk and I have a backport of this but I started to 
wonder if it's a good idea to apply it on 3x -- this may cause issues with 
backport testing, if not anything else. Thoughts?

 Upgrade JUnit to 4.10, refactor state-machine of detecting setUp/tearDown 
 call chaining.
 

 Key: LUCENE-3762
 URL: https://issues.apache.org/jira/browse/LUCENE-3762
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3762.patch, LUCENE-3762.patch, LUCENE-3762.patch


 Both Lucene and Solr use JUnit 4.7. I suggest we move forward and upgrade to 
 JUnit 4.10 which provides several infrastructural changes (serializable 
 Description objects, class-level rules, various tweaks). JUnit 4.10 also 
 changes (or fixes, depends how you look at it) the order in which 
 @Before/@After hooks and @Rules are applied. This makes the old state-machine 
 in LuceneTestCase fail (because the order is changed).
 I rewrote the state machine and used a different, I think simpler, although 
 Uwe may disagree :), mechanism in which the hook methods setUp/ tearDown are 
 still there, but they are empty at the top level and serve only to detect 
 whether subclasses chain super.setUp/tearDown properly (if they override 
 anything).
 In the long term, I would love to just get rid of public setup/teardown 
 methods and make them private (so that they cannot be overriden or even seen 
 by subclasses) but this will require changes to the runner itself.

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



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

[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1731 - Still Failing

2012-02-14 Thread Martijn van Groningen (Created) (JIRA)

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1731/

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

Error Message:
http://localhost:44309/solr/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
http://localhost:44309/solr/collection1
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:481)
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:251)
at 
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:104)
at 
org.apache.solr.cloud.FullSolrCloudTest.index_specific(FullSolrCloudTest.java:498)
at 
org.apache.solr.cloud.FullSolrCloudTest.brindDownShardIndexSomeDocsAndRecover(FullSolrCloudTest.java:745)
at 
org.apache.solr.cloud.FullSolrCloudTest.doTest(FullSolrCloudTest.java:550)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:663)
at 
org.apache.lucene.util.LuceneTestCase$3$1.evaluate(LuceneTestCase.java:527)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:150)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
at 
org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at 
org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
at 
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1413)
at 
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
at 
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
at 
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:425)




Build Log (for compile errors):
[...truncated 10687 lines...]



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

what's wrong with my implementation?

2012-02-14 Thread Li Li

hi all,
maybe it's not a suitable question here, but I want  advices from
experts knowing the details of lucene indexing.
we modified lucene 2.9.1 and add a feature we call attribute fields
which may be named column based storage in many K-V system.
because we need frequently update some fields of a document, such as
click count of webpage. this kind of field is not indexed but only stored.
this field may affect ranking. but for now, let alone ranking. we can just
think attribute an alternative thing for stored fields in fdt/fdx.
attributes can be updated later. but it's also not related to my
question.
I imitated implementation of the fdt/fdx.
for each call of IndexWriter.updateDocument(),
the core methid is processDocument called in updateDocument()
final DocWriter perDoc = state.consumer.processDocument();
the codes related to fdt/fdx in DocFieldProcessorPerThread is
  if (field.isStored) {
fieldsWriter.addField(field, fp.fieldInfo);
  }
 which do the detailed things.
   I add my codes after  final DocWriter perDoc =
state.consumer.processDocument();
   writing attributes for each document. The difference is that, stored
fields will be written to file(write but not flushed) and I hold all my
attributes in memory and flush them in DocumentsWriter.flush()
for(int i=0;ithreadStates.length;i++)
threads.add(threadStates[i].consumer);
consumer.flush(threads, flushState);

//added by LiLi
//flush fixed length attributes
this.flushFixedLengthAttributes(flushState.segmentName);
consumer.flush() will eventually call FieldsWriter.flush()
which flush fdt/fdx here.
indexStream.flush();
fieldsStream.flush();
after fdt/fdx tii tis frq prx tvxxx are flushed. I then flush
my attributes

  Another place need to modify is SegmentMerger.merge()

  mergedDocs = mergeFields();

  //added by LiLi
  //merge anm file
  mergeAttributeInfos();
  //merge attr files
  mergeAttributes(infos);

 it works fine in normal situation. But there is a bug. this bug
occured 2 times. one is last year and the other is this week. I found the
wrong segment have this phenomenon: my attribute file is created but file
size is zero. the segment has only 1 document and is deleted(numDoc()==0
maxDoc()==1)
 all other file is correct except prx(its size is also zero) and my
attr file
-rw-r--r-- 1 lili lili 218 2012-02-13 16:34 _54g.0.anm
-rw-r--r-- 1 lili lili   9 2012-02-13 16:35 _54g_1.del
-rw-r--r-- 1 lili lili   0 2012-02-13 16:34 _54g.cTime.0.att
-rw-r--r-- 1 lili lili   0 2012-02-13 16:34 _54g.downloadCount.0.att
-rw-r--r-- 1 lili lili   5 2012-02-13 16:34 _54g.fdt
-rw-r--r-- 1 lili lili  12 2012-02-13 16:35 _54g.fdx
-rw-r--r-- 1 lili lili 252 2012-02-13 16:34 _54g.fnm
-rw-r--r-- 1 lili lili   2 2012-02-13 16:34 _54g.frq
-rw-r--r-- 1 lili lili  11 2012-02-13 16:35 _54g.nrm
-rw-r--r-- 1 lili lili   0 2012-02-13 16:34 _54g.offline.0.att
-rw-r--r-- 1 lili lili   0 2012-02-13 16:34 _54g.prx
-rw-r--r-- 1 lili lili   0 2012-02-13 16:34 _54g.quality.0.att
-rw-r--r-- 1 lili lili   0 2012-02-13 16:34 _54g.quoteCount.0.att
-rw-r--r-- 1 lili lili   0 2012-02-13 16:34 _54g.startTime.0.att
-rw-r--r-- 1 lili lili  35 2012-02-13 16:34 _54g.tii
-rw-r--r-- 1 lili lili  79 2012-02-13 16:35 _54g.tis
-rw-r--r-- 1 lili lili   0 2012-02-13 16:34 _54g.travelMonths.0.att
   I think there are some code path that I missed. anyone could
help?
   Thank you very much.

[jira] [Resolved] (LUCENE-3774) check-legal isn't doing its job

2012-02-14 Thread Dawid Weiss (Resolved) (JIRA)


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

Dawid Weiss resolved LUCENE-3774.
-

   Resolution: Fixed
Fix Version/s: 4.0
   3.6
Lucene Fields:   (was: Patch Available,New)

 check-legal isn't doing its job
 ---

 Key: LUCENE-3774
 URL: https://issues.apache.org/jira/browse/LUCENE-3774
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Affects Versions: 3.6, 4.0
Reporter: Steven Rowe
Assignee: Dawid Weiss
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3774.patch, LUCENE-3774.patch, LUCENE-3774.patch, 
 LUCENE-3774.patch, LUCENE-3774.patch, LUCENE-3774.patch, LUCENE3774.patch, 
 backport.patch


 In trunk, the {{check-legal-lucene}} ant target is not checking any 
 {{lucene/contrib/\*\*/lib/}} directories; the {{modules/**/lib/}} directories 
 are not being checked; and {{check-legal-solr}} can't be checking 
 {{solr/example/lib/\*\*/\*.jar}}, because there are currently {{.jar}} files 
 in there that don't have a license.
 These targets are set up to take in a full list of {{lib/}} directories in 
 which to check, but modules move around, and these lists are not being kept 
 up-to-date.
 Instead, {{check-legal-\*}} should run for each module, if the module has a 
 {{lib/}} directory, and it should be specialized for modules that have more 
 than one ({{solr/core/}}) or that have a {{lib/}} directory in a non-standard 
 place ({{lucene/core/}}).

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



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

[jira] [Created] (LUCENE-3778) Create a grouping convenience class

Create a grouping convenience class
---

 Key: LUCENE-3778
 URL: https://issues.apache.org/jira/browse/LUCENE-3778
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/grouping
Reporter: Martijn van Groningen


Currently the grouping module has many collector classes with a lot of 
different options per class. I think it would be a good idea to have a 
GroupUtil (Or another name?) convenience class. I think this could be a 
builder, because of the many options 
(sort,sortWithinGroup,groupOffset,groupCount and more) and implementations 
(term/dv/function) grouping has.

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



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

[jira] [Commented] (SOLR-3005) Content-Type disappear

2012-02-14 Thread Chris Male (Commented) (JIRA)


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

Chris Male commented on SOLR-3005:
--

Trunk: Committed revision 1243870.

 Content-Type disappear
 --

 Key: SOLR-3005
 URL: https://issues.apache.org/jira/browse/SOLR-3005
 Project: Solr
  Issue Type: Bug
  Components: Response Writers
Affects Versions: 3.5, 4.0
 Environment: Solr 3.5.0
Reporter: Gasol Wu
Assignee: Chris Male
 Attachments: SOLR-3005.patch, SOLR-3005.patch


 i expect that query always return Content-Type, but after SOLR-1123 had 
 committed, it got chance to return nothing if you leave out all of 
 queryResponseWriter in solrconfig.xml. however i attach a small patch that 
 will correct this situation.
 It look like DEFAULT_RESPONSE_WRITERS never called init method in 
 org.apache.solr.core.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



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

Re: [jira] [Commented] (LUCENE-2632) FilteringCodec, TeeCodec, TeeDirectory

2012-02-14 Thread eks dev

cool indeed!

Now I can easily create full blown index on master and search (or
replicate) only a subset I need to search.

New use cases possible with this:
-  Today one has to blow-up term directory with  XXXMio unique ids
just to support deletions. Often a thing only needed during indexing.
For search only slaves, it is often sufficient to have uid as a stored
field (if at all), but term dictionary does not get bloated.

- possibility to simply store original documents in one index (kind of
key-value store) ,  but to search /distribute much smaller index. This
enables many new scenarios where Lucene takes storage responsibility
(Lucene overtakes Database role in many cases).


On Tue, Feb 14, 2012 at 8:45 AM, Uwe Schindler (Commented) (JIRA)
j...@apache.org wrote:

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

 Uwe Schindler commented on LUCENE-2632:
 ---

 Hey cool, sounds like this unmaintainable ParallelReaders obsolete by doing 
 the splitting to several directories/parallel fields in the codec - so 
 merging automtically works correct with every MP?

 FilteringCodec, TeeCodec, TeeDirectory
 --

                 Key: LUCENE-2632
                 URL: https://issues.apache.org/jira/browse/LUCENE-2632
             Project: Lucene - Java
          Issue Type: New Feature
          Components: core/index
    Affects Versions: 4.0
            Reporter: Andrzej Bialecki
         Attachments: LUCENE-2632.patch, LUCENE-2632.patch


 This issue adds two new Codec implementations:
 * TeeCodec: there have been attempts in the past to implement parallel 
 writing to multiple indexes so that they are all synchronized. This was 
 however complicated due to the complexity of IndexWriter/SegmentMerger 
 logic. The solution presented here offers a similar functionality but 
 working on a different level - as the name suggests, the TeeCodec duplicates 
 index data into multiple output Directories.
 * TeeDirectory (used also in TeeCodec) is a simple abstraction to perform 
 Directory operations on several directories in parallel (effectively 
 mirroring their data). Optionally it's possible to specify a set of suffixes 
 of files that should be mirrored so that non-matching files are skipped.
 * FilteringCodec is related in a remote way to the ideas of index pruning 
 presented in LUCENE-1812 and the concept of tiered search. Since we can use 
 TeeCodec to write to multiple output Directories in a synchronized way, we 
 could also filter out or modify some of the data that is being written. The 
 FilteringCodec provides this functionality, so that you can use like this:
 {code}
 IndexWriter -- TeeCodec
                  |  |
                  |  +-- StandardCodec -- Directory1
                  +-- FilteringCodec -- StandardCodec -- Directory2
 {code}
 The end result of this chain is two indexes that are kept in sync - one is 
 the full regular index, and the other one is a filtered index.

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



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


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

Re: [Lucene.Net] Site / docs

2012-02-14 Thread Stefan Bodewig

On 2012-02-14, Prescott Nasser wrote:

I've been trying to use the upload a tar.gz file to add docs to the
site to solve the publish takes forever problem. This actually doesn't
solve the problem at all - when uploading the tar file, it just untars
it and commits all the files for you (saving no time whatsoever).

8-(

At least is saves some network bandwidth for you.

Given that all projects will have to move website content into svn
sooner or later (the maven generated sites are currently cursing this as
well) I expect a solution will be found cases where a single release
changes thousands of files. But it isn't there, yet.

The only alternative would be to not create thousands of pages. CHMs, I
guess, or running a dynamic server on a dedicated VM. The later would
be easier to negotiate for a top level project.

At the moment I'm trying to solve another issue - it seems that the
Index.html page doesn't load:
http://lucene.net.staging.apache.org/lucene.net/docs/2.9.4/Index.html
- loads nothing for me, view source and it's some corrupted
text.

wget obtains a four byte binary (the byte 3 and three zeros).

However, viewing this through the svn links showing source, the source
seems fine:
https://svn.apache.org/repos/asf/incubator/lucene.net/site/trunk/content/lucene.net/docs/2.9.4/Index.html.
Does
anyone have any idea why this is?

The file itself has the svn:executable property set, but I don't expect
that to cause any issues.

The only other thing I notice with a quick scan is the BOM. Does the
CMS try to process static files in any way? Maybe it chokes on the BOM
(RAT did before I fixed it)?

Can you try to remove the BOM and see whether the problem goes away?
This won't be a permanent solution as I expect all the generated files
to contain BOMs and so we'd need to investigate with infra help what is
causing problems.

Stefan

[jira] [Commented] (LUCENE-3762) Upgrade JUnit to 4.10, refactor state-machine of detecting setUp/tearDown call chaining.


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

Robert Muir commented on LUCENE-3762:
-

+1 for 3.x too. 


 Upgrade JUnit to 4.10, refactor state-machine of detecting setUp/tearDown 
 call chaining.
 

 Key: LUCENE-3762
 URL: https://issues.apache.org/jira/browse/LUCENE-3762
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3762-backport.patch, LUCENE-3762.patch, 
 LUCENE-3762.patch, LUCENE-3762.patch


 Both Lucene and Solr use JUnit 4.7. I suggest we move forward and upgrade to 
 JUnit 4.10 which provides several infrastructural changes (serializable 
 Description objects, class-level rules, various tweaks). JUnit 4.10 also 
 changes (or fixes, depends how you look at it) the order in which 
 @Before/@After hooks and @Rules are applied. This makes the old state-machine 
 in LuceneTestCase fail (because the order is changed).
 I rewrote the state machine and used a different, I think simpler, although 
 Uwe may disagree :), mechanism in which the hook methods setUp/ tearDown are 
 still there, but they are empty at the top level and serve only to detect 
 whether subclasses chain super.setUp/tearDown properly (if they override 
 anything).
 In the long term, I would love to just get rid of public setup/teardown 
 methods and make them private (so that they cannot be overriden or even seen 
 by subclasses) but this will require changes to the runner itself.

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



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

[jira] [Commented] (LUCENE-3777) trapping overloaded ctors/setters in Field/NumericField/DocValuesField

2012-02-14 Thread Chris Male (Commented) (JIRA)


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

Chris Male commented on LUCENE-3777:


bq. I prefer sugar classes (new IntField(7), new IntValueField(7)) instead of 
static factory methods (NumericField.newIntField(7), 
DocValuesField.newIntField(7))...

+1 to sugar classes.  It gives us strong type safety and the ability to add new 
classes overtime.

 trapping overloaded ctors/setters in Field/NumericField/DocValuesField
 --

 Key: LUCENE-3777
 URL: https://issues.apache.org/jira/browse/LUCENE-3777
 Project: Lucene - Java
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir
Assignee: Michael McCandless
Priority: Blocker

 In trunk, these apis let you easily create a field, but my concern is this:
 {code}
 public NumericField(String name, int value)
 public NumericField(String name, long value)
 ..
 public Field(String name, int value, FieldType type)
 public Field(String name, long value, FieldType type)
 ..
 public void setValue(int value)
 public void setValue(long value)
 ..
 public DocValuesField(String name, int value, DocValues.Type docValueType)
 public DocValuesField(String name, long value, DocValues.Type docValueType)
 {code}
 I really don't like overloaded ctors/setters where the compiler can 
 type-promote you,
 I think it makes the apis hard to use.
 Instead for the setters I think we sohuld have setIntValue, setLongValue, ...
 For the ctors, I see two other options:
 # factories like DocValuesField.newIntField()
 # subclasses like IntField
 I don't have any patch for this, but I think we should discuss and fix before 
 these apis are released.

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



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

[jira] [Created] (LUCENE-3779) An incomplete fix for the NPE bugs in MultipleTermPositions.java

An incomplete fix for the NPE bugs in MultipleTermPositions.java


 Key: LUCENE-3779
 URL: https://issues.apache.org/jira/browse/LUCENE-3779
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.0
Reporter: Guangtai Liang
Priority: Critical


The fix revision 219387 was aimed to remove an NPE bug on the  return value of  
_termPositionsQueue.peek() in the method skipTo of the file 
/lucene/java/trunk/src/java/org/apache/lucene/index/MultipleTermPositions.java
 , but it is incomplete. 
Since the returned value  _termPositionsQueue.peek() could be null during the 
run-time execution, its value should also be null-checked before being 
dereferenced in other methods. 

The buggy code locations the same fix needs to be applied at are as bellows: 
 
Line 118, 124, 135 of the method next() : 

public final boolean next() throws IOException {
if (_termPositionsQueue.size() == 0)
  return false;

_posList.clear();
[Line  118]_doc = _termPositionsQueue.peek().doc();

TermPositions tp;
do {
  tp = _termPositionsQueue.peek();

[Line  124]for (int i = 0; i  tp.freq(); i++) {
  // NOTE: this can result in dup positions being added!
_posList.add(tp.nextPosition());
}

  if (tp.next())
_termPositionsQueue.updateTop();
  else {
_termPositionsQueue.pop();
tp.close();
  }
[Line  135]} while (_termPositionsQueue.size()  0  
_termPositionsQueue.peek().doc() == _doc);

_posList.sort();
_freq = _posList.size();

return true;

  }

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



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

[jira] [Commented] (LUCENE-2632) FilteringCodec, TeeCodec, TeeDirectory

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

Robert Muir commented on LUCENE-2632:
-

just some ideas taking a very quick glance

* I like the idea of separate impl packages you used here...
* the TODO/etc in term vectors makes me wish our codec consumer APIs for
Fields/TermVectors were more consistent...
* lots of methods have 'synchronized' where I think its not needed? e.g.
TeeTermVectorsWriter
* close() in Tee* should probably add all closeables to a list and then
IOUtils.close() that.
* TeeCodec.files() i think should call mainCodec.files, so that it doesn't rely
upon mainCodec having the default implementation in Codec.java (some dont).

Sorry, none of this fixes the merging test, which i think is somehow related to
files(), but I didn't spot the bug yet at a glance.

FilteringCodec, TeeCodec, TeeDirectory
--

Key: LUCENE-2632
URL: https://issues.apache.org/jira/browse/LUCENE-2632
Project: Lucene - Java
Issue Type: New Feature
Components: core/index
Affects Versions: 4.0
Reporter: Andrzej Bialecki
Attachments: LUCENE-2632.patch, LUCENE-2632.patch

This issue adds two new Codec implementations:
* TeeCodec: there have been attempts in the past to implement parallel
writing to multiple indexes so that they are all synchronized. This was
however complicated due to the complexity of IndexWriter/SegmentMerger logic.
The solution presented here offers a similar functionality but working on a
different level - as the name suggests, the TeeCodec duplicates index data
into multiple output Directories.
* TeeDirectory (used also in TeeCodec) is a simple abstraction to perform
Directory operations on several directories in parallel (effectively
mirroring their data). Optionally it's possible to specify a set of suffixes
of files that should be mirrored so that non-matching files are skipped.
* FilteringCodec is related in a remote way to the ideas of index pruning
presented in LUCENE-1812 and the concept of tiered search. Since we can use
TeeCodec to write to multiple output Directories in a synchronized way, we
could also filter out or modify some of the data that is being written. The
FilteringCodec provides this functionality, so that you can use like this:
{code}
IndexWriter -- TeeCodec
| |
| +-- StandardCodec -- Directory1
+-- FilteringCodec -- StandardCodec -- Directory2
{code}
The end result of this chain is two indexes that are kept in sync - one is
the full regular index, and the other one is a filtered index.

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

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

[jira] [Commented] (LUCENE-2632) FilteringCodec, TeeCodec, TeeDirectory


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

Robert Muir commented on LUCENE-2632:
-

Hmm actually another thing to investigate is Directory's CFS-related methods 
with things that delegate like TeeDirectory?

We had problems around here before with FileSwitchDirectory... LUCENE-3380, 
maybe you just found another one.

 FilteringCodec, TeeCodec, TeeDirectory
 --

 Key: LUCENE-2632
 URL: https://issues.apache.org/jira/browse/LUCENE-2632
 Project: Lucene - Java
  Issue Type: New Feature
  Components: core/index
Affects Versions: 4.0
Reporter: Andrzej Bialecki 
 Attachments: LUCENE-2632.patch, LUCENE-2632.patch


 This issue adds two new Codec implementations:
 * TeeCodec: there have been attempts in the past to implement parallel 
 writing to multiple indexes so that they are all synchronized. This was 
 however complicated due to the complexity of IndexWriter/SegmentMerger logic. 
 The solution presented here offers a similar functionality but working on a 
 different level - as the name suggests, the TeeCodec duplicates index data 
 into multiple output Directories.
 * TeeDirectory (used also in TeeCodec) is a simple abstraction to perform 
 Directory operations on several directories in parallel (effectively 
 mirroring their data). Optionally it's possible to specify a set of suffixes 
 of files that should be mirrored so that non-matching files are skipped.
 * FilteringCodec is related in a remote way to the ideas of index pruning 
 presented in LUCENE-1812 and the concept of tiered search. Since we can use 
 TeeCodec to write to multiple output Directories in a synchronized way, we 
 could also filter out or modify some of the data that is being written. The 
 FilteringCodec provides this functionality, so that you can use like this:
 {code}
 IndexWriter -- TeeCodec
  |  |
  |  +-- StandardCodec -- Directory1
  +-- FilteringCodec -- StandardCodec -- Directory2
 {code}
 The end result of this chain is two indexes that are kept in sync - one is 
 the full regular index, and the other one is a filtered index.

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



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

[jira] [Created] (LUCENE-3780) An incomplete fix for the NPE bugs in ParallelReader.java

An incomplete fix for the NPE bugs in ParallelReader.java
-

 Key: LUCENE-3780
 URL: https://issues.apache.org/jira/browse/LUCENE-3780
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.0
Reporter: Guangtai Liang
Priority: Critical


The fix revision 407851 was aimed to remove an NPE bug on the  return value of  
fieldToReader.get(field) in the methods getTermFreqVector, hasNorms, 
norms, doSetNorm of the file 
/lucene/java/trunk/src/java/org/apache/lucene/index/ParallelReader.java
 , but it is incomplete. 
Since the returned value  fieldToReader.get(field) could be null during the 
runtime execution, its value should also be null-checked before being 
dereferenced in other methods. 

The buggy code locations the same fix needs to be applied at are as bellows: 
 
Line 499  of the method ParallelTermEnum() : 


public ParallelTermEnum() throws IOException {
  try {
field = fieldToReader.firstKey();
  } catch(NoSuchElementException e) {
// No fields, so keep field == null, termEnum == null
return;
  }
  if (field != null)
[Line 499]termEnum = fieldToReader.get(field).terms();
}


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



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

[jira] [Commented] (SOLR-2934) Problem with Solr Hunspell with French Dictionary

2012-02-14 Thread Commented


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

Bráulio Bhavamitra commented on SOLR-2934:
--

the same is happening with pt_BR dict 
http://artfiles.org/openoffice.org/contrib/dictionaries/pt_BR.zip

 Problem with Solr Hunspell with French Dictionary
 -

 Key: SOLR-2934
 URL: https://issues.apache.org/jira/browse/SOLR-2934
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Affects Versions: 3.5
 Environment: Windows 7
Reporter: Nathan Castelein
Assignee: Chris Male
 Attachments: en_GB.aff, en_GB.dic


 I'm trying to add the HunspellStemFilterFactory to my Solr project. 
 I'm trying this on a fresh new download of Solr 3.5.
 I downloaded french dictionary here (found it from here): 
 http://www.dicollecte.org/download/fr/hunspell-fr-moderne-v4.3.zip
 But when I start Solr and go to the Solr Analysis, an error occurs in Solr.
 Is there the trace : 
 java.lang.RuntimeException: Unable to load hunspell data! 
 [dictionary=en_GB.dic,affix=fr-moderne.aff]
   at 
 org.apache.solr.analysis.HunspellStemFilterFactory.inform(HunspellStemFilterFactory.java:82)
   at 
 org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:546)
   at org.apache.solr.schema.IndexSchema.init(IndexSchema.java:126)
   at org.apache.solr.core.CoreContainer.create(CoreContainer.java:461)
   at org.apache.solr.core.CoreContainer.load(CoreContainer.java:316)
   at org.apache.solr.core.CoreContainer.load(CoreContainer.java:207)
   at 
 org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:130)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:94)
   at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
   at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
   at 
 org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713)
   at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
   at 
 org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)
   at 
 org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)
   at 
 org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)
   at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
   at 
 org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
   at 
 org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
   at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
   at 
 org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
   at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
   at 
 org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
   at org.mortbay.jetty.Server.doStart(Server.java:224)
   at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
   at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at org.mortbay.start.Main.invokeMain(Main.java:194)
   at org.mortbay.start.Main.start(Main.java:534)
   at org.mortbay.start.Main.start(Main.java:441)
   at org.mortbay.start.Main.main(Main.java:119)
 Caused by: java.lang.StringIndexOutOfBoundsException: String index out of 
 range: 3
   at java.lang.String.charAt(Unknown Source)
   at 
 org.apache.lucene.analysis.hunspell.HunspellDictionary$DoubleASCIIFlagParsingStrategy.parseFlags(HunspellDictionary.java:382)
   at 
 org.apache.lucene.analysis.hunspell.HunspellDictionary.parseAffix(HunspellDictionary.java:165)
   at 
 org.apache.lucene.analysis.hunspell.HunspellDictionary.readAffixFile(HunspellDictionary.java:121)
   at 
 org.apache.lucene.analysis.hunspell.HunspellDictionary.init(HunspellDictionary.java:64)
   at 
 org.apache.solr.analysis.HunspellStemFilterFactory.inform(HunspellStemFilterFactory.java:46)
 I can't find where the problem is. It seems like my dictionary isn't well 
 written for hunspell, but I tried with two different dictionaries, and I had 
 the same problem.
 I also tried with an english dictionary, and ... it works !
 So I think that my french dictionary is wrong for hunspell, but I don't know 
 why ...
 Can you help me ?

--
This message is automatically generated by

[jira] [Created] (LUCENE-3781) Another incomplete fix for the NPE bugs in ParallelReader.java

Another incomplete fix for the NPE bugs in ParallelReader.java
--

 Key: LUCENE-3781
 URL: https://issues.apache.org/jira/browse/LUCENE-3781
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.0
Reporter: Guangtai Liang


The fix revision 407851  was aimed to remove an NPE bug on the value  of  
termDocs in the methods next, read, skipTo, close of the file 
/lucene/java/trunk/src/java/org/apache/lucene/index/ParallelReader.java
 , but it is incomplete. 
Since the value  termDocs could be null during the runtime execution, its 
value should also be null-checked before being dereferenced in other methods. 

The buggy code locations the same fix needs to be applied at are as bellows: 
 
Line 574, 575 of the methods doc() , and freq: 

 public int doc() { return termDocs.doc(); }
 public int freq() { return termDocs.freq(); }


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



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

[jira] [Commented] (LUCENE-2632) FilteringCodec, TeeCodec, TeeDirectory

2012-02-14 Thread Andrzej Bialecki (Commented) (JIRA)

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

Andrzej Bialecki commented on LUCENE-2632:
---

bq. the TODO/etc in term vectors makes me wish our codec consumer APIs for
Fields/TermVectors were more consistent...

Also, the handling of segments.gen and compound files that bypasses codec
actually forced me to implement TeeDirectory.

Re. synchronization - yes, many of these should be removed. I synced everything
for now to narrow down the source of merge problems. TeeCodec.files() - well
spotted, this should be fixed.

FilteringCodec, TeeCodec, TeeDirectory
--

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

Re: Hmmm, license checking a bit over-zealous?

 Well, I never did have the sense to  quit while I was ahead. That
 works just fine, checking in momentarily.

Time zone differences, so a bit belated, but this may be of interest
for others as well. License checking is now global to capture any JARs
added to the repo. Unfortunately certain JARs are either created or
copied in the source folders and they need to be excluded manually.
There are three places where this can be done:

*) /lucene/tools/custom-tasks.xml

This is the main macro for license checking and any exclusions applied
to the fileset there will be global for solr, lucene and modules.

*) /lucene/build.xml

Validate target, lucene-specific. Currently only contains macro
invocation (no customizations for Lucene).

*) /solr/build.xml

Validate target, solr-specific. This currently contains that macro
call, but with custom solr-only exclusions as in:

license-check-macro dir=${basedir}
  additional-excludes
!-- Exclude start.jar only (it'd be weird to have a license
file there?) --
exclude name=example/start.jar /
exclude name=example/exampledocs/post.jar /
  /additional-excludes
  additional-filters
replaceregex pattern=/jetty-util([^/]+)$
replace=/jetty-util flags=gi /
replaceregex pattern=/jetty-6([^/]+)$ replace=/jetty flags=gi /
replaceregex pattern=/jsp-2.1-glassfish([^/]+)$
replace=/jsp-2.1-glassfish flags=gi /
replaceregex pattern=/jsp-api-2.1-glassfish([^/]+)$
replace=/jsp-api-2.1-glassfish flags=gi /
  /additional-filters
/license-check-macro

additional-excludes apply exclude rules to the default set.
additional-filters normalize JAR names with funky versioning numbers
so that licenses can be found.

*) /modules/build.xml (trunk)

validate target. I don't think there will be any need to fiddle with it.


So, Erick could have added **/work/** as a sol-only exclusion if it
applies to solr only (I've updated the repo). Ideally, we should over
time get rid of project-specific exclusions since what they mean is
that something is in the sources area instead of being under some
build/ compilation directory...

Dawid

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

[jira] [Created] (LUCENE-3782) An incomplete fix for the NPE bugs in Directory.java

An incomplete fix for the NPE bugs in Directory.java


 Key: LUCENE-3782
 URL: https://issues.apache.org/jira/browse/LUCENE-3782
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/store
Affects Versions: 3.0
Reporter: Guangtai Liang
Priority: Critical


The fix revision 499089 was aimed to remove an NPE bug (LUCENE-773) on the 
value  of  lockFactory  in the method clearLock of the file 
/lucene/java/trunk/src/java/org/apache/lucene/store/Directory.java , but it 
is incomplete. 

Since the value  lockFactory  could be null during the runtime execution, its 
value should also be null-checked before being dereferenced in other methods. 

The buggy code locations the same fix needs to be applied at are as bellows: 
 
Line 106 of the methods doc() , and freq: 

  public Lock makeLock(String name) {
[Line 106]  return lockFactory.makeLock(name);

  }

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



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

[jira] [Commented] (LUCENE-2632) FilteringCodec, TeeCodec, TeeDirectory


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

Robert Muir commented on LUCENE-2632:
-

{quote}
Also, the handling of segments.gen and compound files that bypasses codec 
actually forced me to implement TeeDirectory.
{quote}

True, though I don't know of any simple solutions to either of these :)

for CFS, we made some tiny steps in LUCENE-3728, but the codec only has limited 
control here (e.g. it can store certain things
outside of CFS, this is how preflex codec reads separate norms). But it cannot 
yet customize the CFS filenames nor the actual
format/packing process.


 FilteringCodec, TeeCodec, TeeDirectory
 --

 Key: LUCENE-2632
 URL: https://issues.apache.org/jira/browse/LUCENE-2632
 Project: Lucene - Java
  Issue Type: New Feature
  Components: core/index
Affects Versions: 4.0
Reporter: Andrzej Bialecki 
 Attachments: LUCENE-2632.patch, LUCENE-2632.patch


 This issue adds two new Codec implementations:
 * TeeCodec: there have been attempts in the past to implement parallel 
 writing to multiple indexes so that they are all synchronized. This was 
 however complicated due to the complexity of IndexWriter/SegmentMerger logic. 
 The solution presented here offers a similar functionality but working on a 
 different level - as the name suggests, the TeeCodec duplicates index data 
 into multiple output Directories.
 * TeeDirectory (used also in TeeCodec) is a simple abstraction to perform 
 Directory operations on several directories in parallel (effectively 
 mirroring their data). Optionally it's possible to specify a set of suffixes 
 of files that should be mirrored so that non-matching files are skipped.
 * FilteringCodec is related in a remote way to the ideas of index pruning 
 presented in LUCENE-1812 and the concept of tiered search. Since we can use 
 TeeCodec to write to multiple output Directories in a synchronized way, we 
 could also filter out or modify some of the data that is being written. The 
 FilteringCodec provides this functionality, so that you can use like this:
 {code}
 IndexWriter -- TeeCodec
  |  |
  |  +-- StandardCodec -- Directory1
  +-- FilteringCodec -- StandardCodec -- Directory2
 {code}
 The end result of this chain is two indexes that are kept in sync - one is 
 the full regular index, and the other one is a filtered index.

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



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

[jira] [Commented] (LUCENE-3758) Allow the ComplexPhraseQueryParser to search order or un-order proximity queries.

2012-02-14 Thread Dmitry Kan (Commented) (JIRA)


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

Dmitry Kan commented on LUCENE-3758:


Implemented new query operator #, that allows to do what's described in my 
previous message. Let me know, if someone needs a patch for this.

 Allow the ComplexPhraseQueryParser to search order or un-order proximity 
 queries.
 -

 Key: LUCENE-3758
 URL: https://issues.apache.org/jira/browse/LUCENE-3758
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/queryparser
Affects Versions: 4.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Fix For: 4.0

 Attachments: LUCENE-3758.patch


 The ComplexPhraseQueryParser use SpanNearQuery, but always set the inOrder 
 value hardcoded to true. This could be configurable.

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



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

Re: Hmmm, license checking a bit over-zealous?

2012-02-14 Thread Erick Erickson

Thanks Dawid. I didn't really like the exclusion with **/work/** that
I put in, but it was late. The change to solr/build.xml is a lot cleaner

Erick

On Tue, Feb 14, 2012 at 3:16 AM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
 Well, I never did have the sense to  quit while I was ahead. That
 works just fine, checking in momentarily.

 Time zone differences, so a bit belated, but this may be of interest
 for others as well. License checking is now global to capture any JARs
 added to the repo. Unfortunately certain JARs are either created or
 copied in the source folders and they need to be excluded manually.
 There are three places where this can be done:

 *) /lucene/tools/custom-tasks.xml

 This is the main macro for license checking and any exclusions applied
 to the fileset there will be global for solr, lucene and modules.

 *) /lucene/build.xml

 Validate target, lucene-specific. Currently only contains macro
 invocation (no customizations for Lucene).

 *) /solr/build.xml

 Validate target, solr-specific. This currently contains that macro
 call, but with custom solr-only exclusions as in:

    license-check-macro dir=${basedir}
      additional-excludes
        !-- Exclude start.jar only (it'd be weird to have a license
 file there?) --
        exclude name=example/start.jar /
        exclude name=example/exampledocs/post.jar /
      /additional-excludes
      additional-filters
        replaceregex pattern=/jetty-util([^/]+)$
 replace=/jetty-util flags=gi /
        replaceregex pattern=/jetty-6([^/]+)$ replace=/jetty flags=gi /
        replaceregex pattern=/jsp-2.1-glassfish([^/]+)$
 replace=/jsp-2.1-glassfish flags=gi /
        replaceregex pattern=/jsp-api-2.1-glassfish([^/]+)$
 replace=/jsp-api-2.1-glassfish flags=gi /
      /additional-filters
    /license-check-macro

 additional-excludes apply exclude rules to the default set.
 additional-filters normalize JAR names with funky versioning numbers
 so that licenses can be found.

 *) /modules/build.xml (trunk)

 validate target. I don't think there will be any need to fiddle with it.


 So, Erick could have added **/work/** as a sol-only exclusion if it
 applies to solr only (I've updated the repo). Ideally, we should over
 time get rid of project-specific exclusions since what they mean is
 that something is in the sources area instead of being under some
 build/ compilation directory...

 Dawid

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


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

new Admin UI and license information

2012-02-14 Thread Erick Erickson

While I was working on some of the LukeRequestHandler speedups, I
noticed that there were no license notifications in the new Admin UI
code, so I stuck some in and committed it (r: 1243925). Two questions:

1 Is there any need for a JIRA here?
2 ...solr/webapp/web/js/jquery.sparkline.js and a couple of others
already had a license notification in them. I added in the Apache
license information, should I have?

Thanks,
Erick

P.S. I did a very quick triage to see that that I didn't use, say, the
wrong comment form, but it was *very* quick. If functionality has
disappeared mysteriously, here's where I'd look first.

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

[jira] [Created] (LUCENE-3783) An incomplete fix for the NPE bugs in NearSpansUnordered.java

An incomplete fix for the NPE bugs in NearSpansUnordered.java
-

 Key: LUCENE-3783
 URL: https://issues.apache.org/jira/browse/LUCENE-3783
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/search
Affects Versions: 3.0
Reporter: Guangtai Liang


The fix revision 698487 was aimed to remove an NPE bug (LUCENE-1404) on the 
returned value  of  min() in the method isPayloadAvailable of the file 
/lucene/java/trunk/src/java/org/apache/lucene/search/spans/NearSpansUnordered.java
 , but it is incomplete. 

Since the  returned value  min() could be null during the runtime execution, 
its value should also be null-checked before being dereferenced in other 
methods. 

The buggy code locations the same fix needs to be applied at are as bellows: 
 
Lines 159 , 170 , and 196 of the methods next() 
Line 216 of the methods skipTo()
Line 230 of the methods doc()
230  public int doc() { return min().doc(); }

Line 232 of the methods start()
232  public int start() { return min().start(); }

Line 315 of the methods atMatch()
private boolean atMatch() {
315return (min().doc() == max.doc())
 ((max.end() - min().start() - totalLength) = slop);
  }


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



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

[jira] [Updated] (LUCENE-3781) Another incomplete fix for the NPE bugs in ParallelReader.java

2012-02-14 Thread Guangtai Liang (Updated) (JIRA)


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

Guangtai Liang updated LUCENE-3781:
---

Description: 
The fix revision 407851  was aimed to remove an NPE bug (fix NPE and deletion 
bugs in ParallelReader: LUCENE-561) on the value  of  termDocs in the 
methods next, read, skipTo, close of the file 
/lucene/java/trunk/src/java/org/apache/lucene/index/ParallelReader.java
 , but it is incomplete. 
Since the value  termDocs could be null during the runtime execution, its 
value should also be null-checked before being dereferenced in other methods. 

The buggy code locations the same fix needs to be applied at are as bellows: 
 
Line 574, 575 of the methods doc() , and freq: 

 public int doc() { return termDocs.doc(); }
 public int freq() { return termDocs.freq(); }


  was:
The fix revision 407851  was aimed to remove an NPE bug (LUCENE-561) on the 
value  of  termDocs in the methods next, read, skipTo, close of the 
file /lucene/java/trunk/src/java/org/apache/lucene/index/ParallelReader.java
 , but it is incomplete. 
Since the value  termDocs could be null during the runtime execution, its 
value should also be null-checked before being dereferenced in other methods. 

The buggy code locations the same fix needs to be applied at are as bellows: 
 
Line 574, 575 of the methods doc() , and freq: 

 public int doc() { return termDocs.doc(); }
 public int freq() { return termDocs.freq(); }



 Another incomplete fix for the NPE bugs in ParallelReader.java
 --

 Key: LUCENE-3781
 URL: https://issues.apache.org/jira/browse/LUCENE-3781
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.0
Reporter: Guangtai Liang
  Labels: incomplete_fix, missing_fixes
   Original Estimate: 10m
  Remaining Estimate: 10m

 The fix revision 407851  was aimed to remove an NPE bug (fix NPE and 
 deletion bugs in ParallelReader: LUCENE-561) on the value  of  termDocs in 
 the methods next, read, skipTo, close of the file 
 /lucene/java/trunk/src/java/org/apache/lucene/index/ParallelReader.java
  , but it is incomplete. 
 Since the value  termDocs could be null during the runtime execution, its 
 value should also be null-checked before being dereferenced in other methods. 
 The buggy code locations the same fix needs to be applied at are as bellows: 
  
 Line 574, 575 of the methods doc() , and freq: 
  public int doc() { return termDocs.doc(); }
  public int freq() { return termDocs.freq(); }

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



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

[jira] [Updated] (LUCENE-3779) An incomplete fix for the NPE bugs in MultipleTermPositions.java

2012-02-14 Thread Guangtai Liang (Updated) (JIRA)


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

Guangtai Liang updated LUCENE-3779:
---

Description: 
The fix revision 219387 (Fix for NPE (bug #35626). Fix by Hans Hjelm, test case 
by Scotty Allen.) was aimed to remove an NPE bug on the  return value of  
_termPositionsQueue.peek() in the method skipTo of the file 
/lucene/java/trunk/src/java/org/apache/lucene/index/MultipleTermPositions.java
 , but it is incomplete. 
Since the returned value  _termPositionsQueue.peek() could be null during the 
run-time execution, its value should also be null-checked before being 
dereferenced in other methods. 

The buggy code locations the same fix needs to be applied at are as bellows: 
 
Line 118, 124, 135 of the method next() : 

public final boolean next() throws IOException {
if (_termPositionsQueue.size() == 0)
  return false;

_posList.clear();
[Line  118]_doc = _termPositionsQueue.peek().doc();

TermPositions tp;
do {
  tp = _termPositionsQueue.peek();

[Line  124]for (int i = 0; i  tp.freq(); i++) {
  // NOTE: this can result in dup positions being added!
_posList.add(tp.nextPosition());
}

  if (tp.next())
_termPositionsQueue.updateTop();
  else {
_termPositionsQueue.pop();
tp.close();
  }
[Line  135]} while (_termPositionsQueue.size()  0  
_termPositionsQueue.peek().doc() == _doc);

_posList.sort();
_freq = _posList.size();

return true;

  }

  was:
The fix revision 219387 was aimed to remove an NPE bug on the  return value of  
_termPositionsQueue.peek() in the method skipTo of the file 
/lucene/java/trunk/src/java/org/apache/lucene/index/MultipleTermPositions.java
 , but it is incomplete. 
Since the returned value  _termPositionsQueue.peek() could be null during the 
run-time execution, its value should also be null-checked before being 
dereferenced in other methods. 

The buggy code locations the same fix needs to be applied at are as bellows: 
 
Line 118, 124, 135 of the method next() : 

public final boolean next() throws IOException {
if (_termPositionsQueue.size() == 0)
  return false;

_posList.clear();
[Line  118]_doc = _termPositionsQueue.peek().doc();

TermPositions tp;
do {
  tp = _termPositionsQueue.peek();

[Line  124]for (int i = 0; i  tp.freq(); i++) {
  // NOTE: this can result in dup positions being added!
_posList.add(tp.nextPosition());
}

  if (tp.next())
_termPositionsQueue.updateTop();
  else {
_termPositionsQueue.pop();
tp.close();
  }
[Line  135]} while (_termPositionsQueue.size()  0  
_termPositionsQueue.peek().doc() == _doc);

_posList.sort();
_freq = _posList.size();

return true;

  }


 An incomplete fix for the NPE bugs in MultipleTermPositions.java
 

 Key: LUCENE-3779
 URL: https://issues.apache.org/jira/browse/LUCENE-3779
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.0
Reporter: Guangtai Liang
Priority: Critical
   Original Estimate: 10m
  Remaining Estimate: 10m

 The fix revision 219387 (Fix for NPE (bug #35626). Fix by Hans Hjelm, test 
 case by Scotty Allen.) was aimed to remove an NPE bug on the  return value of 
  _termPositionsQueue.peek() in the method skipTo of the file 
 /lucene/java/trunk/src/java/org/apache/lucene/index/MultipleTermPositions.java
  , but it is incomplete. 
 Since the returned value  _termPositionsQueue.peek() could be null during 
 the run-time execution, its value should also be null-checked before being 
 dereferenced in other methods. 
 The buggy code locations the same fix needs to be applied at are as bellows: 
  
 Line 118, 124, 135 of the method next() : 
 public final boolean next() throws IOException {
 if (_termPositionsQueue.size() == 0)
   return false;
 _posList.clear();
 [Line  118]_doc = _termPositionsQueue.peek().doc();
 TermPositions tp;
 do {
   tp = _termPositionsQueue.peek();
 [Line  124]for (int i = 0; i  tp.freq(); i++) {
   // NOTE: this can result in dup positions being added!
 _posList.add(tp.nextPosition());
 }
   if (tp.next())
 _termPositionsQueue.updateTop();
   else {
 _termPositionsQueue.pop();
 tp.close();
   }
 [Line  135]} while (_termPositionsQueue.size()  0  
 _termPositionsQueue.peek().doc() == _doc);
 _posList.sort();
 _freq = _posList.size();
 return true;
   }

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

[jira] [Commented] (LUCENE-3758) Allow the ComplexPhraseQueryParser to search order or un-order proximity queries.

2012-02-14 Thread Commented


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

Tomás Fernández Löbbe commented on LUCENE-3758:
---

Basically, a search like 'foo bar#2' would match documents with the terms 
foo and bar with up to 2 positions of distance from each other and only if 
foo is before bar?

 Allow the ComplexPhraseQueryParser to search order or un-order proximity 
 queries.
 -

 Key: LUCENE-3758
 URL: https://issues.apache.org/jira/browse/LUCENE-3758
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/queryparser
Affects Versions: 4.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Fix For: 4.0

 Attachments: LUCENE-3758.patch


 The ComplexPhraseQueryParser use SpanNearQuery, but always set the inOrder 
 value hardcoded to true. This could be configurable.

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



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

[jira] [Commented] (SOLR-3131) details command fails while a replication is forced with a fetchIndex command on a non-slave server

2012-02-14 Thread Commented


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

Tomás Fernández Löbbe commented on SOLR-3131:
-

Thanks Mark, I tested the patch with my data and seems to work.

 details command fails while a replication is forced with a fetchIndex 
 command on a non-slave server
 ---

 Key: SOLR-3131
 URL: https://issues.apache.org/jira/browse/SOLR-3131
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 4.0
Reporter: Tomás Fernández Löbbe
Assignee: Mark Miller
Priority: Minor
 Attachments: SOLR-3131.patch


 Steps to reproduce the problem:
 1) Start a master Solr instance (called A)
 2) Start a Solr instance with replication handler configured, but with no 
 slave configuration. (called B)
 3) Issue the request 
 http://B:port/solr/replication?command=fetchindexmasterUrl=http://A:port/solr/replication
 4) While B is fetching the index, issue the request: 
 http://B:port/solr/replication?command=details
 Expected behavior: See the replication details as usual.
 Getting an exception instead:
 java.lang.NullPointerException
   at 
 org.apache.solr.handler.ReplicationHandler.isPollingDisabled(ReplicationHandler.java:447)
   at 
 org.apache.solr.handler.ReplicationHandler.getReplicationDetails(ReplicationHandler.java:611)
   at 
 org.apache.solr.handler.ReplicationHandler.handleRequestBody(ReplicationHandler.java:211)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1523)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:339)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:234)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
   at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
   at 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
   at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
   at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
   at 
 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
   at 
 org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
   at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
   at org.mortbay.jetty.Server.handle(Server.java:326)
   at 
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
   at 
 org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
   at 
 org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
   at 
 org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)

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



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

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 12430 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12430/

All tests passed

Build Log (for compile errors):
[...truncated 20880 lines...]



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

Re: Hmmm, license checking a bit over-zealous?

 Thanks Dawid. I didn't really like the exclusion with **/work/** that
 I put in, but it was late. The change to solr/build.xml is a lot cleaner

I should have explained it when I committed it in, but I honestly
thought I'd gone through all the possible scenarios and had all the
weird files covered. Sorry for trouble.

Dawid

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

Re: new Admin UI and license information

By the way -- that license-check macro can work with any files, not
only with *.jar files. It's basically a mapping from a fileset
resources to other resource names. I can help in adding validation for
*.js or whatever so that they are checked for licenses too.

Dawid

On Tue, Feb 14, 2012 at 3:07 PM, Erick Erickson erickerick...@gmail.com wrote:
 While I was working on some of the LukeRequestHandler speedups, I
 noticed that there were no license notifications in the new Admin UI
 code, so I stuck some in and committed it (r: 1243925). Two questions:

 1 Is there any need for a JIRA here?
 2 ...solr/webapp/web/js/jquery.sparkline.js and a couple of others
 already had a license notification in them. I added in the Apache
 license information, should I have?

 Thanks,
 Erick

 P.S. I did a very quick triage to see that that I didn't use, say, the
 wrong comment form, but it was *very* quick. If functionality has
 disappeared mysteriously, here's where I'd look first.

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


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

[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1733 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1733/

2 tests failed.
REGRESSION:  org.apache.solr.cloud.FullSolrCloudTest.testDistribSearch

Error Message:
http://localhost:42979/solr/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
http://localhost:42979/solr/collection1
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:481)
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:251)
at 
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:104)
at 
org.apache.solr.cloud.FullSolrCloudTest.index_specific(FullSolrCloudTest.java:498)
at 
org.apache.solr.cloud.FullSolrCloudTest.brindDownShardIndexSomeDocsAndRecover(FullSolrCloudTest.java:745)
at 
org.apache.solr.cloud.FullSolrCloudTest.doTest(FullSolrCloudTest.java:550)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:663)
at 
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:700)
at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:599)
at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:504)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:562)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:150)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
at 
org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at 
org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
at 
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1413)
at 
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
at 
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
at 
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:425)


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

Error Message:
ERROR: SolrIndexSearcher opens=13 closes=12

Stack Trace:
junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=13 
closes=12
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:152)
at 
org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:76)




Build Log (for compile errors):
[...truncated 10159 lines...]



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

RE: [JENKINS] Lucene-Solr-tests-only-3.x - Build # 12430 - Failure

2012-02-14 Thread Steven A Rowe

This is a javadoc warning:

  [javadoc] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/core/src/java/org/apache/lucene/search/NRTManager.java:369:
 warning - Tag @link: can't find release(IndexSearcher) in 
org.apache.lucene.search.SearcherManager

 -Original Message-
 From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
 Sent: Tuesday, February 14, 2012 10:06 AM
 To: dev@lucene.apache.org
 Subject: [JENKINS] Lucene-Solr-tests-only-3.x - Build # 12430 - Failure
 
 Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12430/
 
 All tests passed
 
 Build Log (for compile errors):
 [...truncated 20880 lines...]

[jira] [Resolved] (LUCENE-3762) Upgrade JUnit to 4.10, refactor state-machine of detecting setUp/tearDown call chaining.

2012-02-14 Thread Dawid Weiss (Resolved) (JIRA)


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

Dawid Weiss resolved LUCENE-3762.
-

Resolution: Fixed

 Upgrade JUnit to 4.10, refactor state-machine of detecting setUp/tearDown 
 call chaining.
 

 Key: LUCENE-3762
 URL: https://issues.apache.org/jira/browse/LUCENE-3762
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3762-backport.patch, LUCENE-3762.patch, 
 LUCENE-3762.patch, LUCENE-3762.patch


 Both Lucene and Solr use JUnit 4.7. I suggest we move forward and upgrade to 
 JUnit 4.10 which provides several infrastructural changes (serializable 
 Description objects, class-level rules, various tweaks). JUnit 4.10 also 
 changes (or fixes, depends how you look at it) the order in which 
 @Before/@After hooks and @Rules are applied. This makes the old state-machine 
 in LuceneTestCase fail (because the order is changed).
 I rewrote the state machine and used a different, I think simpler, although 
 Uwe may disagree :), mechanism in which the hook methods setUp/ tearDown are 
 still there, but they are empty at the top level and serve only to detect 
 whether subclasses chain super.setUp/tearDown properly (if they override 
 anything).
 In the long term, I would love to just get rid of public setup/teardown 
 methods and make them private (so that they cannot be overriden or even seen 
 by subclasses) but this will require changes to the runner itself.

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



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

[jira] [Resolved] (LUCENE-3492) Extract a generic framework for running randomized tests.

2012-02-14 Thread Dawid Weiss (Resolved) (JIRA)


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

Dawid Weiss resolved LUCENE-3492.
-

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

I consider this issue done. I've pulled all the super-cool features from 
Lucene/Solr and put them into a separate, stand-alone and reusable project 
called randomizedtesting. We have switched our infrastructure at Carrot2 to use 
it and I'm very happy with it.

http://labs.carrotsearch.com/randomizedtesting.html

I will file another issue concerned with progressively moving from 
LuceneTestRunner/Case and tests infrastructure to RandomizedRunner (and 
siblings).

 Extract a generic framework for running randomized tests.
 -

 Key: LUCENE-3492
 URL: https://issues.apache.org/jira/browse/LUCENE-3492
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Minor
 Attachments: Screen Shot 2011-10-06 at 12.58.02 PM.png


 {color:red}The work on this issue is temporarily at github{color} (lots of 
 experiments and tweaking):
 https://github.com/carrotsearch/randomizedtesting
 Or directly: git clone git://github.com/carrotsearch/randomizedtesting.git
 {color}
 
 RandomizedRunner is a JUnit runner, so it is capable of running 
 @Test-annotated test cases. It
 respects regular lifecycle hooks such as @Before, @After, @BeforeClass or 
 @AfterClass, but it
 also adds the following:
 Randomized, but repeatable execution and infrastructure for dealing with 
 randomness:
 - uses pseudo-randomness (so that a given run can be repeated if given the 
 same starting seed)
   for many things called random below,
 - randomly shuffles test methods to ensure they don't depend on each other,
 - randomly shuffles hooks (within a given class) to ensure they don't depend 
 on each other,
 - base class RandomizedTest provides a number of methods for generating 
 random numbers, strings
   and picking random objects from collections (again, this is fully 
 repeatable given the
   initial seed if there are no race conditions),
 - the runner provides infrastructure to augment stack traces with information 
 about the initial
   seeds used for running the test, so that it can be repeated (or it can be 
 determined that
   the test is not repeatable -- this indicates a problem with the test case 
 itself).
 Thread control:
 - any threads created as part of a test case are assigned the same initial 
 random seed 
   (repeatability),
 - tracks and attempts to terminate any Threads that are created and not 
 terminated inside 
   a test case (not cleaning up causes a test failure),
 - tracks and attempts to terminate test cases that run for too long (default 
 timeout: 60 seconds,
   adjustable using global property or annotations),
 Improved validation and lifecycle support:
 - RandomizedRunner uses relaxed contracts of hook methods' accessibility 
 (hook methods _can_ be
   private). This helps in avoiding problems with method shadowing (static 
 hooks) or overrides
   that require tedious super.() chaining). Private hooks are always executed 
 and don't affect
   subclasses in any way, period.
 - @Listeners annotation on a test class allows it to hook into the execution 
 progress and listen
   to events.
 - @Validators annotation allows a test class to provide custom validation 
 strategies 
   (project-specific). For example a base class can request specific test case 
 naming strategy
   (or reject JUnit3-like methods, for instance).
 - RandomizedRunner does not chain or suppress exceptions happening during 
 execution of 
   a test case (including hooks). All exceptions are reported as soon as they 
 happened and multiple
   failure reports can occur. Most environments we know of then display these 
 failures sequentially
   allowing a clearer understanding of what actually happened 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



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

[jira] [Created] (LUCENE-3784) Switching tests infrastructure to randomizedtesting.*

2012-02-14 Thread Dawid Weiss (Created) (JIRA)

Switching tests infrastructure to randomizedtesting.*
-

 Key: LUCENE-3784
 URL: https://issues.apache.org/jira/browse/LUCENE-3784
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build, general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Minor
 Fix For: 4.0




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



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

[jira] [Resolved] (LUCENE-3761) Generalize SearcherManager

2012-02-14 Thread Shai Erera (Resolved) (JIRA)

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

Shai Erera resolved LUCENE-3761.

Resolution: Fixed

Thanks all for your comments. Robert, I added back maybeReopen to
SearcherManager as deprecated.

Committed rev 1243906 (3x).
Ported to trunk 1244000 (trunk).

I will open a separate issue for SearcherTaxoManager

Generalize SearcherManager
--

Key: LUCENE-3761
URL: https://issues.apache.org/jira/browse/LUCENE-3761
Project: Lucene - Java
Issue Type: Improvement
Components: core/search
Reporter: Shai Erera
Assignee: Shai Erera
Priority: Minor
Fix For: 3.6, 4.0

Attachments: LUCENE-3761.patch, LUCENE-3761.patch, LUCENE-3761.patch

I'd like to generalize SearcherManager to a class which can manage instances
of a certain type of interfaces. The reason is that today SearcherManager
knows how to handle IndexSearcher instances. I have a SearcherManager which
manages a pair of IndexSearcher and TaxonomyReader pair.
Recently, few concurrency bugs were fixed in SearcherManager, and I realized
that I need to apply them to my version as well. Which led me to think why
can't we have an SM version which is generic enough so that both my version
and Lucene's can benefit from?
The way I see SearcherManager, it can be divided into two parts: (1) the part
that manages the logic of acquire/release/maybeReopen (i.e., ensureOpen,
protect from concurrency stuff etc.), and (2) the part which handles
IndexSearcher, or my SearcherTaxoPair. I'm thinking that if we'll have an
interface with incRef/decRef/tryIncRef/maybeRefresh, we can make
SearcherManager a generic class which handles this interface.
I will post a patch with the initial idea, and we can continue from there.

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

[jira] [Created] (LUCENE-3785) Replace ant macros for running concurrent tests with ant-junit4.

2012-02-14 Thread Dawid Weiss (Created) (JIRA)

Replace ant macros for running concurrent tests with ant-junit4.


 Key: LUCENE-3785
 URL: https://issues.apache.org/jira/browse/LUCENE-3785
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: general/build, general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Minor
 Fix For: 4.0


ant-junit4 is an ANT task for running tests in parallel (on slave JVMs). Its 
advantages over the current macros:
- dynamic load balancing based on historical test runs and current execution 
(job-stealing),
- jvm-crash resilience (I wrote tests that actually crash a slave jvms to make 
sure such an event is reported appropriately),
- nicer console reporting (no need for syserrs on LuceneTestCase level).

More documentation and info will follow as I roll out a patch.

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



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

[jira] [Created] (LUCENE-3786) Create SearcherTaxoManager

2012-02-14 Thread Shai Erera (Created) (JIRA)

Create SearcherTaxoManager
--

 Key: LUCENE-3786
 URL: https://issues.apache.org/jira/browse/LUCENE-3786
 Project: Lucene - Java
  Issue Type: New Feature
  Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera
Priority: Minor
 Fix For: 3.6, 4.0


If an application wants to use an IndexSearcher and TaxonomyReader in a 
SearcherManager-like fashion, it cannot use a separate SearcherManager, and say 
a TaxonomyReaderManager, because the IndexSearcher and TaxoReader instances 
need to be in sync. That is, the IS-TR pair must match, or otherwise the 
category ordinals that are encoded in the search index might not match the ones 
in the taxonomy index.

This can happen if someone reopens the IndexSearcher's IndexReader, but does 
not refresh the TaxonomyReader, and the category ordinals that exist in the 
reopened IndexReader are not yet visible to the TaxonomyReader instance.

I'd like to create a SearcherTaxoManager (which is a ReferenceManager) which 
manages an IndexSearcher and TaxonomyReader pair. Then an application will call:
{code}
SearcherTaxoPair pair = manager.acquire();
try {
  IndexSearcher searcher = pair.searcher;
  TaxonomyReader taxoReader = pair.taxoReader;
  // do something with them
} finally {
  manager.release(pair);
  pair = null;
}
{code}


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



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

[JENKINS] Lucene-Solr-tests-only-3.x-java7 - Build # 1761 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/1761/

No tests ran.

Build Log (for compile errors):
[...truncated 53 lines...]
+ 
ARTIFACTS=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/artifacts
+ 
JAVADOCS_ARTIFACTS=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/javadocs
+ 
DUMP_DIR=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/heapdumps
+ TESTS_MULTIPLIER=3
+ TEST_LINE_DOCS_FILE=/home/hudson/lucene-data/enwiki.random.lines.txt.gz
+ TEST_JVM_ARGS='-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/heapdumps/
 '
+ set +x
+ mkdir -p 
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/heapdumps
+ rm -rf 
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/heapdumps/README.txt
+ echo 'This directory contains heap dumps that may be generated by test runs 
when OOM occurred.'
+ TESTS_MULTIPLIER=5
+ cd 
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout
+ JAVA_HOME=/home/hudson/tools/java/latest1.5 
/home/hudson/tools/ant/latest1.7/bin/ant clean
Buildfile: build.xml

clean:

clean:
   [delete] Deleting directory 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/build
 [echo] Building solr...

clean:
   [delete] Deleting directory 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/solr/build
 [echo] TODO: fix tests to not write files to 
'core/src/test-files/solr/data'!
   [delete] Deleting directory 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/solr/core/src/test-files/solr/data

BUILD SUCCESSFUL
Total time: 2 seconds
+ cd 
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene
+ JAVA_HOME=/home/hudson/tools/java/latest1.5 
/home/hudson/tools/ant/latest1.7/bin/ant compile compile-test build-contrib 
compile-backwards
Buildfile: build.xml

compile-lucene-core:

jflex-uptodate-check:

jflex-notice:

javacc-uptodate-check:

javacc-notice:

init:

clover.setup:

clover.info:
 [echo] 
 [echo]   Clover not found. Code coverage reports disabled.
 [echo] 

clover:

common.compile-core:
[mkdir] Created dir: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/build/core/classes/java
[javac] Compiling 499 source files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/build/core/classes/java
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/core/src/java/org/apache/lucene/queryParser/CharStream.java:34:
 warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac]   int getColumn();
[javac]   ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/core/src/java/org/apache/lucene/queryParser/CharStream.java:41:
 warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac]   int getLine();
[javac]   ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/core/src/java/org/apache/lucene/search/SearcherManager.java:123:
 warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac]   public final boolean maybeReopen() throws IOException {
[javac]^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 3 warnings

compile-core:

compile-core:

compile:

compile-lucene-core:

compile-test-framework:

init:

compile-lucene-core:

compile-core:
[mkdir] Created dir: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/build/test-framework/classes/java
[javac] Compiling 37 source files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/build/test-framework/classes/java
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:393:
 method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:452:
 method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:483:
 method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac]

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 12431 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12431/

No tests ran.

Build Log (for compile errors):
[...truncated 55 lines...]
+ 
ARTIFACTS=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/artifacts
+ 
JAVADOCS_ARTIFACTS=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/javadocs
+ 
DUMP_DIR=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/heapdumps
+ TESTS_MULTIPLIER=3
+ TEST_LINE_DOCS_FILE=/home/hudson/lucene-data/enwiki.random.lines.txt.gz
+ TEST_JVM_ARGS='-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/heapdumps/
 '
+ set +x
+ mkdir -p 
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/heapdumps
+ rm -rf 
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/heapdumps/README.txt
+ echo 'This directory contains heap dumps that may be generated by test runs 
when OOM occurred.'
+ TESTS_MULTIPLIER=5
+ cd /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout
+ JAVA_HOME=/home/hudson/tools/java/latest1.5 
/home/hudson/tools/ant/latest1.7/bin/ant clean
Buildfile: build.xml

clean:

clean:
   [delete] Deleting directory 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/build
 [echo] Building solr...

clean:
   [delete] Deleting directory 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/build
 [echo] TODO: fix tests to not write files to 
'core/src/test-files/solr/data'!
   [delete] Deleting directory 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/core/src/test-files/solr/data

BUILD SUCCESSFUL
Total time: 2 seconds
+ cd 
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene
+ JAVA_HOME=/home/hudson/tools/java/latest1.5 
/home/hudson/tools/ant/latest1.7/bin/ant compile compile-test build-contrib 
compile-backwards
Buildfile: build.xml

compile-lucene-core:

jflex-uptodate-check:

jflex-notice:

javacc-uptodate-check:

javacc-notice:

init:

clover.setup:

clover.info:
 [echo] 
 [echo]   Clover not found. Code coverage reports disabled.
 [echo] 

clover:

common.compile-core:
[mkdir] Created dir: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/build/core/classes/java
[javac] Compiling 499 source files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/build/core/classes/java
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/core/src/java/org/apache/lucene/queryParser/CharStream.java:34:
 warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac]   int getColumn();
[javac]   ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/core/src/java/org/apache/lucene/queryParser/CharStream.java:41:
 warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac]   int getLine();
[javac]   ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/core/src/java/org/apache/lucene/search/SearcherManager.java:123:
 warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac]   public final boolean maybeReopen() throws IOException {
[javac]^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 3 warnings

compile-core:

compile-core:

compile:

compile-lucene-core:

compile-test-framework:

init:

compile-lucene-core:

compile-core:
[mkdir] Created dir: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/build/test-framework/classes/java
[javac] Compiling 37 source files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/build/test-framework/classes/java
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:393:
 method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:452:
 method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:483:
 method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:599:
 method does not override a method

[jira] [Commented] (LUCENE-3714) add suggester that uses shortest path/wFST instead of buckets

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

Robert Muir commented on LUCENE-3714:
-

I played with a lot of variations on this patch:
* generified the shortest path method to take things like Comparators/Comparable
* tried different algebra/representations with that

I think we should keep the code wired to Long for now. according to the
benchmark
any generification is like a 5-10% overall perf hit, and I don't see a need for
anything but Long.

I think as far as representation, we need to integrate the offline sort, find
min/max
float values and scale to precision space, e.g. if precision is 32 then
Integer.MAX_VALUE - scaledWeight.

I tried different representations and they just add more complexity (e.g.
negative outputs),
without saving much space at all. This patch uses Integer precision and is only
10% larger
than the previous impl.

We don't even need precision to be configurable really,
we could wire it to integers as a start. But maybe later someone could specify
it, e.g.
if they specified 8 then they basically get the same result as bucketed
algorithm today...

add suggester that uses shortest path/wFST instead of buckets
-

Key: LUCENE-3714
URL: https://issues.apache.org/jira/browse/LUCENE-3714
Project: Lucene - Java
Issue Type: New Feature
Components: modules/spellchecker
Reporter: Robert Muir
Attachments: LUCENE-3714.patch, LUCENE-3714.patch, LUCENE-3714.patch,
LUCENE-3714.patch, LUCENE-3714.patch, TestMe.java, out.png

Currently the FST suggester (really an FSA) quantizes weights into buckets
(e.g. single byte) and puts them in front of the word.
This makes it fast, but you lose granularity in your suggestions.
Lately the question was raised, if you build lucene's FST with
positiveintoutputs, does it behave the same as a tropical semiring wFST?
In other words, after completing the word, we instead traverse min(output) at
each node to find the 'shortest path' to the
best suggestion (with the highest score).
This means we wouldnt need to quantize weights at all and it might make some
operations (e.g. adding fuzzy matching etc) a lot easier.

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

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

2012-02-14 Thread Shai Erera

javadoc error. committed a fix.

Shai

On Tue, Feb 14, 2012 at 5:56 PM, Apache Jenkins Server 
jenk...@builds.apache.org wrote:

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

 No tests ran.

 Build Log (for compile errors):
 [...truncated 7209 lines...]




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

Re: svn commit: r1244000 - in /lucene/dev/trunk: ./ lucene/ lucene/core/src/java/org/apache/lucene/search/ lucene/core/src/test/org/apache/lucene/search/ lucene/test-framework/src/java/org/apache/luce

2012-02-14 Thread Simon Willnauer

shai, seems like you missed the CHANGES.TXT from branch_3x?

simon

On Tue, Feb 14, 2012 at 4:36 PM,  sh...@apache.org wrote:
 Author: shaie
 Date: Tue Feb 14 15:36:14 2012
 New Revision: 1244000

 URL: http://svn.apache.org/viewvc?rev=1244000view=rev
 Log:
 LUCENE-3761: generalize SearcherManager (port to trunk)

 Added:
    
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/ReferenceManager.java
      - copied unchanged from r1243906, 
 lucene/dev/branches/branch_3x/lucene/core/src/java/org/apache/lucene/search/ReferenceManager.java
 Modified:
    lucene/dev/trunk/   (props changed)
    lucene/dev/trunk/lucene/   (props changed)
    
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/NRTManager.java
    
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/SearcherManager.java
    
 lucene/dev/trunk/lucene/core/src/test/org/apache/lucene/search/TestSearcherManager.java
    
 lucene/dev/trunk/lucene/test-framework/src/java/org/apache/lucene/search/ShardSearchingTestBase.java

 Modified: 
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/NRTManager.java
 URL: 
 http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/NRTManager.java?rev=1244000r1=1243999r2=1244000view=diff
 ==
 --- 
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/NRTManager.java
  (original)
 +++ 
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/NRTManager.java
  Tue Feb 14 15:36:14 2012
 @@ -343,7 +343,7 @@ public class NRTManager implements Close
         }
         boolean setSearchGen;
         if (!mgr.isSearcherCurrent()) {
 -          setSearchGen = mgr.maybeReopen();
 +          setSearchGen = mgr.maybeRefresh();
         } else {
           setSearchGen = true;
         }

 Modified: 
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/SearcherManager.java
 URL: 
 http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/SearcherManager.java?rev=1244000r1=1243999r2=1244000view=diff
 ==
 --- 
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/SearcherManager.java
  (original)
 +++ 
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/SearcherManager.java
  Tue Feb 14 15:36:14 2012
 @@ -17,17 +17,11 @@ package org.apache.lucene.search;
  * limitations under the License.
  */

 -import java.io.Closeable;
  import java.io.IOException;
 -import java.util.concurrent.Semaphore;

 -import org.apache.lucene.index.CorruptIndexException;
  import org.apache.lucene.index.IndexReader;
  import org.apache.lucene.index.DirectoryReader;
  import org.apache.lucene.index.IndexWriter;
 -import org.apache.lucene.search.NRTManager; // javadocs
 -import org.apache.lucene.search.IndexSearcher; // javadocs
 -import org.apache.lucene.store.AlreadyClosedException;
  import org.apache.lucene.store.Directory;

  /**
 @@ -51,42 +45,40 @@ import org.apache.lucene.store.Directory
  * /pre
  *
  * p
 - * In addition you should periodically call {@link #maybeReopen}. While it's
 + * In addition you should periodically call {@link #maybeRefresh}. While it's
  * possible to call this just before running each query, this is discouraged
  * since it penalizes the unlucky queries that do the reopen. It's better to 
 use
  * a separate background thread, that periodically calls maybeReopen. Finally,
  * be sure to call {@link #close} once you are done.
  *
 - * p
 - * bNOTE/b: if you have an {@link IndexWriter}, it's better to use
 - * {@link NRTManager} since that class pulls near-real-time readers from the
 - * IndexWriter.
 - *
  * @see SearcherFactory
  *
  * @lucene.experimental
  */
 +public final class SearcherManager extends ReferenceManagerIndexSearcher {

 -public final class SearcherManager implements Closeable {
 -
 -  private volatile IndexSearcher currentSearcher;
   private final SearcherFactory searcherFactory;
 -  private final Semaphore reopenLock = new Semaphore(1);
 -
 +
   /**
 -   * Creates and returns a new SearcherManager from the given {@link 
 IndexWriter}.
 -   * @param writer the IndexWriter to open the IndexReader from.
 -   * @param applyAllDeletes If codetrue/code, all buffered deletes will
 -   *        be applied (made visible) in the {@link IndexSearcher} / {@link 
 DirectoryReader}.
 -   *        If codefalse/code, the deletes may or may not be applied, 
 but remain buffered
 -   *        (in IndexWriter) so that they will be applied in the future.
 -   *        Applying deletes can be costly, so if your app can tolerate 
 deleted documents
 -   *        being returned you might gain some performance by passing 
 codefalse/code.
 -   *        See {@link DirectoryReader#openIfChanged(DirectoryReader, 
 IndexWriter, boolean)}.
 -   * @param searcherFactory An optional {@link SearcherFactory}. Pass
 -

[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12420 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12420/

All tests passed

Build Log (for compile errors):
[...truncated 12802 lines...]



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

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 12432 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12432/

No tests ran.

Build Log (for compile errors):
[...truncated 24 lines...]
+ MODULES_DIR=checkout/modules
+ SOLR_DIR=checkout/solr
+ 
ARTIFACTS=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/artifacts
+ 
JAVADOCS_ARTIFACTS=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/javadocs
+ 
DUMP_DIR=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/heapdumps
+ TESTS_MULTIPLIER=3
+ TEST_LINE_DOCS_FILE=/home/hudson/lucene-data/enwiki.random.lines.txt.gz
+ TEST_JVM_ARGS='-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/heapdumps/
 '
+ set +x
+ mkdir -p 
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/heapdumps
+ rm -rf 
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/heapdumps/README.txt
+ echo 'This directory contains heap dumps that may be generated by test runs 
when OOM occurred.'
+ TESTS_MULTIPLIER=5
+ cd /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout
+ JAVA_HOME=/home/hudson/tools/java/latest1.5 
/home/hudson/tools/ant/latest1.7/bin/ant clean
Buildfile: build.xml

clean:

clean:
   [delete] Deleting directory 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/build
 [echo] Building solr...

clean:
 [echo] TODO: fix tests to not write files to 
'core/src/test-files/solr/data'!

BUILD SUCCESSFUL
Total time: 0 seconds
+ cd 
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene
+ JAVA_HOME=/home/hudson/tools/java/latest1.5 
/home/hudson/tools/ant/latest1.7/bin/ant compile compile-test build-contrib 
compile-backwards
Buildfile: build.xml

compile-lucene-core:

jflex-uptodate-check:

jflex-notice:

javacc-uptodate-check:

javacc-notice:

init:

clover.setup:

clover.info:
 [echo] 
 [echo]   Clover not found. Code coverage reports disabled.
 [echo] 

clover:

common.compile-core:
[mkdir] Created dir: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/build/core/classes/java
[javac] Compiling 499 source files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/build/core/classes/java
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/core/src/java/org/apache/lucene/queryParser/CharStream.java:34:
 warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac]   int getColumn();
[javac]   ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/core/src/java/org/apache/lucene/queryParser/CharStream.java:41:
 warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac]   int getLine();
[javac]   ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/core/src/java/org/apache/lucene/search/SearcherManager.java:123:
 warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac]   public final boolean maybeReopen() throws IOException {
[javac]^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 3 warnings

compile-core:

compile-core:

compile:

compile-lucene-core:

compile-test-framework:

init:

compile-lucene-core:

compile-core:
[mkdir] Created dir: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/build/test-framework/classes/java
[javac] Compiling 37 source files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/build/test-framework/classes/java
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:393:
 method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:452:
 method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:483:
 method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:599:
 method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.

[JENKINS] Lucene-Solr-tests-only-3.x-java7 - Build # 1762 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/1762/

No tests ran.

Build Log (for compile errors):
[...truncated 24 lines...]
+ MODULES_DIR=checkout/modules
+ SOLR_DIR=checkout/solr
+ 
ARTIFACTS=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/artifacts
+ 
JAVADOCS_ARTIFACTS=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/javadocs
+ 
DUMP_DIR=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/heapdumps
+ TESTS_MULTIPLIER=3
+ TEST_LINE_DOCS_FILE=/home/hudson/lucene-data/enwiki.random.lines.txt.gz
+ TEST_JVM_ARGS='-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/heapdumps/
 '
+ set +x
+ mkdir -p 
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/heapdumps
+ rm -rf 
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/heapdumps/README.txt
+ echo 'This directory contains heap dumps that may be generated by test runs 
when OOM occurred.'
+ TESTS_MULTIPLIER=5
+ cd 
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout
+ JAVA_HOME=/home/hudson/tools/java/latest1.5 
/home/hudson/tools/ant/latest1.7/bin/ant clean
Buildfile: build.xml

clean:

clean:
   [delete] Deleting directory 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/build
 [echo] Building solr...

clean:
 [echo] TODO: fix tests to not write files to 
'core/src/test-files/solr/data'!

BUILD SUCCESSFUL
Total time: 0 seconds
+ cd 
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene
+ JAVA_HOME=/home/hudson/tools/java/latest1.5 
/home/hudson/tools/ant/latest1.7/bin/ant compile compile-test build-contrib 
compile-backwards
Buildfile: build.xml

compile-lucene-core:

jflex-uptodate-check:

jflex-notice:

javacc-uptodate-check:

javacc-notice:

init:

clover.setup:

clover.info:
 [echo] 
 [echo]   Clover not found. Code coverage reports disabled.
 [echo] 

clover:

common.compile-core:
[mkdir] Created dir: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/build/core/classes/java
[javac] Compiling 499 source files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/build/core/classes/java
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/core/src/java/org/apache/lucene/queryParser/CharStream.java:34:
 warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac]   int getColumn();
[javac]   ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/core/src/java/org/apache/lucene/queryParser/CharStream.java:41:
 warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac]   int getLine();
[javac]   ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/core/src/java/org/apache/lucene/search/SearcherManager.java:123:
 warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac]   public final boolean maybeReopen() throws IOException {
[javac]^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 3 warnings

compile-core:

compile-core:

compile:

compile-lucene-core:

compile-test-framework:

init:

compile-lucene-core:

compile-core:
[mkdir] Created dir: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/build/test-framework/classes/java
[javac] Compiling 37 source files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/build/test-framework/classes/java
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:393:
 method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:452:
 method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:483:
 method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac] 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x-java7/checkout/lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java:599:
 method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac] Note:

RE: I have my name on the staging site

2012-02-14 Thread Dyer, James

got it.   Also I updated a few links in the wiki, and put an obsolete notice 
(with a link) on the page about editing Forrest.

James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311


-Original Message-
From: Chris Hostetter [mailto:hossman_luc...@fucit.org] 

(wana update the instructions too?)


-Hoss

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


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

[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1734 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1734/

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.RecoveryZkTest

Error Message:
ERROR: SolrIndexSearcher opens=13 closes=12

Stack Trace:
junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=13 
closes=12
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:152)
at 
org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:76)




Build Log (for compile errors):
[...truncated 10010 lines...]



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

Re: Test failure in modules/benchmark/: byTask.TestPerfTasksLogic

2012-02-14 Thread Shai Erera

Found the problem, though I don't understand why didn't it always (!!!)
fail.

The problem is that DocMaker.setConfig initializes the ContentSource,
however it doesn't close it first if its current instance is not null. How
can this happen? If your .alg has a resetInputs (and such) tasks, then
DocMaker.resetInputs is called, which calls DocMaker.setConfig ...

Like I wrote, I have no idea why doesn't it always fail. In fact, here's a
short test that reproduces it, and always fails irregardless of seeds:

public void testDocMakerLeak() throws Exception {
Properties props = new Properties();
props.setProperty(content.source,
org.apache.lucene.benchmark.byTask.feeds.LineDocSource);
props.setProperty(docs.file, getReuters20LinesFile());
props.setProperty(content.source.forever, false);
PerfRunData runData = new PerfRunData(new Config(props));

// this causes the leak !
ResetInputsTask reset = new ResetInputsTask(runData);
reset.doLogic();
reset.close();

runData.close();
  }

But now Robert tells me that it passes for him, which leaves me baffled
again ..

Anyway, if you add this to DocMaker.setConfig (inside the first try), it
fixes the bug (and there's definitely a bug):

if (source != null) {
  source.close();
}

I will fix it on both trunk and 3x (where the bug exists too !) and add the
above test to TestDocMaker.

Shai

On Mon, Feb 13, 2012 at 8:06 PM, Robert Muir rcm...@gmail.com wrote:

 I poked around... I got nothing. We should probably just open an
 issue, maybe someone else can see the bug.

 On Mon, Feb 13, 2012 at 12:48 PM, Robert Muir rcm...@gmail.com wrote:
  The previous time we had these problems, I committed a half-way fix
  admitting there were still sporatic problems.
 
  So i traced this down a little more, you can add
  -Dtestmethod=testParallelExhausted to steven's 'reproduce-with'
  command-line and it fails. all other test methods are fine.
 
  So testParallelExhausted (with the seed etc he specified) is somehow
  doing something to create a leak... it looks the same as the other
  methods so I suspect the leak is not in test code but in benchmark
  code.
 
  On Mon, Feb 13, 2012 at 12:46 PM, Uwe Schindler u...@thetaphi.de wrote:
  I have the feeling we already fixed that or tried to? Robert?
 
  Uwe
  --
  Uwe Schindler
  H.-H.-Meier-Allee 63, 28213 Bremen
  http://www.thetaphi.de
 
 
 
  Robert Muir rcm...@gmail.com schrieb:
 
  On Sat, Feb 11, 2012 at 1:35 PM, Steven A Rowe sar...@syr.edu wrote:
   This fails 100% of the time for me with the given seed, and passes
 when
   I don't specify the seed:
  
 
  fails for me too on a windows box with no virus scanners. So I think
  in some situations we still have reuters.first20.lines.txt open.
 
  --
  lucidimagination.com
 
  
 
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 
 
 
  --
  lucidimagination.com



 --
 lucidimagination.com

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

Re: svn commit: r1244000 - in /lucene/dev/trunk: ./ lucene/ lucene/core/src/java/org/apache/lucene/search/ lucene/core/src/test/org/apache/lucene/search/ lucene/test-framework/src/java/org/apache/luce

2012-02-14 Thread Shai Erera

I wasn't sure if the CHANGES is needed in trunk as well, since the change
was also done in 3x ... so I asked Robert and he said that he doesn't think
that we need an entry in trunk as well, which makes sense to me because
trunk is not yet released ..

What's our policy about this? because I keep asking myself in every commit
whether I need to port CHANGES to trunk too ...

Shai

On Tue, Feb 14, 2012 at 6:18 PM, Simon Willnauer 
simon.willna...@googlemail.com wrote:

 shai, seems like you missed the CHANGES.TXT from branch_3x?

 simon

 On Tue, Feb 14, 2012 at 4:36 PM,  sh...@apache.org wrote:
  Author: shaie
  Date: Tue Feb 14 15:36:14 2012
  New Revision: 1244000
 
  URL: http://svn.apache.org/viewvc?rev=1244000view=rev
  Log:
  LUCENE-3761: generalize SearcherManager (port to trunk)
 
  Added:
 
  
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/ReferenceManager.java
   - copied unchanged from r1243906,
 lucene/dev/branches/branch_3x/lucene/core/src/java/org/apache/lucene/search/ReferenceManager.java
  Modified:
 lucene/dev/trunk/   (props changed)
 lucene/dev/trunk/lucene/   (props changed)
 
  
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/NRTManager.java
 
  
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/SearcherManager.java
 
  
 lucene/dev/trunk/lucene/core/src/test/org/apache/lucene/search/TestSearcherManager.java
 
  
 lucene/dev/trunk/lucene/test-framework/src/java/org/apache/lucene/search/ShardSearchingTestBase.java
 
  Modified:
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/NRTManager.java
  URL:
 http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/NRTManager.java?rev=1244000r1=1243999r2=1244000view=diff
 
 ==
  ---
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/NRTManager.java
 (original)
  +++
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/NRTManager.java
 Tue Feb 14 15:36:14 2012
  @@ -343,7 +343,7 @@ public class NRTManager implements Close
  }
  boolean setSearchGen;
  if (!mgr.isSearcherCurrent()) {
  -  setSearchGen = mgr.maybeReopen();
  +  setSearchGen = mgr.maybeRefresh();
  } else {
setSearchGen = true;
  }
 
  Modified:
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/SearcherManager.java
  URL:
 http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/SearcherManager.java?rev=1244000r1=1243999r2=1244000view=diff
 
 ==
  ---
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/SearcherManager.java
 (original)
  +++
 lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/SearcherManager.java
 Tue Feb 14 15:36:14 2012
  @@ -17,17 +17,11 @@ package org.apache.lucene.search;
   * limitations under the License.
   */
 
  -import java.io.Closeable;
   import java.io.IOException;
  -import java.util.concurrent.Semaphore;
 
  -import org.apache.lucene.index.CorruptIndexException;
   import org.apache.lucene.index.IndexReader;
   import org.apache.lucene.index.DirectoryReader;
   import org.apache.lucene.index.IndexWriter;
  -import org.apache.lucene.search.NRTManager; // javadocs
  -import org.apache.lucene.search.IndexSearcher; // javadocs
  -import org.apache.lucene.store.AlreadyClosedException;
   import org.apache.lucene.store.Directory;
 
   /**
  @@ -51,42 +45,40 @@ import org.apache.lucene.store.Directory
   * /pre
   *
   * p
  - * In addition you should periodically call {@link #maybeReopen}. While
 it's
  + * In addition you should periodically call {@link #maybeRefresh}.
 While it's
   * possible to call this just before running each query, this is
 discouraged
   * since it penalizes the unlucky queries that do the reopen. It's
 better to use
   * a separate background thread, that periodically calls maybeReopen.
 Finally,
   * be sure to call {@link #close} once you are done.
   *
  - * p
  - * bNOTE/b: if you have an {@link IndexWriter}, it's better to use
  - * {@link NRTManager} since that class pulls near-real-time readers
 from the
  - * IndexWriter.
  - *
   * @see SearcherFactory
   *
   * @lucene.experimental
   */
  +public final class SearcherManager extends
 ReferenceManagerIndexSearcher {
 
  -public final class SearcherManager implements Closeable {
  -
  -  private volatile IndexSearcher currentSearcher;
private final SearcherFactory searcherFactory;
  -  private final Semaphore reopenLock = new Semaphore(1);
  -
  +
/**
  -   * Creates and returns a new SearcherManager from the given {@link
 IndexWriter}.
  -   * @param writer the IndexWriter to open the IndexReader from.
  -   * @param applyAllDeletes If codetrue/code, all buffered deletes
 will
  -   *be applied (made visible) in the {@link IndexSearcher} /

RE: Test failure in modules/benchmark/: byTask.TestPerfTasksLogic

2012-02-14 Thread Steven A Rowe

Thanks Shai!

From: Shai Erera [mailto:ser...@gmail.com]
Sent: Tuesday, February 14, 2012 12:17 PM
To: dev@lucene.apache.org
Subject: Re: Test failure in modules/benchmark/: byTask.TestPerfTasksLogic

Found the problem, though I don't understand why didn't it always (!!!) fail.

The problem is that DocMaker.setConfig initializes the ContentSource, however 
it doesn't close it first if its current instance is not null. How can this 
happen? If your .alg has a resetInputs (and such) tasks, then 
DocMaker.resetInputs is called, which calls DocMaker.setConfig ...

Like I wrote, I have no idea why doesn't it always fail. In fact, here's a 
short test that reproduces it, and always fails irregardless of seeds:

public void testDocMakerLeak() throws Exception {
Properties props = new Properties();
props.setProperty(content.source, 
org.apache.lucene.benchmark.byTask.feeds.LineDocSource);
props.setProperty(docs.file, getReuters20LinesFile());
props.setProperty(content.source.forever, false);
PerfRunData runData = new PerfRunData(new Config(props));

// this causes the leak !
ResetInputsTask reset = new ResetInputsTask(runData);
reset.doLogic();
reset.close();

runData.close();
  }

But now Robert tells me that it passes for him, which leaves me baffled again ..

Anyway, if you add this to DocMaker.setConfig (inside the first try), it fixes 
the bug (and there's definitely a bug):

if (source != null) {
  source.close();
}

I will fix it on both trunk and 3x (where the bug exists too !) and add the 
above test to TestDocMaker.

Shai
On Mon, Feb 13, 2012 at 8:06 PM, Robert Muir 
rcm...@gmail.commailto:rcm...@gmail.com wrote:
I poked around... I got nothing. We should probably just open an
issue, maybe someone else can see the bug.

On Mon, Feb 13, 2012 at 12:48 PM, Robert Muir 
rcm...@gmail.commailto:rcm...@gmail.com wrote:
 The previous time we had these problems, I committed a half-way fix
 admitting there were still sporatic problems.

 So i traced this down a little more, you can add
 -Dtestmethod=testParallelExhausted to steven's 'reproduce-with'
 command-line and it fails. all other test methods are fine.

 So testParallelExhausted (with the seed etc he specified) is somehow
 doing something to create a leak... it looks the same as the other
 methods so I suspect the leak is not in test code but in benchmark
 code.

 On Mon, Feb 13, 2012 at 12:46 PM, Uwe Schindler 
 u...@thetaphi.demailto:u...@thetaphi.de wrote:
 I have the feeling we already fixed that or tried to? Robert?

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

 Robert Muir rcm...@gmail.commailto:rcm...@gmail.com schrieb:

 On Sat, Feb 11, 2012 at 1:35 PM, Steven A Rowe 
 sar...@syr.edumailto:sar...@syr.edu wrote:
  This fails 100% of the time for me with the given seed, and passes when
  I don't specify the seed:

 fails for me too on a windows box with no virus scanners. So I think
 in some situations we still have reuters.first20.lines.txt open.

 --
 lucidimagination.comhttp://lucidimagination.com

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

 --
 lucidimagination.comhttp://lucidimagination.com

--
lucidimagination.comhttp://lucidimagination.com

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

RE: svn commit: r1244000 - in /lucene/dev/trunk: ./ lucene/ lucene/core/src/java/org/apache/lucene/search/ lucene/core/src/test/org/apache/lucene/search/ lucene/test-framework/src/java/org/apache/luce

2012-02-14 Thread Uwe Schindler

When you merge from 3.x to trunk or the other way round it will
automatically merge the entries. Most of us always merge also the changes.
E.g. if I do a change that's released for the first time in 3.x, I do the
change first on trunk, but already put it in trunk into the changes. Then I
merge to 3.x and all is fine, no conflicts, always works.

 

I am not sure why you always fix bugs on 3.x and then merge to trunk, but
that should not matter for that.

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

 http://www.thetaphi.de/ http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Shai Erera [mailto:ser...@gmail.com] 
Sent: Tuesday, February 14, 2012 6:19 PM
To: dev@lucene.apache.org; simon.willna...@gmail.com
Subject: Re: svn commit: r1244000 - in /lucene/dev/trunk: ./ lucene/
lucene/core/src/java/org/apache/lucene/search/
lucene/core/src/test/org/apache/lucene/search/
lucene/test-framework/src/java/org/apache/lucene/search/

 

I wasn't sure if the CHANGES is needed in trunk as well, since the change
was also done in 3x ... so I asked Robert and he said that he doesn't think
that we need an entry in trunk as well, which makes sense to me because
trunk is not yet released ..

What's our policy about this? because I keep asking myself in every commit
whether I need to port CHANGES to trunk too ...

Shai

On Tue, Feb 14, 2012 at 6:18 PM, Simon Willnauer
simon.willna...@googlemail.com wrote:

shai, seems like you missed the CHANGES.TXT from branch_3x?

simon

On Tue, Feb 14, 2012 at 4:36 PM,  sh...@apache.org wrote:
 Author: shaie
 Date: Tue Feb 14 15:36:14 2012
 New Revision: 1244000

 URL: http://svn.apache.org/viewvc?rev=1244000
http://svn.apache.org/viewvc?rev=1244000view=rev view=rev
 Log:
 LUCENE-3761: generalize SearcherManager (port to trunk)

 Added:

lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/ReferenceMana
ger.java
  - copied unchanged from r1243906,
lucene/dev/branches/branch_3x/lucene/core/src/java/org/apache/lucene/search/
ReferenceManager.java
 Modified:
lucene/dev/trunk/   (props changed)
lucene/dev/trunk/lucene/   (props changed)

lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/NRTManager.ja
va

lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/SearcherManag
er.java

lucene/dev/trunk/lucene/core/src/test/org/apache/lucene/search/TestSearcherM
anager.java

lucene/dev/trunk/lucene/test-framework/src/java/org/apache/lucene/search/Sha
rdSearchingTestBase.java

 Modified:
lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/NRTManager.ja
va
 URL:
http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apach
e/lucene/search/NRTManager.java?rev=1244000
http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apac
he/lucene/search/NRTManager.java?rev=1244000r1=1243999r2=1244000view=diff
 r1=1243999r2=1244000view=diff


==
 ---
lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/NRTManager.ja
va (original)
 +++
lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/NRTManager.ja
va Tue Feb 14 15:36:14 2012
 @@ -343,7 +343,7 @@ public class NRTManager implements Close
 }
 boolean setSearchGen;
 if (!mgr.isSearcherCurrent()) {
 -  setSearchGen = mgr.maybeReopen();
 +  setSearchGen = mgr.maybeRefresh();
 } else {
   setSearchGen = true;
 }

 Modified:
lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/SearcherManag
er.java
 URL:
http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apach
e/lucene/search/SearcherManager.java?rev=1244000
http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apac
he/lucene/search/SearcherManager.java?rev=1244000r1=1243999r2=1244000view
=diff r1=1243999r2=1244000view=diff


==
 ---
lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/SearcherManag
er.java (original)
 +++
lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/SearcherManag
er.java Tue Feb 14 15:36:14 2012
 @@ -17,17 +17,11 @@ package org.apache.lucene.search;
  * limitations under the License.
  */

 -import java.io.Closeable;
  import java.io.IOException;
 -import java.util.concurrent.Semaphore;

 -import org.apache.lucene.index.CorruptIndexException;
  import org.apache.lucene.index.IndexReader;
  import org.apache.lucene.index.DirectoryReader;
  import org.apache.lucene.index.IndexWriter;
 -import org.apache.lucene.search.NRTManager; // javadocs
 -import org.apache.lucene.search.IndexSearcher; // javadocs
 -import org.apache.lucene.store.AlreadyClosedException;
  import org.apache.lucene.store.Directory;

  /**
 @@ -51,42 +45,40 @@ import org.apache.lucene.store.Directory
  * /pre
  *
  * p
 - * In addition you should periodically call {@link #maybeReopen}. While
it's
 + * In addition you

Re: new Admin UI and license information

2012-02-14 Thread Erick Erickson

Hmmm, I just happened to notice this, I'm not really a license cop...

But what the heck. Off the top of my head,
html, js, jsp, vm and tpl are extensions that may make sense to look at.

Erick

On Tue, Feb 14, 2012 at 10:19 AM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
 By the way -- that license-check macro can work with any files, not
 only with *.jar files. It's basically a mapping from a fileset
 resources to other resource names. I can help in adding validation for
 *.js or whatever so that they are checked for licenses too.

 Dawid

 On Tue, Feb 14, 2012 at 3:07 PM, Erick Erickson erickerick...@gmail.com 
 wrote:
 While I was working on some of the LukeRequestHandler speedups, I
 noticed that there were no license notifications in the new Admin UI
 code, so I stuck some in and committed it (r: 1243925). Two questions:

 1 Is there any need for a JIRA here?
 2 ...solr/webapp/web/js/jquery.sparkline.js and a couple of others
 already had a license notification in them. I added in the Apache
 license information, should I have?

 Thanks,
 Erick

 P.S. I did a very quick triage to see that that I didn't use, say, the
 wrong comment form, but it was *very* quick. If functionality has
 disappeared mysteriously, here's where I'd look first.

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


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


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

[jira] [Updated] (LUCENE-2632) FilteringCodec, TeeCodec, TeeDirectory

2012-02-14 Thread Robert Muir (Updated) (JIRA)

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

Robert Muir updated LUCENE-2632:

Attachment: LUCENE-2632.patch

Updated patch from andrzej's fixing the FNFE in merge (though it fails for
other reasons, one step at a time).

The problem is due to the strange way in which Norms-writers extend
PerDocConsumer... they override canMerge/getDocValuesForMerge/getDocValuesType
completely differently.

Furthermore you could not delegate these, as they are protected.

as a temporary hack i made them public and delegated in Tee's impl... but I'm
going to instead open a separate issue to clean this up.

FilteringCodec, TeeCodec, TeeDirectory
--

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

Re: new Admin UI and license information

2012-02-14 Thread Robert Muir

We also have 'ant rat-sources' which works from within any module (yes
Dawid, this one actually would be better top-level!)

for it to work, just put apache-rat-0.8.jar in your ~/.ant/lib

On Tue, Feb 14, 2012 at 12:58 PM, Erick Erickson
erickerick...@gmail.com wrote:
 Hmmm, I just happened to notice this, I'm not really a license cop...

 But what the heck. Off the top of my head,
 html, js, jsp, vm and tpl are extensions that may make sense to look at.

 Erick

 On Tue, Feb 14, 2012 at 10:19 AM, Dawid Weiss
 dawid.we...@cs.put.poznan.pl wrote:
 By the way -- that license-check macro can work with any files, not
 only with *.jar files. It's basically a mapping from a fileset
 resources to other resource names. I can help in adding validation for
 *.js or whatever so that they are checked for licenses too.

 Dawid

 On Tue, Feb 14, 2012 at 3:07 PM, Erick Erickson erickerick...@gmail.com 
 wrote:
 While I was working on some of the LukeRequestHandler speedups, I
 noticed that there were no license notifications in the new Admin UI
 code, so I stuck some in and committed it (r: 1243925). Two questions:

 1 Is there any need for a JIRA here?
 2 ...solr/webapp/web/js/jquery.sparkline.js and a couple of others
 already had a license notification in them. I added in the Apache
 license information, should I have?

 Thanks,
 Erick

 P.S. I did a very quick triage to see that that I didn't use, say, the
 wrong comment form, but it was *very* quick. If functionality has
 disappeared mysteriously, here's where I'd look first.

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


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


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




-- 
lucidimagination.com

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

[jira] [Resolved] (SOLR-3130) The new Admin UI code does not contain any Apache licensing information

2012-02-14 Thread Erick Erickson (Resolved) (JIRA)


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

Erick Erickson resolved SOLR-3130.
--

   Resolution: Fixed
Fix Version/s: 4.0

r: 1243925

 The new Admin UI code does not contain any Apache licensing information
 ---

 Key: SOLR-3130
 URL: https://issues.apache.org/jira/browse/SOLR-3130
 Project: Solr
  Issue Type: Task
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.0

 Attachments: SOLR-3130.patch


 What it says. I'll add them in sometime today/tomorrow (Feb 13-14)...

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



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

[jira] [Created] (LUCENE-3787) Improve Norms merging APIs

2012-02-14 Thread Robert Muir (Created) (JIRA)

Improve Norms merging APIs
--

 Key: LUCENE-3787
 URL: https://issues.apache.org/jira/browse/LUCENE-3787
 Project: Lucene - Java
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir


Spinoff from LUCENE-2632, since it took us a fair amount of time to track down,
I think its worth trying to improve the API.

The DocValuesConsumer api's default merge implementation calls 
canMerge/getDocValuesForMerge/getDocValuesType (protected methods).

but its a little strange how this works:
* all norms implementations must override the default DV implementation, or 
they might accidentally merge docvalues into their norms!
* preflex-RW only overrides 2 of these... how is its norms merging working... 
is it?
* its tricky obviously for issues like LUCENE-2632: as delegating merge() is 
not very obvious either.

So I think we should look at this, instead of having all NormsWriters override 
DocValues, redefining these methods in a way thats 
not a is-a relationship, we could do something else like have split 
NormsConsumer/DVConsumer apis that share a package-private base class.

This way a norms impl just extends NormsConsumer and there are no traps. 

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



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

[jira] [Updated] (LUCENE-3754) Store generated archive manifests in per-module output directories

2012-02-14 Thread Steven Rowe (Updated) (JIRA)


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

Steven Rowe updated LUCENE-3754:


Attachment: LUCENE-3754.patch

This version of the patch only provides per-artifact manifest files - these 
manifest files are always rebuilt, as is currently the case.  (I'd rather not 
make manifests the only part of the build that can get stale between {{ant 
clean}} invocations.)

The patch also contains a new macro {{solr-jarify}}, which provides 
Solr-specific default attributes, and then calls {{jarify}}, so that these 
values don't have to be specified everywhere in Solr build files - I noticed 
that one of the Solr {{jarify}} invocations was missing a Solr-specific value.

The manifest filename can now have more than one value in a module, though only 
the facet module uses this capability right now, to provide a different value 
in the manifest for the examples jar.

Unless there are objections, I will commit this tomorrow.

 Store generated archive manifests in per-module output directories
 --

 Key: LUCENE-3754
 URL: https://issues.apache.org/jira/browse/LUCENE-3754
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Steven Rowe
Assignee: Steven Rowe
Priority: Minor
 Attachments: LUCENE-3754.patch, LUCENE-3754.patch


 Currently, generated archive manifests are all stored in the same location, 
 so each module's build overwrites the previously built module's manifest.  
 Locating these files in the per-module build dirs will allow them to be 
 rebuilt only when necessary, rather than every time a module's {{jar}} target 
 is called.

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



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

[jira] [Commented] (LUCENE-3754) Store generated archive manifests in per-module output directories


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

Robert Muir commented on LUCENE-3754:
-

+1

 Store generated archive manifests in per-module output directories
 --

 Key: LUCENE-3754
 URL: https://issues.apache.org/jira/browse/LUCENE-3754
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Steven Rowe
Assignee: Steven Rowe
Priority: Minor
 Attachments: LUCENE-3754.patch, LUCENE-3754.patch


 Currently, generated archive manifests are all stored in the same location, 
 so each module's build overwrites the previously built module's manifest.  
 Locating these files in the per-module build dirs will allow them to be 
 rebuilt only when necessary, rather than every time a module's {{jar}} target 
 is called.

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



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

[jira] [Commented] (SOLR-3126) We should try to do a quick sync on std start up recovery before trying to do a full blown replication.


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

Mark Miller commented on SOLR-3126:
---

Whoops - was not building the leader url correctly - fixed. I'll commit this 
soon.

 We should try to do a quick sync on std start up recovery before trying to do 
 a full blown replication.
 ---

 Key: SOLR-3126
 URL: https://issues.apache.org/jira/browse/SOLR-3126
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-3126.patch


 just more efficient - especially on cluster shutdown/start where the replicas 
 may all be up to date and match anway.

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



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

[jira] [Commented] (SOLR-3088) create shard placeholders


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

Mark Miller commented on SOLR-3088:
---

You done here Sami? Should we resolve this one?

 create shard placeholders
 -

 Key: SOLR-3088
 URL: https://issues.apache.org/jira/browse/SOLR-3088
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud
Reporter: Yonik Seeley
 Fix For: 4.0

 Attachments: SOLR-3088.patch, SOLR-3088.patch


 When creating a new collection, a placeholder for each shard should be 
 created.

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



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

[jira] [Commented] (SOLR-3080) We should consider removing shard info from Zk when you explicitly unload a SolrCore.


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

Mark Miller commented on SOLR-3080:
---

Cool - I'll try and get to this today.

 We should consider removing shard info from Zk when you explicitly unload a 
 SolrCore.
 -

 Key: SOLR-3080
 URL: https://issues.apache.org/jira/browse/SOLR-3080
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.0

 Attachments: SOLR-3080.patch, SOLR-3080.patch




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



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

Re: [Lucene.Net] Blog Setup

2012-02-14 Thread Christopher Currens

Looks like the blog was successfully setup (that was quick!).  You can
access it here:  https://blogs.apache.org/lucenenet/

I've migrated the whopping 3 new entries we already have on our
index/front-page in the news section over to the blog.  I would give a shot
at integrating it into the website, but I actually have no idea how to edit
the website. :)


Thanks,
Christopher

On Mon, Feb 13, 2012 at 6:17 PM, Prescott Nasser geobmx...@hotmail.comwrote:


 I've submitted a ticket here:
 https://issues.apache.org/jira/browse/INFRA-4433 I only added my name, I
 wasn't sure who else would want access - if you do want it, submit a
 comment to that ticket with your apache username and full name.   I'm going
 to try and integrate this into the site soon. I also have some ideas about
 how to utilize the blog that I'll outline after I get it up and running ~P
   From: bode...@apache.org
  To: lucene-net-...@incubator.apache.org
  Date: Mon, 13 Feb 2012 13:39:11 +0100
  Subject: [Lucene.Net] Blog Setup
 
  Hi all,
 
  If we want a blog for Lucene.Net on blogs.apache.org, the instructions
  to request one are at
  https://cwiki.apache.org/confluence/display/INFRA/Resource+request+FAQs
 
  Mainly we should have a list of ASF ids of the initial set of admins and
  authors.
 
  I had a look at how the RSS snippets are added to www.apache.org's index
  page and it doesn't look to difficult to adapt.
 
  In
  
 https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/index.html
 
  there is
 
  {% for e in blog.list %}
  h4a href={{ e.url }}{{ e.title }}/a/h4
  div class=section-content{{ e.content|safe|truncatewords_html:50
 }}/div
  hr
  {% endfor %}
 
  which iterates over a blogs collection created in path.pm via
 
  [qr!^/index\.html$!, news_page =
{
  blog = ASF::Value::Blogs-new(blog = foundation, limit=
 3),
},
  ],
 
  and uses the ASF::Value::Blog package that is part of the CMS.
  
 https://svn.apache.org/repos/infra/websites/cms/build/lib/ASF/Value/Blogs.pm
 
 
  So getting content from the blog to the main page is pretty easy.  I
  think the main site is re-created every fifteen minutes to ensure things
  are fresh, not sure how one would go about this for a page that doesn't
  change that often (manually triggering buildbot might be an option).
  We'd need to ask this on the site-dev mailing list which is dedicated to
  the CMS.
 
  Stefan

[jira] [Resolved] (SOLR-3126) We should try to do a quick sync on std start up recovery before trying to do a full blown replication.

2012-02-14 Thread Mark Miller (Resolved) (JIRA)


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

Mark Miller resolved SOLR-3126.
---

Resolution: Fixed

Alright, this is in.

 We should try to do a quick sync on std start up recovery before trying to do 
 a full blown replication.
 ---

 Key: SOLR-3126
 URL: https://issues.apache.org/jira/browse/SOLR-3126
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-3126.patch


 just more efficient - especially on cluster shutdown/start where the replicas 
 may all be up to date and match anway.

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



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

Re: new Admin UI and license information

I didn't even know about rat; funny how the same things get reinvented
over and over again:

https://github.com/carrot2/carrot2/tree/master/lib/org.carrot2.antlib/src/main/java/org/carrot2/antlib/tasks

Dawid

On Tue, Feb 14, 2012 at 7:15 PM, Robert Muir rcm...@gmail.com wrote:
 We also have 'ant rat-sources' which works from within any module (yes
 Dawid, this one actually would be better top-level!)

 for it to work, just put apache-rat-0.8.jar in your ~/.ant/lib

 On Tue, Feb 14, 2012 at 12:58 PM, Erick Erickson
 erickerick...@gmail.com wrote:
 Hmmm, I just happened to notice this, I'm not really a license cop...

 But what the heck. Off the top of my head,
 html, js, jsp, vm and tpl are extensions that may make sense to look at.

 Erick

 On Tue, Feb 14, 2012 at 10:19 AM, Dawid Weiss
 dawid.we...@cs.put.poznan.pl wrote:
 By the way -- that license-check macro can work with any files, not
 only with *.jar files. It's basically a mapping from a fileset
 resources to other resource names. I can help in adding validation for
 *.js or whatever so that they are checked for licenses too.

 Dawid

 On Tue, Feb 14, 2012 at 3:07 PM, Erick Erickson erickerick...@gmail.com 
 wrote:
 While I was working on some of the LukeRequestHandler speedups, I
 noticed that there were no license notifications in the new Admin UI
 code, so I stuck some in and committed it (r: 1243925). Two questions:

 1 Is there any need for a JIRA here?
 2 ...solr/webapp/web/js/jquery.sparkline.js and a couple of others
 already had a license notification in them. I added in the Apache
 license information, should I have?

 Thanks,
 Erick

 P.S. I did a very quick triage to see that that I didn't use, say, the
 wrong comment form, but it was *very* quick. If functionality has
 disappeared mysteriously, here's where I'd look first.

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


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


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




 --
 lucidimagination.com

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


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

[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12422 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12422/

No tests ran.

Build Log (for compile errors):
[...truncated 8079 lines...]



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

[jira] [Reopened] (SOLR-3126) We should try to do a quick sync on std start up recovery before trying to do a full blown replication.

2012-02-14 Thread Mark Miller (Reopened) (JIRA)


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

Mark Miller reopened SOLR-3126:
---


Actually I should probably do one more thing here - wait to start sync until we 
are sure the leader sees as recovering.

 We should try to do a quick sync on std start up recovery before trying to do 
 a full blown replication.
 ---

 Key: SOLR-3126
 URL: https://issues.apache.org/jira/browse/SOLR-3126
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-3126.patch


 just more efficient - especially on cluster shutdown/start where the replicas 
 may all be up to date and match anway.

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



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

Welcome Christian Moen as committer

2012-02-14 Thread Robert Muir

I'm pleased to announce that Christian Moen has joined our ranks as a committer.

He has been contributing to our language capabilities, especially
filling the gap for the Japanese language.

Christian, its tradition that you introduce yourself with a brief bio.

I think your SVN access is already configured, so you should also be
able to add yourself to the committers list on the website as well.

Congratulations!

-- 
lucidimagination.com

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

RE: Welcome Christian Moen as committer

2012-02-14 Thread Steven A Rowe

Welcome Christian!

 -Original Message-
 From: Robert Muir [mailto:rcm...@gmail.com]
 Sent: Tuesday, February 14, 2012 4:48 PM
 To: dev@lucene.apache.org
 Subject: Welcome Christian Moen as committer

 I'm pleased to announce that Christian Moen has joined our ranks as a
 committer.

 He has been contributing to our language capabilities, especially
 filling the gap for the Japanese language.

 Christian, its tradition that you introduce yourself with a brief bio.

 I think your SVN access is already configured, so you should also be
 able to add yourself to the committers list on the website as well.

 Congratulations!

 --
 lucidimagination.com

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

Re: Welcome Christian Moen as committer

2012-02-14 Thread Yonik Seeley

Congrats Christian!

-Yonik
lucidimagination.com



On Tue, Feb 14, 2012 at 4:48 PM, Robert Muir rcm...@gmail.com wrote:
 I'm pleased to announce that Christian Moen has joined our ranks as a 
 committer.

 He has been contributing to our language capabilities, especially
 filling the gap for the Japanese language.

 Christian, its tradition that you introduce yourself with a brief bio.

 I think your SVN access is already configured, so you should also be
 able to add yourself to the committers list on the website as well.

 Congratulations!

 --
 lucidimagination.com

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


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

Re: Welcome Christian Moen as committer

2012-02-14 Thread Tommaso Teofili

Welcome Christian!
Tommaso

2012/2/14 Robert Muir rcm...@gmail.com

 I'm pleased to announce that Christian Moen has joined our ranks as a
 committer.

 He has been contributing to our language capabilities, especially
 filling the gap for the Japanese language.

 Christian, its tradition that you introduce yourself with a brief bio.

 I think your SVN access is already configured, so you should also be
 able to add yourself to the committers list on the website as well.

 Congratulations!

 --
 lucidimagination.com

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

[jira] [Assigned] (SOLR-2847) fix test bug in DistributedSpellCheckComponentTest

2012-02-14 Thread James Dyer (Assigned) (JIRA)


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

James Dyer reassigned SOLR-2847:


Assignee: James Dyer

 fix test bug in DistributedSpellCheckComponentTest
 --

 Key: SOLR-2847
 URL: https://issues.apache.org/jira/browse/SOLR-2847
 Project: Solr
  Issue Type: Bug
  Components: multicore, spellchecker
Affects Versions: 4.0
Reporter: James Dyer
Assignee: James Dyer
Priority: Trivial
 Fix For: 4.0

 Attachments: SOLR-2847.patch


 In Trunk, the IndexBasedSpellChecker dictionary is not being built both for 
 the control and shard indexes.  The test then compares nothing to nothing 
 and passes, because both the shard-index response and the control-index 
 responses are the same.  This issue fixes the problem with the dictionaries 
 not being built and also adds an additional check for data in the 
 control-index responses so that this sort of regression may be detected in 
 the future.

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



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

[jira] [Updated] (SOLR-2847) fix test bug in DistributedSpellCheckComponentTest

2012-02-14 Thread James Dyer (Updated) (JIRA)


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

James Dyer updated SOLR-2847:
-

Attachment: SOLR-2847.patch

updated patch fixes devious test bug.  With this patch, if the controlData 
doesn't return any spellcheck responses, the test fails.

Will commit soon  port to 3x.  Figure this is a good practice-commit for me.

 fix test bug in DistributedSpellCheckComponentTest
 --

 Key: SOLR-2847
 URL: https://issues.apache.org/jira/browse/SOLR-2847
 Project: Solr
  Issue Type: Bug
  Components: multicore, spellchecker
Affects Versions: 4.0
Reporter: James Dyer
Assignee: James Dyer
Priority: Trivial
 Fix For: 4.0

 Attachments: SOLR-2847.patch, SOLR-2847.patch


 In Trunk, the IndexBasedSpellChecker dictionary is not being built both for 
 the control and shard indexes.  The test then compares nothing to nothing 
 and passes, because both the shard-index response and the control-index 
 responses are the same.  This issue fixes the problem with the dictionaries 
 not being built and also adds an additional check for data in the 
 control-index responses so that this sort of regression may be detected in 
 the future.

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



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

Re: Welcome Christian Moen as committer

2012-02-14 Thread Erik Hatcher

Yay!!!   Welcome Christian.  A great asset to the Lucene community!

Erik

On Feb 14, 2012, at 16:48 , Robert Muir wrote:

 I'm pleased to announce that Christian Moen has joined our ranks as a 
 committer.
 
 He has been contributing to our language capabilities, especially
 filling the gap for the Japanese language.
 
 Christian, its tradition that you introduce yourself with a brief bio.
 
 I think your SVN access is already configured, so you should also be
 able to add yourself to the committers list on the website as well.
 
 Congratulations!
 
 -- 
 lucidimagination.com
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 


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

Re: Welcome Christian Moen as committer

2012-02-14 Thread Michael McCandless

Welcome Christian!

Mike McCandless

http://blog.mikemccandless.com

On Tue, Feb 14, 2012 at 4:48 PM, Robert Muir rcm...@gmail.com wrote:
 I'm pleased to announce that Christian Moen has joined our ranks as a 
 committer.

 He has been contributing to our language capabilities, especially
 filling the gap for the Japanese language.

 Christian, its tradition that you introduce yourself with a brief bio.

 I think your SVN access is already configured, so you should also be
 able to add yourself to the committers list on the website as well.

 Congratulations!

 --
 lucidimagination.com

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


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

[jira] [Updated] (SOLR-2847) fix test bug in DistributedSpellCheckComponentTest

2012-02-14 Thread James Dyer (Updated) (JIRA)


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

James Dyer updated SOLR-2847:
-

Affects Version/s: 3.5
Fix Version/s: 3.6

 fix test bug in DistributedSpellCheckComponentTest
 --

 Key: SOLR-2847
 URL: https://issues.apache.org/jira/browse/SOLR-2847
 Project: Solr
  Issue Type: Bug
  Components: multicore, spellchecker
Affects Versions: 3.5, 4.0
Reporter: James Dyer
Assignee: James Dyer
Priority: Trivial
 Fix For: 3.6, 4.0

 Attachments: SOLR-2847.patch, SOLR-2847.patch


 In Trunk, the IndexBasedSpellChecker dictionary is not being built both for 
 the control and shard indexes.  The test then compares nothing to nothing 
 and passes, because both the shard-index response and the control-index 
 responses are the same.  This issue fixes the problem with the dictionaries 
 not being built and also adds an additional check for data in the 
 control-index responses so that this sort of regression may be detected in 
 the future.

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



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

[jira] [Commented] (SOLR-3122) RecoveryStrat can not use interrupt due to the use of Channels.


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

Mark Miller commented on SOLR-3122:
---

Since we no longer interrupted, zk retry operations could retry for a long 
time, even if recovery was cancelled - so I've worked around this 
(SafeStopThread interface) and just committed a fix.

 RecoveryStrat can not use interrupt due to the use of Channels.
 ---

 Key: SOLR-3122
 URL: https://issues.apache.org/jira/browse/SOLR-3122
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.0


 along the lines of LUCENE-2239, we cannot use interrupt unfortunetly.

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



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

[jira] [Updated] (SOLR-3126) We should try to do a quick sync on std start up recovery before trying to do a full blown replication.

2012-02-14 Thread Mark Miller (Updated) (JIRA)


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

Mark Miller updated SOLR-3126:
--

Attachment: SOLR-3126.patch

path for this - I stop committing in the prep recovery cmd so that it can be 
used also in the sync case - in the replicate case, we do a prep recovery cmd 
then an explicit commit

 We should try to do a quick sync on std start up recovery before trying to do 
 a full blown replication.
 ---

 Key: SOLR-3126
 URL: https://issues.apache.org/jira/browse/SOLR-3126
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-3126.patch, SOLR-3126.patch


 just more efficient - especially on cluster shutdown/start where the replicas 
 may all be up to date and match anway.

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



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

[jira] [Commented] (LUCENE-3731) Create a analysis/uima module for UIMA based tokenizers/analyzers


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

Robert Muir commented on LUCENE-3731:
-

Thanks for factoring this out Tommaso.

 Create a analysis/uima module for UIMA based tokenizers/analyzers
 -

 Key: LUCENE-3731
 URL: https://issues.apache.org/jira/browse/LUCENE-3731
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/analysis
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3731.patch, LUCENE-3731_2.patch, 
 LUCENE-3731_3.patch, LUCENE-3731_4.patch


 As discussed in SOLR-3013 the UIMA Tokenizers/Analyzer should be refactored 
 out in a separate module (modules/analysis/uima) as they can be used in plain 
 Lucene. Then the solr/contrib/uima will contain only the related factories.

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



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

[jira] [Commented] (LUCENE-3731) Create a analysis/uima module for UIMA based tokenizers/analyzers

2012-02-14 Thread Tommaso Teofili (Commented) (JIRA)


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

Tommaso Teofili commented on LUCENE-3731:
-

committed on trunk in r1244236

 Create a analysis/uima module for UIMA based tokenizers/analyzers
 -

 Key: LUCENE-3731
 URL: https://issues.apache.org/jira/browse/LUCENE-3731
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/analysis
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3731.patch, LUCENE-3731_2.patch, 
 LUCENE-3731_3.patch, LUCENE-3731_4.patch


 As discussed in SOLR-3013 the UIMA Tokenizers/Analyzer should be refactored 
 out in a separate module (modules/analysis/uima) as they can be used in plain 
 Lucene. Then the solr/contrib/uima will contain only the related factories.

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



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

Re: Welcome Christian Moen as committer

2012-02-14 Thread Martijn v Groningen

Welcome Christian!

Martijn

On 14 February 2012 23:01, Michael McCandless luc...@mikemccandless.com wrote:
 Welcome Christian!

 Mike McCandless

 http://blog.mikemccandless.com

 On Tue, Feb 14, 2012 at 4:48 PM, Robert Muir rcm...@gmail.com wrote:
 I'm pleased to announce that Christian Moen has joined our ranks as a 
 committer.

 He has been contributing to our language capabilities, especially
 filling the gap for the Japanese language.

 Christian, its tradition that you introduce yourself with a brief bio.

 I think your SVN access is already configured, so you should also be
 able to add yourself to the committers list on the website as well.

 Congratulations!

 --
 lucidimagination.com

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


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




-- 
Met vriendelijke groet,

Martijn van Groningen

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

RE: Welcome Christian Moen as committer

2012-02-14 Thread Uwe Schindler

Hey welcome, great work with Kumoroji!

Uwe

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

 -Original Message-
 From: Robert Muir [mailto:rcm...@gmail.com]
 Sent: Tuesday, February 14, 2012 10:48 PM
 To: dev@lucene.apache.org
 Subject: Welcome Christian Moen as committer
 
 I'm pleased to announce that Christian Moen has joined our ranks as a
 committer.
 
 He has been contributing to our language capabilities, especially filling the 
 gap
 for the Japanese language.
 
 Christian, its tradition that you introduce yourself with a brief bio.
 
 I think your SVN access is already configured, so you should also be able to 
 add
 yourself to the committers list on the website as well.
 
 Congratulations!
 
 --
 lucidimagination.com
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
 commands, e-mail: dev-h...@lucene.apache.org


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

Re: Welcome Christian Moen as committer

Welcome Christian!
Dawid

On Tue, Feb 14, 2012 at 11:28 PM, Martijn v Groningen
martijn.v.gronin...@gmail.com wrote:
 Welcome Christian!

 Martijn

 On 14 February 2012 23:01, Michael McCandless luc...@mikemccandless.com 
 wrote:
 Welcome Christian!

 Mike McCandless

 http://blog.mikemccandless.com

 On Tue, Feb 14, 2012 at 4:48 PM, Robert Muir rcm...@gmail.com wrote:
 I'm pleased to announce that Christian Moen has joined our ranks as a 
 committer.

 He has been contributing to our language capabilities, especially
 filling the gap for the Japanese language.

 Christian, its tradition that you introduce yourself with a brief bio.

 I think your SVN access is already configured, so you should also be
 able to add yourself to the committers list on the website as well.

 Congratulations!

 --
 lucidimagination.com

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


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




 --
 Met vriendelijke groet,

 Martijn van Groningen

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


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

[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1735 - Still Failing