headers
Uwe Schindler | 10 Feb 11:13
Picon

RE: svn commit: r804418 - in /websites/production/lucene/content: core/index.html index.html solr/index.html

Can we somehow silence this?

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe <at> thetaphi.de

> -----Original Message-----
> From: buildbot <at> apache.org [mailto:buildbot <at> apache.org]
> Sent: Friday, February 10, 2012 10:15 AM
> To: commits <at> lucene.apache.org
> Subject: svn commit: r804418 - in /websites/production/lucene/content:
> core/index.html index.html solr/index.html
> 
> Author: buildbot
> Date: Fri Feb 10 09:15:11 2012
> New Revision: 804418
> 
> Log:
> Production update by buildbot
> 
> Modified:
>     websites/production/lucene/content/core/index.html
>     websites/production/lucene/content/index.html
>     websites/production/lucene/content/solr/index.html
> 
> Modified: websites/production/lucene/content/core/index.html
> ================================================================
> ==============
(Continue reading)

Permalink | Reply | 0 comments |
headers
Apache Jenkins Server | 10 Feb 10:58
Picon
Gravatar

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

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

1 tests failed.
REGRESSION:  org.apache.solr.client.solrj.embedded.SolrExampleJettyTest.testCommitWithinOnAdd

Error Message:
expected:<1> but was:<0>

Stack Trace:
junit.framework.AssertionFailedError: expected:<1> but was:<0>
	at org.apache.solr.client.solrj.SolrExampleTests.testCommitWithinOnAdd(SolrExampleTests.java:362)
	at org.apache.lucene.util.LuceneTestCase$2$1.evaluate(LuceneTestCase.java:432)
	at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:147)
	at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50)

Build Log (for compile errors):
[...truncated 16287 lines...]
Permalink | Reply | 0 comments |
headers
Sami Siren (Created) (JIRA | 10 Feb 10:53
Picon
Favicon

[jira] [Created] (LUCENE-3768) Typo in some of the .alg files: ForcMerge instead of ForceMerge

Typo in some of the .alg files: ForcMerge instead of ForceMerge
---------------------------------------------------------------

                 Key: LUCENE-3768
                 URL: https://issues.apache.org/jira/browse/LUCENE-3768
             Project: Lucene - Java
          Issue Type: Bug
          Components: modules/benchmark
    Affects Versions: 4.0
            Reporter: Sami Siren

Some of the alg files have a typo and have ForcMerge when they should have ForceMerge. This causes following
exception to display when those are used:

{code}
     [java] java.lang.Exception: Error: cannot understand algorithm!
     [java] 	at org.apache.lucene.benchmark.byTask.Benchmark.<init>(Benchmark.java:63)
     [java] 	at org.apache.lucene.benchmark.byTask.Benchmark.exec(Benchmark.java:109)
     [java] 	at org.apache.lucene.benchmark.byTask.Benchmark.main(Benchmark.java:84)
     [java] Caused by: java.lang.ClassNotFoundException: ForcMerge not found in packages [org.apache.lucene.benchmark.byTask.tasks]
     [java] 	at org.apache.lucene.benchmark.byTask.utils.Algorithm.taskClass(Algorithm.java:283)
     [java] 	at org.apache.lucene.benchmark.byTask.utils.Algorithm.<init>(Algorithm.java:73)
     [java] 	at org.apache.lucene.benchmark.byTask.Benchmark.<init>(Benchmark.java:61)
     [java] 	... 2 more
{code}
Caused by: java.lang.ClassNotFoundException: ForcMerge not found in packages [org.apache.lucene.benchmark.byTask.tasks]

--
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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sami Siren (Created) (JIRA | 10 Feb 09:23
Picon
Favicon

[jira] [Created] (SOLR-3118) We need a better error message when failing due to a slice that is part of collection is not available

We need a better error message when failing due to a slice that is part of collection is not available
------------------------------------------------------------------------------------------------------

                 Key: SOLR-3118
                 URL: https://issues.apache.org/jira/browse/SOLR-3118
             Project: Solr
          Issue Type: Improvement
          Components: SolrCloud
    Affects Versions: 4.0
            Reporter: Sami Siren
            Priority: Minor

When indexing to/searching from an incomplete collection (for example a slice does not have any shards
registered/available) a cruel error without a proper explanation is shown to the user. These errors are
from running example1.sh and creating a new collection with coreadminhandler:

Slices with no shards:
Indexing:
{code}
Error 500 No registered leader was found, collection:collection2 slice:shard4

java.lang.RuntimeException: No registered leader was found, collection:collection2 slice:shard4
	at org.apache.solr.common.cloud.ZkStateReader.getLeaderProps(ZkStateReader.java:408)
	at org.apache.solr.common.cloud.ZkStateReader.getLeaderProps(ZkStateReader.java:393)
	at org.apache.solr.update.processor.DistributedUpdateProcessor.setupRequest(DistributedUpdateProcessor.java:154)
	at org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:210)
	at org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:115)
	at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:135)
	at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:79)
	at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:59)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Apache Jenkins Server | 10 Feb 07:29
Picon
Gravatar

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

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

1 tests failed.
REGRESSION:  org.apache.solr.cloud.LeaderElectionIntegrationTest.testSimpleSliceLeaderElection

Error Message:
We didn't find a new leader! 7003 was shutdown, but it's still showing as the leader

Stack Trace:
junit.framework.AssertionFailedError: We didn't find a new leader! 7003 was shutdown, but it's still
showing as the leader
	at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
	at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
	at org.apache.solr.cloud.LeaderElectionIntegrationTest.testSimpleSliceLeaderElection(LeaderElectionIntegrationTest.java:171)
	at org.apache.lucene.util.LuceneTestCase$3$1.evaluate(LuceneTestCase.java:527)

Build Log (for compile errors):
[...truncated 10209 lines...]
Permalink | Reply | 0 comments |
headers
Michael McCandless (Created) (JIRA | 10 Feb 00:40
Picon
Favicon

[jira] [Created] (LUCENE-3767) Explore streaming Viterbi search in Kuromoji

Explore streaming Viterbi search in Kuromoji
--------------------------------------------

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

I've been playing with the idea of changing the Kuromoji viterbi
search to be 2 passes (intersect, backtrace) instead of 4 passes
(break into sentences, intersect, score, backtrace)... this is very
much a work in progress, so I'm just getting my current state up.
It's got tons of nocommits, doesn't properly handle the user dict nor
extended modes yet, etc.

One thing I'm playing with is to add a double backtrace for the long
compound tokens, ie, instead of penalizing these tokens so that
shorter tokens are picked, leave the scores unchanged but on backtrace
take that penalty and use it as a threshold for a 2nd best
segmentation...

--
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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Muir | 9 Feb 21:46
Picon
Gravatar

Re: svn commit: r1242514 [1/2] - in /lucene/dev/trunk/solr: ./ core/src/java/org/apache/solr/update/processor/ core/src/test-files/solr/conf/ core/src/test/org/apache/solr/update/processor/

Can we improve this? Both Min and MaxFieldValueUpdateProcessorFactory
show up as a compile error in eclipse, which is frustrating to people
who use those IDEs.

While it could be a bug in the eclipse compiler, this code is
definitely on shaky ground, I don't understand how a
ClassCastException is OK?!

   <at> Override
   <at> SuppressWarnings("unchecked")
  public Collection<Object> pickSubset(Collection<Object> values) {
    Collection<Object> result = values;
    try {
      result = Collections.singletonList
        (Collections.max((Collection)values));
    } catch (ClassCastException e) {
      /* NOOP */
    }
    return result;
  }


On Thu, Feb 9, 2012 at 3:41 PM,  <hossman <at> apache.org> wrote:
> Author: hossman
> Date: Thu Feb  9 20:41:21 2012
> New Revision: 1242514
>
> URL: http://svn.apache.org/viewvc?rev=1242514&view=rev
> Log:
> SOLR-2802: several new UpdateProcessorFactories for modifing fields of documents, along with base classes to make writing these types of classes easier for users
(Continue reading)

Permalink | Reply | 3 comments |
headers
Apache Jenkins Server | 9 Feb 19:07
Picon
Gravatar

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

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

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 7988 lines...]
Permalink | Reply | 1 comment |
headers
Erick Erickson | 9 Feb 18:42
Picon

Scale function inefficiency perhaps?

Mostly, I'm checking to see if I'm hallucinating or not before going forward....

ScaleFloatFunction.getValues iterates through all the values for a
field in all the documents to find the min and max for a particular
field it's using. So far, so good. But is this really necessary every
time it gets called? I don't think these numbers change if the index
hasn't changed, right? Couldn't the min and max just be cached the
first time around?

If one were to work up a patch (both 3.x and 4.x I think), I assume
that reader.getVersion() and min and max could be cached the first
time around and the list iterated only when the version changes...

The only fly I see in the ointment is that the values would have to be
shared amongst multiple threads, what's the preferred way to
synchronize such a thing? It's been a long time since I've been in
Java synchronization methods....
Permalink | Reply | 3 comments |
headers
Michael McCandless (Created) (JIRA | 9 Feb 17:31
Picon
Favicon

[jira] [Created] (LUCENE-3766) Remove/deprecate Tokenizer's default ctor

Remove/deprecate Tokenizer's default ctor
-----------------------------------------

                 Key: LUCENE-3766
                 URL: https://issues.apache.org/jira/browse/LUCENE-3766
             Project: Lucene - Java
          Issue Type: Improvement
            Reporter: Michael McCandless
             Fix For: 3.6, 4.0

I was working on a new Tokenizer... and I accidentally forgot to call super(input) (and
super.reset(input) from my reset method)... which then meant my correctOffset() calls were silently a
no-op; this is very trappy.

Fortunately the awesome BaseTokenStreamTestCase caught this (I hit failures because the offsets were
not in fact being corrected).

One minimal thing we can do (but it sounds like from Robert there may be reasons why we can't) is add {{assert
input != null}} in Tokenizer.correctOffset:

{noformat}
Index: lucene/core/src/java/org/apache/lucene/analysis/Tokenizer.java
===================================================================
--- lucene/core/src/java/org/apache/lucene/analysis/Tokenizer.java	(revision 1242316)
+++ lucene/core/src/java/org/apache/lucene/analysis/Tokenizer.java	(working copy)
@@ -82,6 +82,7 @@
    * @see CharStream#correctOffset
    */
   protected final int correctOffset(int currentOff) {
+    assert input != null: "subclass failed to call super(Reader) or super.reset(Reader)";
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jamie Johnson (Created) (JIRA | 9 Feb 17:07
Picon
Favicon

[jira] [Created] (SOLR-3117) CoreDescriptor attempts to use the name before checking if it is null

CoreDescriptor attempts to use the name before checking if it is null
---------------------------------------------------------------------

                 Key: SOLR-3117
                 URL: https://issues.apache.org/jira/browse/SOLR-3117
             Project: Solr
          Issue Type: Improvement
          Components: SolrCloud
    Affects Versions: 4.0
            Reporter: Jamie Johnson
            Priority: Minor

in CoreDescriptor when creating the cloudDesc the name is accessed before checking if it is null 

I believe it should be the following instead

{code}
  public CoreDescriptor(CoreContainer coreContainer, String name, String instanceDir) {
    this.coreContainer = coreContainer;
    this.name = name;

    if (name == null) {
        throw new RuntimeException("Core needs a name");
      }

    if(coreContainer != null && coreContainer.getZkController() != null) {
      this.cloudDesc = new CloudDescriptor();
      // cloud collection defaults to core name
      cloudDesc.setCollectionName(name.isEmpty() ? coreContainer.getDefaultCoreName() : name);
    }
(Continue reading)

Permalink | Reply | 2 comments |

Gmane