[jira] [Commented] (SOLR-3857) DIH: SqlEntityProcessor with "simple" cache broken

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-3857:


James,

Could you explain what can be actually cached in N+1 scenario (where 
xid=${x.id}) ? 

> DIH: SqlEntityProcessor with "simple" cache broken
> --
>
> Key: SOLR-3857
> URL: https://issues.apache.org/jira/browse/SOLR-3857
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 3.6.1, 4.0-BETA
>Reporter: James Dyer
>
> The wiki describes a usage of CachedSqlEntityProcessor like this:
> {code:xml}
>  processor="CachedSqlEntityProcessor">
> {code}
> This creates what the code refers as a "simple" cache.  Rather than build the 
> entire cache up-front, the cache is built on-the-go.  I think this has 
> limited use cases but it would be nice to preserve the feature if possible.
> Unfortunately this was not included in any (effective) unit tests, and 
> SOLR-2382 entirely broke the functionality for 3.6/4.0-alpha+ .  At a first 
> glance, the fix may not be entirely straightforward.
> This was found while writing tests for SOLR-3856.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: Build failed in Jenkins: Lucene-Core-4x-Beasting #8125

[Dawid Weiss]

Yup, something is odd. The "quit" event is the last one emitted from a
forked jvm and it should always be received.

It'd be great if you could capture the workspace (or just the
temporary build files -- **/*.events); I'm sure it's possible to keep
these as part of each build -- they're removed on successful
completion anyway so it'll affect failed builds only. Could you
configure this somehow?

Dawid

On Thu, Sep 20, 2012 at 2:09 AM, Robert Muir  wrote:
> this looks like a bug in the testrunner? all tests are actually done
> executing here.
>
> On Wed, Sep 19, 2012 at 8:02 PM,   wrote:
>> See 
>>
>> --
>> [...truncated 8788 lines...]
>> compile-test-framework:
>>
>> ivy-availability-check:
>>
>> ivy-fail:
>>
>> ivy-configure:
>> [ivy:configure] :: loading settings :: file = 
>> 
>>
>> resolve:
>>
>> init:
>>
>> compile-lucene-core:
>>
>> compile-codecs:
>>  [echo] Building codecs...
>>
>> ivy-availability-check:
>>
>> ivy-fail:
>>
>> ivy-configure:
>> [ivy:configure] :: loading settings :: file = 
>> 
>>
>> resolve:
>>
>> common.init:
>>
>> compile-lucene-core:
>>
>> init:
>>
>> -clover.disable:
>>
>> -clover.setup:
>>
>> clover:
>>
>> compile-core:
>>
>> compile-core:
>>
>> common.compile-test:
>>
>> install-junit4-taskdef:
>>
>> -clover.disable:
>>
>> -clover.setup:
>>
>> clover:
>>
>> validate:
>>
>> common.test:
>> [mkdir] Created dir: 
>> 
>> [junit4:junit4]  says olá! Master seed: 71BB57BBEF1760E0
>> [junit4:junit4] Executing 1 suite with 1 JVM.
>> [junit4:junit4]
>> [junit4:junit4] Suite: org.apache.lucene.index.memory.MemoryIndexTest
>> [junit4:junit4] Completed in 3.32s, 5 tests
>> [junit4:junit4]
>> [junit4:junit4] JVM J0: 0.31 .. 4.14 = 3.83s
>> [junit4:junit4] Execution time total: 4.14 sec.
>> [junit4:junit4] Tests summary: 1 suite, 5 tests
>>  [echo] 5 slowest tests:
>> [junit4:tophints]   3.32s | org.apache.lucene.index.memory.MemoryIndexTest
>>  [echo] Building misc...
>>
>> ivy-availability-check:
>>
>> ivy-fail:
>>
>> ivy-configure:
>> [ivy:configure] :: loading settings :: file = 
>> 
>>
>> resolve:
>>
>> common.init:
>>
>> compile-lucene-core:
>>
>> ivy-availability-check:
>>
>> ivy-fail:
>>
>> ivy-configure:
>> [ivy:configure] :: loading settings :: file = 
>> 
>>
>> resolve:
>>
>> init:
>>
>> -clover.disable:
>>
>> -clover.setup:
>>
>> clover:
>>
>> compile-core:
>>
>> init:
>>
>> test:
>>  [echo] Building misc...
>>
>> ivy-availability-check:
>>
>> ivy-fail:
>>
>> ivy-configure:
>> [ivy:configure] :: loading settings :: file = 
>> 
>>
>> resolve:
>>
>> common.init:
>>
>> compile-lucene-core:
>>
>> init:
>>
>> compile-test:
>>  [echo] Building misc...
>>
>> ivy-availability-check:
>>
>> ivy-fail:
>>
>> ivy-configure:
>> [ivy:configure] :: loading settings :: file = 
>> 
>>
>> resolve:
>>
>> common.init:
>>
>> compile-lucene-core:
>>
>> init:
>>
>> -clover.disable:
>>
>> -clover.setup:
>>
>> clover:
>>
>> compile-core:
>>
>> compile-test-framework:
>>
>> ivy-availability-check:
>>
>> ivy-fail:
>>
>> ivy-configure:
>> [ivy:configure] :: loading settings :: file = 
>> 
>>
>> resolve:
>>
>> init:
>>
>> compile-lucene-core:
>>
>> compile-codecs:
>>  [echo] Building codecs...
>>
>> ivy-availability-check:
>>
>> ivy-fail:
>>
>> ivy-configure:
>> [ivy:configure] :: loading settings :: file = 
>> 
>>
>> resolve:
>>
>> common.init:
>>
>> compile-lucene-core:
>>
>> init:
>>
>> -clover.disable:
>>
>> -clover.setup:
>>
>> clover:
>>
>> compile-core:
>>
>> compile-core:
>>
>> common.compile-test:
>>
>> install-junit4-taskdef:
>>
>> -clover.disable:
>>
>> -clover.setup:
>>
>> clover:
>>
>> validate:
>>
>> common.test:
>> [mkdir] Created dir: 
>> 
>> [junit4:junit4]  says Привет! Master seed: 618B11506A5D
>> [junit4:junit4] Executing 5 suites with 4 JVMs.
>> [junit4:junit4]
>> [junit4:junit4] Suite: org.apache.lucene.misc.SweetSpotSimilarityTest
>> [junit4:junit4] Completed on J3 in 0.44s, 3 tests
>> [junit4:junit4]
>> [junit4:junit4] Suite: org.apache.lucene.index.TestMultiPassIndexSplitter
>> [junit4:junit4] Completed on J3 in 1.

Jenkins build is back to normal : Lucene-Solr-Robocop #89

[hudsonseviltwin]

See 


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

Build failed in Jenkins: Lucene-Solr-Robocop #88

[hudsonseviltwin]

See 

--
[...truncated 15937 lines...]
download-java6-javadoc-packagelist:
   [delete] Deleting: 

  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package 
org.apache.lucene.sandbox.queries...
  [javadoc] Loading source files for package 
org.apache.lucene.sandbox.queries.regex...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.7.0_01
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 

  [javadoc] Note: Custom tags that were not seen:  @lucene.internal, 
@lucene.experimental
 [exec] Result: 1
  [jar] Building jar: 

 [echo] Building spatial...

check-queries-javadocs-uptodate:

javadocs-queries:

check-queries-uptodate:

jar-queries:

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 


resolve:

common.init:

compile-lucene-core:

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 


resolve:

init:

-clover.disable:

-clover.setup:

clover:

compile-core:

init:

-clover.disable:

-clover.setup:

clover:

common.compile-core:

compile-core:

javadocs:
[mkdir] Created dir: 

 [echo] Building spatial...

download-java6-javadoc-packagelist:
 [copy] Copying 1 file to 

  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene.spatial...
  [javadoc] Loading source files for package org.apache.lucene.spatial.prefix...
  [javadoc] Loading source files for package 
org.apache.lucene.spatial.prefix.tree...
  [javadoc] Loading source files for package org.apache.lucene.spatial.query...
  [javadoc] Loading source files for package org.apache.lucene.spatial.util...
  [javadoc] Loading source files for package org.apache.lucene.spatial.vector...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.7.0_01
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
 [exec] Result: 1
  [jar] Building jar: 

 [echo] Building suggest...

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 


resolve:

common.init:

compile-lucene-core:

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 


resolve:

init:

-clover.disable:

-clover.setup:

clover:

compile-core:

init:

-clover.disable:

-clover.setup:

clover:

compile-core:

check-lucene-core-javadocs-uptodate:

javadocs-lucene-core:

javadocs:
[mkdir] Created dir: 

 [echo] Building suggest...

download-java6-javadoc-packagelist:
 [copy] Copying 1 file to 

  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene.search.spell...
  [javadoc] Loading source files for package org.apache.lucene.search.suggest...
  [javadoc] Loading source files for package 
org.apache.lucene.search.suggest.fst...
  [javadoc] Loading source files for package 
org.apache.lucene.search.suggest.jaspell...
  [javadoc] Loading source files for package 
org.apache.lucene.search.suggest.tst...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.7.0_01
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
 [exec] Result: 1
  [jar] Building jar: 

[jira] [Updated] (SOLR-2255) local params are not parsed in facet.pivot parameter

[David Smiley (JIRA)]

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

David Smiley updated SOLR-2255:
---

Attachment: SOLR-2255_local-param_support_for_pivot_faceting.patch

This is a small update to the patch to update it for a recent change.  FYI this 
works on 4x too.

Any comments from the likes of Yonik, Hoss, Ryan, or Erik  (those involved in 
the underlying code)?

> local params are not parsed in facet.pivot parameter
> 
>
> Key: SOLR-2255
> URL: https://issues.apache.org/jira/browse/SOLR-2255
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 4.0-ALPHA
>Reporter: Julien Lirochon
>Assignee: David Smiley
> Attachments: SOLR-2255_local-param_support_for_pivot_faceting.patch, 
> SOLR-2255_local-param_support_for_pivot_faceting.patch
>
>
> ...&facet=true&facet.pivot={!ex=category}category_id,subcategory_id&fq={!tag=category}category_id=42
> generates the following error : "undefined field {!ex=category}category_id"
> If you filter on subcategory_id, the facet.pivot result will contain only 
> results from this subcategory. It's a loss of function since you can't alter 
> this behavior with local params.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4175) Include BBox Spatial Strategy

[Chris Male (JIRA)]

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

Chris Male commented on LUCENE-4175:


With the very near release of 4.0, I don't think we should backport anything 
untested.  I also don't think we're in any immediate hurry for this since we've 
got other options in 4.0.  But we should definitely work on the testing and 
push it for 4.1.

> Include BBox Spatial Strategy
> -
>
> Key: LUCENE-4175
> URL: https://issues.apache.org/jira/browse/LUCENE-4175
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: LUCENE-4175-bbox-strategy.patch
>
>
> This is an approach to indexing bounding boxes using 4 numeric fields 
> (xmin,ymin,xmax,ymax) and a flag to say if it crosses the dateline.
> This is a modification from the Apache 2.0 code from the ESRI Geoportal:
> http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-2008) SolrCore.close should shutdown updateHandler before searchExecutor

[Yandong Yao (JIRA)]

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

Yandong Yao commented on SOLR-2008:
---

Just compared solr-4.0-beta source code and diff at 
http://mail-archives.apache.org/mod_mbox/lucene-commits/201007.mbox/%3c20100720180640.535952388...@eris.apache.org%3E,

seems the fix in this patch are not in solr-4.0-beta. Please help to check, 
thanks!

> SolrCore.close should shutdown updateHandler before searchExecutor
> --
>
> Key: SOLR-2008
> URL: https://issues.apache.org/jira/browse/SOLR-2008
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.3, 1.4, 1.4.1
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 3.1, 4.0-ALPHA
>
>
> As noted on the mailing list...
> http://markmail.org/message/cvihm2m6aqhrfbo5
> a RejectedExecutionException can occur when shutting down a solr core if the 
> UpdateHandler.close() wants to do an autocommit - because the searchExecutor 
> has already been closed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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

[dev]improve the construct in the dev version?

[秋水]

Hello
my comprehending, the ideal construct should use many interfaces, getters and 
setters.

in the 3.6.1 version, there are many suspicious package construct, which must 
come around with MS dot Net background developer or other programming 
languages, accompanying much performance considering.

is there a good plan or vision on improving it?

[jira] [Commented] (LUCENE-4409) implement javadocs linting with eclipse ecj compiler

[Chris Male (JIRA)]

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

Chris Male commented on LUCENE-4409:


+1 That's pretty damn cool

> implement javadocs linting with eclipse ecj compiler
> 
>
> Key: LUCENE-4409
> URL: https://issues.apache.org/jira/browse/LUCENE-4409
> Project: Lucene - Core
>  Issue Type: Task
>  Components: general/build
>Reporter: Robert Muir
>
> today we have a lot of custom python scripts checking javadocs (checking for 
> missing stuff too).
> Most of this is implemented by parsing html etc (some of this should stay 
> this way, like broken-link detection)
> But actually the eclipse compiler can do most of this type of linting, and 
> has a lot of options for it. We can pull it via ivy and run it from the 
> command-line.
> I tested this manually by adding a bogus throws clause to Codec.java, 
> downloading the ecj.jar from maven and running it manually:
> {noformat}
> rmuir@beast:~/workspace/lucene-trunk/lucene/core/src/java$ java -cp 
> ~/Downloads/ecj-3.7.2.jar org.eclipse.jdt.internal.compiler.batch.Main 
> -source 1.6 -d none -enableJavadoc -properties 
> ~/workspace/lucene-trunk/dev-tools/eclipse/.settings/org.eclipse.jdt.core.prefs
>  .
> ...
> --
> 120. ERROR in 
> /home/rmuir/workspace/lucene-trunk/lucene/core/src/java/./org/apache/lucene/codecs/Codec.java
>  (at line 59)
>   * @throws IOException */
> ^^^
> Javadoc: Exception IOException is not declared
> --
> {noformat}
> here i specified -d none (don't generate class files), and essentially told 
> it to read the compiler warnings/errors options set in the dev-tools config. 
> For javadocs-lint we would want our own separate properties file that 
> disables the ordinary java warnings (because eclipse can warn/error/ignore on 
> lots of things, not just javadocs, and does by default).
> Separately we could also use this to check/fail/warn on other things besides 
> javadoc...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Assigned] (SOLR-3859) SolrCloud admin graph is showing leader as state recovery failed, but it's working

[Mark Miller (JIRA)]

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

Mark Miller reassigned SOLR-3859:
-

Assignee: Mark Miller

> SolrCloud admin graph is showing leader as state recovery failed, but it's 
> working
> --
>
> Key: SOLR-3859
> URL: https://issues.apache.org/jira/browse/SOLR-3859
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.0-BETA
> Environment: linux/centos
>Reporter: Jim Musil
>Assignee: Mark Miller
>
> I'm not sure this is truly a bug, but the behavior really confuses me.
> I have four servers running one of my cores. As a test, I took down the 
> leader to watch how leader election works. In this case, a leader was 
> selected, but it went into a state of "recovery failed". The odd thing is 
> that everything still works. I can query that box directly and I can query 
> the cluster and I observe correct behavior.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3859) SolrCloud admin graph is showing leader as state recovery failed, but it's working

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-3859:
---

Did you refresh the page? It does not auto refresh. I assume you did though.

There is an option to dump all the zk state to the clipboard - can you attach 
that dump here?

> SolrCloud admin graph is showing leader as state recovery failed, but it's 
> working
> --
>
> Key: SOLR-3859
> URL: https://issues.apache.org/jira/browse/SOLR-3859
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.0-BETA
> Environment: linux/centos
>Reporter: Jim Musil
>
> I'm not sure this is truly a bug, but the behavior really confuses me.
> I have four servers running one of my cores. As a test, I took down the 
> leader to watch how leader election works. In this case, a leader was 
> selected, but it went into a state of "recovery failed". The odd thing is 
> that everything still works. I can query that box directly and I can query 
> the cluster and I observe correct behavior.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4409) implement javadocs linting with eclipse ecj compiler

[Robert Muir (JIRA)]

Robert Muir created LUCENE-4409:
---

 Summary: implement javadocs linting with eclipse ecj compiler
 Key: LUCENE-4409
 URL: https://issues.apache.org/jira/browse/LUCENE-4409
 Project: Lucene - Core
  Issue Type: Task
  Components: general/build
Reporter: Robert Muir


today we have a lot of custom python scripts checking javadocs (checking for 
missing stuff too).

Most of this is implemented by parsing html etc (some of this should stay this 
way, like broken-link detection)

But actually the eclipse compiler can do most of this type of linting, and has 
a lot of options for it. We can pull it via ivy and run it from the 
command-line.

I tested this manually by adding a bogus throws clause to Codec.java, 
downloading the ecj.jar from maven and running it manually:

{noformat}
rmuir@beast:~/workspace/lucene-trunk/lucene/core/src/java$ java -cp 
~/Downloads/ecj-3.7.2.jar org.eclipse.jdt.internal.compiler.batch.Main -source 
1.6 -d none -enableJavadoc -properties 
~/workspace/lucene-trunk/dev-tools/eclipse/.settings/org.eclipse.jdt.core.prefs 
.
...
--
120. ERROR in 
/home/rmuir/workspace/lucene-trunk/lucene/core/src/java/./org/apache/lucene/codecs/Codec.java
 (at line 59)
* @throws IOException */
  ^^^
Javadoc: Exception IOException is not declared
--
{noformat}

here i specified -d none (don't generate class files), and essentially told it 
to read the compiler warnings/errors options set in the dev-tools config. For 
javadocs-lint we would want our own separate properties file that disables the 
ordinary java warnings (because eclipse can warn/error/ignore on lots of 
things, not just javadocs, and does by default).

Separately we could also use this to check/fail/warn on other things besides 
javadoc...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3747) Support Unicode 6.1.0

[Steven Rowe (JIRA)]

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

Steven Rowe resolved LUCENE-3747.
-

Resolution: Fixed

Committed:

- trunk [r1387813|https://svn.apache.org/viewvc?rev=1387813&view=rev]
- branch_4x [r1387837|https://svn.apache.org/viewvc?rev=1387837&view=rev]

> Support Unicode 6.1.0
> -
>
> Key: LUCENE-3747
> URL: https://issues.apache.org/jira/browse/LUCENE-3747
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 3.5, 4.0-ALPHA
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Minor
> Fix For: 5.0, 4.0-BETA
>
> Attachments: LUCENE-3747.patch, LUCENE-3747.patch, 
> LUCENE-3747-remainders.patch
>
>
> Now that Unicode 6.1.0 has been released, Lucene/Solr should support it.
> JFlex trunk now supports Unicode 6.1.0.
> Tasks include:
> * Upgrade ICU4J to v49 (after it's released, on 2012-03-21, according to 
> http://icu-project.org).
> * Use {{icu}} module tools to regenerate the supplementary character 
> additions to JFlex grammars.
> * Version the JFlex grammars: copy the current implementations to 
> {{*Impl3}}; cause the versioning tokenizer wrappers to instantiate this 
> version when the {{Version}} c-tor param is in the range 3.1 to the version 
> in which these changes are released (excluding the range endpoints); then 
> change the specified Unicode version in the non-versioned JFlex grammars from 
> 6.0 to 6.1.
> * Regenerate JFlex scanners, including {{StandardTokenizerImpl}}, 
> {{UAX29URLEmailTokenizerImpl}}, and {{HTMLStripCharFilter}}.
> * Using {{generateJavaUnicodeWordBreakTest.pl}}, generate and then run 
> {{WordBreakTestUnicode_6_1_0.java}}  under 
> {{modules/analysis/common/src/test/org/apache/lucene/analysis/core/}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3783) Facet pivots produces NPE when facet.missing is turned on

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-3783.


   Resolution: Fixed
Fix Version/s: 5.0
   4.0
 Assignee: Hoss Man

Committed revision 1387824.
Committed revision 1387825. - 4x


> Facet pivots produces NPE when facet.missing is turned on
> -
>
> Key: SOLR-3783
> URL: https://issues.apache.org/jira/browse/SOLR-3783
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Reporter: Tanguy Moal
>Assignee: Hoss Man
>Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: SOLR-3783.patch
>
>
> We get an http 500 as follow :
> {code:xml}
> 
>   java.lang.NullPointerException
>   500
> 
> {code}
> When facet.missing is turned on and combined with facet.pivot (if one of the 
> pivot-faceted fields have missing counts ^-^)
> Ideally, the decission tree could be computing for the missing "entries" 
> using the {noformat} -field:[* TO *] {noformat} query but it might be a 
> performance issue on a large index (I guess)
> The fallback to this could be to raise a 400 error with a clean message 
> telling that both parameters can't be combined and then the documentation 
> should be modified accordingly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3783) Facet pivots produces NPE when facet.missing is turned on

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-3783:
---

Attachment: SOLR-3783.patch

Thanks for reporting this Tanguy,

The NPE is definitely bad, a pretty clear oversight in the pivot facet code - 
fixing it doesn't seem to be that hard.

patch includes test updated tests (which also fixes what appeared to be a 
mistake in the test -- comment suggested it was checking data about the second 
pivot but it was still checking hte first)


> Facet pivots produces NPE when facet.missing is turned on
> -
>
> Key: SOLR-3783
> URL: https://issues.apache.org/jira/browse/SOLR-3783
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Reporter: Tanguy Moal
>Priority: Minor
> Attachments: SOLR-3783.patch
>
>
> We get an http 500 as follow :
> {code:xml}
> 
>   java.lang.NullPointerException
>   500
> 
> {code}
> When facet.missing is turned on and combined with facet.pivot (if one of the 
> pivot-faceted fields have missing counts ^-^)
> Ideally, the decission tree could be computing for the missing "entries" 
> using the {noformat} -field:[* TO *] {noformat} query but it might be a 
> performance issue on a large index (I guess)
> The fallback to this could be to raise a 400 error with a clean message 
> telling that both parameters can't be combined and then the documentation 
> should be modified accordingly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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 build is back to normal : Lucene-Core-4x-Beasting #8126

[hudsonseviltwin]

See 


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

Re: Build failed in Jenkins: Lucene-Core-4x-Beasting #8125

[Robert Muir]

this looks like a bug in the testrunner? all tests are actually done
executing here.

On Wed, Sep 19, 2012 at 8:02 PM,   wrote:
> See 
>
> --
> [...truncated 8788 lines...]
> compile-test-framework:
>
> ivy-availability-check:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> 
>
> resolve:
>
> init:
>
> compile-lucene-core:
>
> compile-codecs:
>  [echo] Building codecs...
>
> ivy-availability-check:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> 
>
> resolve:
>
> common.init:
>
> compile-lucene-core:
>
> init:
>
> -clover.disable:
>
> -clover.setup:
>
> clover:
>
> compile-core:
>
> compile-core:
>
> common.compile-test:
>
> install-junit4-taskdef:
>
> -clover.disable:
>
> -clover.setup:
>
> clover:
>
> validate:
>
> common.test:
> [mkdir] Created dir: 
> 
> [junit4:junit4]  says olá! Master seed: 71BB57BBEF1760E0
> [junit4:junit4] Executing 1 suite with 1 JVM.
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.index.memory.MemoryIndexTest
> [junit4:junit4] Completed in 3.32s, 5 tests
> [junit4:junit4]
> [junit4:junit4] JVM J0: 0.31 .. 4.14 = 3.83s
> [junit4:junit4] Execution time total: 4.14 sec.
> [junit4:junit4] Tests summary: 1 suite, 5 tests
>  [echo] 5 slowest tests:
> [junit4:tophints]   3.32s | org.apache.lucene.index.memory.MemoryIndexTest
>  [echo] Building misc...
>
> ivy-availability-check:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> 
>
> resolve:
>
> common.init:
>
> compile-lucene-core:
>
> ivy-availability-check:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> 
>
> resolve:
>
> init:
>
> -clover.disable:
>
> -clover.setup:
>
> clover:
>
> compile-core:
>
> init:
>
> test:
>  [echo] Building misc...
>
> ivy-availability-check:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> 
>
> resolve:
>
> common.init:
>
> compile-lucene-core:
>
> init:
>
> compile-test:
>  [echo] Building misc...
>
> ivy-availability-check:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> 
>
> resolve:
>
> common.init:
>
> compile-lucene-core:
>
> init:
>
> -clover.disable:
>
> -clover.setup:
>
> clover:
>
> compile-core:
>
> compile-test-framework:
>
> ivy-availability-check:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> 
>
> resolve:
>
> init:
>
> compile-lucene-core:
>
> compile-codecs:
>  [echo] Building codecs...
>
> ivy-availability-check:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> 
>
> resolve:
>
> common.init:
>
> compile-lucene-core:
>
> init:
>
> -clover.disable:
>
> -clover.setup:
>
> clover:
>
> compile-core:
>
> compile-core:
>
> common.compile-test:
>
> install-junit4-taskdef:
>
> -clover.disable:
>
> -clover.setup:
>
> clover:
>
> validate:
>
> common.test:
> [mkdir] Created dir: 
> 
> [junit4:junit4]  says Привет! Master seed: 618B11506A5D
> [junit4:junit4] Executing 5 suites with 4 JVMs.
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.misc.SweetSpotSimilarityTest
> [junit4:junit4] Completed on J3 in 0.44s, 3 tests
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.index.TestMultiPassIndexSplitter
> [junit4:junit4] Completed on J3 in 1.32s, 2 tests
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.misc.TestHighFreqTerms
> [junit4:junit4] Completed on J2 in 1.69s, 11 tests
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.index.TestPKIndexSplitter
> [junit4:junit4] Completed on J1 in 1.70s, 1 test
> [junit4:junit4]
> [junit4:junit4] Suite: org.apache.lucene.index.TestIndexSplitter
> [junit4:junit4] Completed on J0 in 8.24s, 1 test
> [junit4:junit4]
> [junit4:junit4] JVM J0: 0.84 .. 9.61 = 8.77s
> [junit4:junit4] JVM J1: 1.08 .. 5.99 = 4.91s
> [junit4:junit4] JVM J2: 1.08 .. 3.04 = 1.96s
> [junit4:junit4] JVM J3: 0.84 .. 3.03 = 2.19s
> [junit4:junit

Build failed in Jenkins: Lucene-Core-4x-Beasting #8125

[hudsonseviltwin]

See 

--
[...truncated 8788 lines...]
compile-test-framework:

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 


resolve:

init:

compile-lucene-core:

compile-codecs:
 [echo] Building codecs...

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 


resolve:

common.init:

compile-lucene-core:

init:

-clover.disable:

-clover.setup:

clover:

compile-core:

compile-core:

common.compile-test:

install-junit4-taskdef:

-clover.disable:

-clover.setup:

clover:

validate:

common.test:
[mkdir] Created dir: 

[junit4:junit4]  says olá! Master seed: 71BB57BBEF1760E0
[junit4:junit4] Executing 1 suite with 1 JVM.
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.memory.MemoryIndexTest
[junit4:junit4] Completed in 3.32s, 5 tests
[junit4:junit4] 
[junit4:junit4] JVM J0: 0.31 .. 4.14 = 3.83s
[junit4:junit4] Execution time total: 4.14 sec.
[junit4:junit4] Tests summary: 1 suite, 5 tests
 [echo] 5 slowest tests:
[junit4:tophints]   3.32s | org.apache.lucene.index.memory.MemoryIndexTest
 [echo] Building misc...

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 


resolve:

common.init:

compile-lucene-core:

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 


resolve:

init:

-clover.disable:

-clover.setup:

clover:

compile-core:

init:

test:
 [echo] Building misc...

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 


resolve:

common.init:

compile-lucene-core:

init:

compile-test:
 [echo] Building misc...

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 


resolve:

common.init:

compile-lucene-core:

init:

-clover.disable:

-clover.setup:

clover:

compile-core:

compile-test-framework:

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 


resolve:

init:

compile-lucene-core:

compile-codecs:
 [echo] Building codecs...

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 


resolve:

common.init:

compile-lucene-core:

init:

-clover.disable:

-clover.setup:

clover:

compile-core:

compile-core:

common.compile-test:

install-junit4-taskdef:

-clover.disable:

-clover.setup:

clover:

validate:

common.test:
[mkdir] Created dir: 

[junit4:junit4]  says Привет! Master seed: 618B11506A5D
[junit4:junit4] Executing 5 suites with 4 JVMs.
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.misc.SweetSpotSimilarityTest
[junit4:junit4] Completed on J3 in 0.44s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestMultiPassIndexSplitter
[junit4:junit4] Completed on J3 in 1.32s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.misc.TestHighFreqTerms
[junit4:junit4] Completed on J2 in 1.69s, 11 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestPKIndexSplitter
[junit4:junit4] Completed on J1 in 1.70s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestIndexSplitter
[junit4:junit4] Completed on J0 in 8.24s, 1 test
[junit4:junit4] 
[junit4:junit4] JVM J0: 0.84 .. 9.61 = 8.77s
[junit4:junit4] JVM J1: 1.08 .. 5.99 = 4.91s
[junit4:junit4] JVM J2: 1.08 .. 3.04 = 1.96s
[junit4:junit4] JVM J3: 0.84 .. 3.03 = 2.19s
[junit4:junit4] Execution time total: 9.61 sec.
[junit4:junit4] ERROR: JVM J1 ended with an exception, command line: 
/usr/local/jdk1.7.0_01/jre/bin/java -Dtests.prefix=tests 
-Dtests.seed=618B11506A5D -Xmx512M -Dtests.iters= -Dtests.verbose=false 
-Dtests.infostream=false 
-Dtests.lockdir=
 -Dtests.codec=random -Dtests.postingsformat=random -Dtests.locale=random 
-Dtests.timezone=random -Dtests.directory=random 
-Dtests.linedocsfile=europarl.line

[jira] [Updated] (LUCENE-3747) Support Unicode 6.1.0

[Steven Rowe (JIRA)]

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

Steven Rowe updated LUCENE-3747:


Attachment: LUCENE-3747-remainders.patch

{{HTMLStripCharFilter.jflex}} needed to be upgraded ({{%unicode 6.0}} -> 
{{%unicode 6.1}}) and regenerated, but the rest is just documentation, though 
this patch does include all regenerated .java files.

Committing shortly.

> Support Unicode 6.1.0
> -
>
> Key: LUCENE-3747
> URL: https://issues.apache.org/jira/browse/LUCENE-3747
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 3.5, 4.0-ALPHA
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Minor
> Fix For: 4.0-BETA, 5.0
>
> Attachments: LUCENE-3747.patch, LUCENE-3747.patch, 
> LUCENE-3747-remainders.patch
>
>
> Now that Unicode 6.1.0 has been released, Lucene/Solr should support it.
> JFlex trunk now supports Unicode 6.1.0.
> Tasks include:
> * Upgrade ICU4J to v49 (after it's released, on 2012-03-21, according to 
> http://icu-project.org).
> * Use {{icu}} module tools to regenerate the supplementary character 
> additions to JFlex grammars.
> * Version the JFlex grammars: copy the current implementations to 
> {{*Impl3}}; cause the versioning tokenizer wrappers to instantiate this 
> version when the {{Version}} c-tor param is in the range 3.1 to the version 
> in which these changes are released (excluding the range endpoints); then 
> change the specified Unicode version in the non-versioned JFlex grammars from 
> 6.0 to 6.1.
> * Regenerate JFlex scanners, including {{StandardTokenizerImpl}}, 
> {{UAX29URLEmailTokenizerImpl}}, and {{HTMLStripCharFilter}}.
> * Using {{generateJavaUnicodeWordBreakTest.pl}}, generate and then run 
> {{WordBreakTestUnicode_6_1_0.java}}  under 
> {{modules/analysis/common/src/test/org/apache/lucene/analysis/core/}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Reopened] (LUCENE-3747) Support Unicode 6.1.0

[Steven Rowe (JIRA)]

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

Steven Rowe reopened LUCENE-3747:
-


I missed a couple of Unicode 6.0 mentions.  Patch in a moment.

> Support Unicode 6.1.0
> -
>
> Key: LUCENE-3747
> URL: https://issues.apache.org/jira/browse/LUCENE-3747
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 3.5, 4.0-ALPHA
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Minor
> Fix For: 4.0-BETA, 5.0
>
> Attachments: LUCENE-3747.patch, LUCENE-3747.patch
>
>
> Now that Unicode 6.1.0 has been released, Lucene/Solr should support it.
> JFlex trunk now supports Unicode 6.1.0.
> Tasks include:
> * Upgrade ICU4J to v49 (after it's released, on 2012-03-21, according to 
> http://icu-project.org).
> * Use {{icu}} module tools to regenerate the supplementary character 
> additions to JFlex grammars.
> * Version the JFlex grammars: copy the current implementations to 
> {{*Impl3}}; cause the versioning tokenizer wrappers to instantiate this 
> version when the {{Version}} c-tor param is in the range 3.1 to the version 
> in which these changes are released (excluding the range endpoints); then 
> change the specified Unicode version in the non-versioned JFlex grammars from 
> 6.0 to 6.1.
> * Regenerate JFlex scanners, including {{StandardTokenizerImpl}}, 
> {{UAX29URLEmailTokenizerImpl}}, and {{HTMLStripCharFilter}}.
> * Using {{generateJavaUnicodeWordBreakTest.pl}}, generate and then run 
> {{WordBreakTestUnicode_6_1_0.java}}  under 
> {{modules/analysis/common/src/test/org/apache/lucene/analysis/core/}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (SOLR-3859) SolrCloud admin graph is showing leader as state recovery failed, but it's working

[Jim Musil (JIRA)]

Jim Musil created SOLR-3859:
---

 Summary: SolrCloud admin graph is showing leader as state recovery 
failed, but it's working
 Key: SOLR-3859
 URL: https://issues.apache.org/jira/browse/SOLR-3859
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-BETA
 Environment: linux/centos
Reporter: Jim Musil


I'm not sure this is truly a bug, but the behavior really confuses me.

I have four servers running one of my cores. As a test, I took down the leader 
to watch how leader election works. In this case, a leader was selected, but it 
went into a state of "recovery failed". The odd thing is that everything still 
works. I can query that box directly and I can query the cluster and I observe 
correct behavior.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (SOLR-3858) Doc-to-shard assignment based on "range" property on shards

[Yonik Seeley (JIRA)]

Yonik Seeley created SOLR-3858:
--

 Summary: Doc-to-shard assignment based on "range" property on 
shards
 Key: SOLR-3858
 URL: https://issues.apache.org/jira/browse/SOLR-3858
 Project: Solr
  Issue Type: Sub-task
Reporter: Yonik Seeley


Anything that maps a document id to a shard should consult the ranges defined 
on the shards (currently indexing and real-time get).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3087) XInclude not working on schema.xml

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-3087.


   Resolution: Fixed
Fix Version/s: 5.0

Committed revision 1387778.
Committed revision 1387784. - 4x


> XInclude not working on schema.xml
> --
>
> Key: SOLR-3087
> URL: https://issues.apache.org/jira/browse/SOLR-3087
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 3.5
>Reporter: Romain MERESSE
>Assignee: Hoss Man
>  Labels: XInclude, schema.xml
> Fix For: 4.0, 5.0
>
> Attachments: SOLR-3087.patch, SOLR-3087.patch
>
>
> I want to use XML XInclude mechanism (http://en.wikipedia.org/wiki/XInclude) 
> to include parts of schema.xml.
> When I try to include a fieldType, I get this exception :
> java.lang.RuntimeException: schema fieldtype 
> string2(org.apache.solr.schema.StrField) invalid 
> arguments:{xml:base=solrres:/schema_integration.xml}
>   at org.apache.solr.schema.FieldType.setArgs(FieldType.java:168)
>   at org.apache.solr.schema.IndexSchema$1.init(IndexSchema.java:467)
>   at org.apache.solr.schema.IndexSchema$1.init(IndexSchema.java:435)
>   at 
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:175)
>   at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:480)
>   at org.apache.solr.schema.IndexSchema.(IndexSchema.java:125)
>   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)
>   at 
> org.mortbay.jetty.win32service.JettyServiceWrapperListener.start(JettyServiceWrapperListener.java:47)
>   at 
> org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788)
> I include 'schema_integration.xml' like this :
> schema.xml ->
> 
> 
>   
>  
>   xmlns:xi="http://www.w3.org/2001/XInclude"/>
>   
>   
> 
> schema_integration.xml ->
> 
>  omitNorms="true"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3087) XInclude not working on schema.xml

[Amit Nithian (JIRA)]

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

Amit Nithian commented on SOLR-3087:


Perfect that makes sense! I didn't go that generic but hey that's what 
collaboration is for :-)

> XInclude not working on schema.xml
> --
>
> Key: SOLR-3087
> URL: https://issues.apache.org/jira/browse/SOLR-3087
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 3.5
>Reporter: Romain MERESSE
>Assignee: Hoss Man
>  Labels: XInclude, schema.xml
> Fix For: 4.0
>
> Attachments: SOLR-3087.patch, SOLR-3087.patch
>
>
> I want to use XML XInclude mechanism (http://en.wikipedia.org/wiki/XInclude) 
> to include parts of schema.xml.
> When I try to include a fieldType, I get this exception :
> java.lang.RuntimeException: schema fieldtype 
> string2(org.apache.solr.schema.StrField) invalid 
> arguments:{xml:base=solrres:/schema_integration.xml}
>   at org.apache.solr.schema.FieldType.setArgs(FieldType.java:168)
>   at org.apache.solr.schema.IndexSchema$1.init(IndexSchema.java:467)
>   at org.apache.solr.schema.IndexSchema$1.init(IndexSchema.java:435)
>   at 
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:175)
>   at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:480)
>   at org.apache.solr.schema.IndexSchema.(IndexSchema.java:125)
>   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)
>   at 
> org.mortbay.jetty.win32service.JettyServiceWrapperListener.start(JettyServiceWrapperListener.java:47)
>   at 
> org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788)
> I include 'schema_integration.xml' like this :
> schema.xml ->
> 
> 
>   
>  
>   xmlns:xi="http://www.w3.org/2001/XInclude"/>
>   
>   
> 
> schema_integration.xml ->
> 
>  omitNorms="true"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: SpanNearQuery distance issue

[vempap]

Shoot me. Thanks, I did not notice that the doc has ".. e a .." in the
content. Thanks again :) 



--
View this message in context: 
http://lucene.472066.n3.nabble.com/SpanNearQuery-distance-issue-tp4008974p4009034.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

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

[jira] [Updated] (SOLR-3087) XInclude not working on schema.xml

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-3087:
---

Attachment: SOLR-3087.patch

Romain: thanks for reporting this!

Amit: thanks for your patch with a fix! .. your changed definitely addresses 
the specific bug reported, but i'm worried that it really only deals with the 
specific case of fieldType and it might leave other holes where code validates 
(or may be updated to valide in the future) that only expected attributes are 
used.

So I've updated the patch to modify DOMUtil to ignore anything using the 
reserved xml namespace prefix.  patch also improves on the existing 
TestXIncludeConfig to demonstrate this bug and that the fix is working.

> XInclude not working on schema.xml
> --
>
> Key: SOLR-3087
> URL: https://issues.apache.org/jira/browse/SOLR-3087
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 3.5
>Reporter: Romain MERESSE
>Assignee: Hoss Man
>  Labels: XInclude, schema.xml
> Fix For: 4.0
>
> Attachments: SOLR-3087.patch, SOLR-3087.patch
>
>
> I want to use XML XInclude mechanism (http://en.wikipedia.org/wiki/XInclude) 
> to include parts of schema.xml.
> When I try to include a fieldType, I get this exception :
> java.lang.RuntimeException: schema fieldtype 
> string2(org.apache.solr.schema.StrField) invalid 
> arguments:{xml:base=solrres:/schema_integration.xml}
>   at org.apache.solr.schema.FieldType.setArgs(FieldType.java:168)
>   at org.apache.solr.schema.IndexSchema$1.init(IndexSchema.java:467)
>   at org.apache.solr.schema.IndexSchema$1.init(IndexSchema.java:435)
>   at 
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:175)
>   at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:480)
>   at org.apache.solr.schema.IndexSchema.(IndexSchema.java:125)
>   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)
>   at 
> org.mortbay.jetty.win32service.JettyServiceWrapperListener.start(JettyServiceWrapperListener.java:47)
>   at 
> org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788)
> I include 'schema_integration.xml' like this :
> schema.xml ->
> 
> 
>   
>  
>   xmlns:xi="http://www.w3.org/2001/XInclude"/>
>   
>   
> 
> schema_integration.xml ->
> 
>  omitNorms="true"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please

[jira] [Commented] (SOLR-3815) add hash range to shard

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-3815:


Committed fix to preserve shard properties:
trunk: http://svn.apache.org/viewvc?rev=1387747&view=rev
4x: http://svn.apache.org/viewvc?rev=1387749&view=rev

> add hash range to shard
> ---
>
> Key: SOLR-3815
> URL: https://issues.apache.org/jira/browse/SOLR-3815
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Yonik Seeley
> Attachments: SOLR-3815_addrange.patch, 
> SOLR-3815_clusterState_immutable.patch, SOLR-3815.patch
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4404) Add ListOfOutputs FST Outputs, replacing UpToTwoPositiveIntOutputs

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-4404:
---

Attachment: LUCENE-4404.patch

New patch, I think it's ready.

I resurrected UpToTwoPositiveInts, in lucene/misc, and moved ListOfOutputs 
there too.  And I refactored the reusable parts of TestFSTs into 
test-framework, and created TestFSTsMisc to test these two output impls.

> Add ListOfOutputs FST Outputs, replacing UpToTwoPositiveIntOutputs
> --
>
> Key: LUCENE-4404
> URL: https://issues.apache.org/jira/browse/LUCENE-4404
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: LUCENE-4404.patch, LUCENE-4404.patch
>
>
> Spinoff from LUCENE-3842.  This just generalizes the
> UpToTwoPositiveIntOutputs to a list of any arbitrary output, by
> wrapping any other Outputs impl.  I also made separate methods to
> write/read a node-final output: since list of values can only occur on
> a final node output, this impl optimizes and avoids writing an extra
> byte per label for normal arc labels.
> This also fixes a bug in Builder that was sometimes failing to join
> multiple outputs together.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-1597) New Document and Field API

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-1597.


Resolution: Duplicate

I think it's more or less dup'd w/ LUCENE-2308 ... we can open new issues for 
any differences.

> New Document and Field API
> --
>
> Key: LUCENE-1597
> URL: https://issues.apache.org/jira/browse/LUCENE-1597
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/index
>Reporter: Michael Busch
>Assignee: Michael Busch
>Priority: Minor
> Fix For: 4.1
>
> Attachments: lucene-new-doc-api.patch
>
>
> This is a super rough prototype of how a new document API could look like. 
> It's basically what I came up with during a long flight across the Atlantic :)
> It is not integrated with anything yet (like IndexWriter, DocumentsWriter, 
> etc.) and heavily uses Java 1.5 features, such as generics and annotations.
> The general idea sounds similar to what Marvin is doing in KS, which I found 
> out by reading Mike's comments on LUCENE-831, I haven't looked at the KS API 
> myself yet. 
> Main ideas:
> - separate a field's value from its configuration; therefore this patch 
> introduces two classes: FieldDescriptor and FieldValue
> - I was thinking that in most cases the documents people add to a Lucene 
> index look alike, i.e. they contain mostly the same fields with the same 
> settings. Yet, for every field instance the DocumentsWriter checks the 
> settings and calls the right consumers, which themselves check settings and 
> return true or false, indicating whether or not they want to do something 
> with that field or not. So I was thinking we could design the document API 
> similar to the Class<->Object concept of OO-languages. There a class is a 
> blueprint (as everyone knows :) ), and an object is one instance of it. So in 
> this patch I introduced a class called DocumentDescriptor, which contains all 
> FieldDescriptors with the field settings. This descriptor is given to the 
> consumer (IndexWriter) once in the constructor. Then the Document "instances" 
> are created and added via addDocument().
> - A Document instance allows adding "variable fields" in addition to the 
> "fixed fields" the DocumentDescriptor contains. For these fields the 
> consumers have to check the field settings for every document instance (like 
> with the old document API). This is for maintaining Lucene's flexibility that 
> everyone loves.
> - Disregard the changes to AttributeSource for now. The code that's worth 
> looking at is contained in a new package "newdoc".
> Again, this is not a "real" patch, but rather a demo of how a new API could 
> roughly work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-1689) supplementary character handling

[Steven Rowe (JIRA)]

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

Steven Rowe commented on LUCENE-1689:
-

Robert, is there anything left to do here?  I think this issue can be resolved 
as fixed.

> supplementary character handling
> 
>
> Key: LUCENE-1689
> URL: https://issues.apache.org/jira/browse/LUCENE-1689
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Robert Muir
>Priority: Minor
> Fix For: 4.1
>
> Attachments: LUCENE-1689_lowercase_example.txt, LUCENE-1689.patch, 
> LUCENE-1689.patch, LUCENE-1689.patch, testCurrentBehavior.txt
>
>
> for Java 5. Java 5 is based on unicode 4, which means variable-width encoding.
> supplementary character support should be fixed for code that works with 
> char/char[]
> For example:
> StandardAnalyzer, SimpleAnalyzer, StopAnalyzer, etc should at least be 
> changed so they don't actually remove suppl characters, or modified to look 
> for surrogates and behave correctly.
> LowercaseFilter should be modified to lowercase suppl. characters correctly.
> CharTokenizer should either be deprecated or changed so that isTokenChar() 
> and normalize() use int.
> in all of these cases code should remain optimized for the BMP case, and 
> suppl characters should be the exception, but still work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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

unable to build v.3.6.1-2 on ubuntu 12.04; ICU issue?

[RKBelew]

after realizing what an old version of pylucene (2.3.1 !) is
available as a .deb, i am trying to build my own.  the make goes
well thru building the spellchecker:

>   [jar] Building jar: 
/Data/pkg/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build/core/lucene-core-3.6.1.jar
>   [jar] Building jar: 
/Data/pkg/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build/contrib/analyzers/common/lucene-analyzers-3.6.1.jar
>   [jar] Building jar: 
/Data/pkg/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build/contrib/queryparser/lucene-queryparser-3.6.1.jar
>   [jar] Building jar: 
/Data/pkg/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build/contrib/memory/lucene-memory-3.6.1.jar
>   [jar] Building jar: 
/Data/pkg/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build/contrib/queries/lucene-queries-3.6.1.jar
>   [jar] Building jar: 
/Data/pkg/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build/contrib/highlighter/lucene-highlighter-3.6.1.jar
>   [jar] Building jar: 
/Data/pkg/pylucene-3.6.1-2/build/jar/extensions.jar
>   [jar] Building jar: 
/Data/pkg/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build/contrib/grouping/lucene-grouping-3.6.1.jar
>   [jar] Building jar: 
/Data/pkg/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build/contrib/join/lucene-join-3.6.1.jar
>   [jar] Building jar: 
/Data/pkg/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build/contrib/facet/lucene-facet-3.6.1.jar
>   [jar] Building jar: 
/Data/pkg/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build/contrib/facet/lucene-facet-3.6.1-examples.jar
>   [jar] Building jar: 
/Data/pkg/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build/contrib/spellchecker/lucene-spellchecker-3.6.1.jar

>
> BUILD SUCCESSFUL
> Total time: 4 seconds

but then i get the ICU echo: and then it dies:

> ICU not installed
> /usr/bin/python -m jcc
>   --shared
>   --jar lucene-java-3.6.1/lucene/build/core/lucene-core-3.6.1.jar
>   --jar 
lucene-java-3.6.1/lucene/build/contrib/analyzers/common/lucene-analyzers-3.6.1.jar
>   --jar 
lucene-java-3.6.1/lucene/build/contrib/memory/lucene-memory-3.6.1.jar
>   --jar 
lucene-java-3.6.1/lucene/build/contrib/highlighter/lucene-highlighter-3.6.1.jar

>   --jar build/jar/extensions.jar
>   --jar 
lucene-java-3.6.1/lucene/build/contrib/queries/lucene-queries-3.6.1.jar
>   --jar 
lucene-java-3.6.1/lucene/build/contrib/grouping/lucene-grouping-3.6.1.jar
>   --jar 
lucene-java-3.6.1/lucene/build/contrib/join/lucene-join-3.6.1.jar
>   --jar 
lucene-java-3.6.1/lucene/build/contrib/facet/lucene-facet-3.6.1.jar
>   --jar 
lucene-java-3.6.1/lucene/build/contrib/spellchecker/lucene-spellchecker-3.6.1.jar
>   --package java.lang java.lang.System java.lang.Runtime 
java.lang.IllegalStateException java.lang.IndexOutOfBoundsException
>   --package java.util java.util.Arrays java.util.HashMap 
java.util.HashSet java.util.NoSuchElementException 
java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator

>   --package java.util.regex
>   --package java.io java.io.StringReader 
java.io.InputStreamReader java.io.FileInputStream

>   --exclude org.apache.lucene.queryParser.Token
>   --exclude org.apache.lucene.queryParser.TokenMgrError
>   --exclude org.apache.lucene.queryParser.QueryParserTokenManager
>   --exclude org.apache.lucene.queryParser.ParseException
>   --exclude org.apache.lucene.queryParser.CharStream
>   --exclude org.apache.lucene.search.regex.JakartaRegexpCapabilities
>   --exclude org.apache.regexp.RegexpTunnel
>   --exclude org.apache.lucene.analysis.cn.smart.AnalyzerProfile
>   --python lucene
>   --mapping org.apache.lucene.document.Document 
'get:(Ljava/lang/String;)Ljava/lang/String;'
>   --mapping java.util.Properties 
'getProperty:(Ljava/lang/String;)Ljava/lang/String;'
>   --sequence java.util.AbstractList 'size:()I' 
'get:(I)Ljava/lang/Object;'
>   --rename 
org.apache.lucene.search.highlight.SpanScorer=HighlighterSpanScorer
>   --rename 
org.apache.lucene.search.highlight.Scorer=HighlighterScorer

>   --rename org.apache.lucene.search.spell.Dictionary=SpellDictionary
>   --rename org.apache.lucene.search.suggest.fst.Sort=SuggestSort
>   --rename org.apache.lucene.store.DataInput=StoreDataInput
>   --rename org.apache.lucene.store.DataOutput=StoreDataOutput
>   --rename org.tartarus.snowball.ext.DutchStemmer=DutchPorterStemmer
>   --rename 
org.tartarus.snowball.ext.FrenchStemmer=FrenchPorterStemmer
>   --rename 
org.tartarus.snowball.ext.GermanStemmer=GermanPorterStemmer
>   --rename 
org.tartarus.snowball.ext.PortugueseStemmer=PortuguesePorterStemmer

>   --version 3.6.1
>   --module python/collections.py
>   --module python/ICUNormalizer2Filter.py
>   --module python/ICUFoldingFilter.py
>   --module python/ICUTransformFilter.py
>   --files 4
>   --build
> While loading 
org/apache/pylucene/queryParser/PythonMultiFieldQuery

[jira] [Commented] (LUCENE-1597) New Document and Field API

[Steven Rowe (JIRA)]

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

Steven Rowe commented on LUCENE-1597:
-

Can this be resolved (maybe as duplicate?), since {{o.a.l.document.FieldType}} 
was introduced by LUCENE-2308?

Or maybe there are other not-already-implemented ideas here that could be 
refactored to work with the current status quo?  (I didn't study the patch.)

> New Document and Field API
> --
>
> Key: LUCENE-1597
> URL: https://issues.apache.org/jira/browse/LUCENE-1597
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/index
>Reporter: Michael Busch
>Assignee: Michael Busch
>Priority: Minor
> Fix For: 4.1
>
> Attachments: lucene-new-doc-api.patch
>
>
> This is a super rough prototype of how a new document API could look like. 
> It's basically what I came up with during a long flight across the Atlantic :)
> It is not integrated with anything yet (like IndexWriter, DocumentsWriter, 
> etc.) and heavily uses Java 1.5 features, such as generics and annotations.
> The general idea sounds similar to what Marvin is doing in KS, which I found 
> out by reading Mike's comments on LUCENE-831, I haven't looked at the KS API 
> myself yet. 
> Main ideas:
> - separate a field's value from its configuration; therefore this patch 
> introduces two classes: FieldDescriptor and FieldValue
> - I was thinking that in most cases the documents people add to a Lucene 
> index look alike, i.e. they contain mostly the same fields with the same 
> settings. Yet, for every field instance the DocumentsWriter checks the 
> settings and calls the right consumers, which themselves check settings and 
> return true or false, indicating whether or not they want to do something 
> with that field or not. So I was thinking we could design the document API 
> similar to the Class<->Object concept of OO-languages. There a class is a 
> blueprint (as everyone knows :) ), and an object is one instance of it. So in 
> this patch I introduced a class called DocumentDescriptor, which contains all 
> FieldDescriptors with the field settings. This descriptor is given to the 
> consumer (IndexWriter) once in the constructor. Then the Document "instances" 
> are created and added via addDocument().
> - A Document instance allows adding "variable fields" in addition to the 
> "fixed fields" the DocumentDescriptor contains. For these fields the 
> consumers have to check the field settings for every document instance (like 
> with the old document API). This is for maintaining Lucene's flexibility that 
> everyone loves.
> - Disregard the changes to AttributeSource for now. The code that's worth 
> looking at is contained in a new package "newdoc".
> Again, this is not a "real" patch, but rather a demo of how a new API could 
> roughly work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Comment Edited] (LUCENE-1560) maxDocBytesToAnalyze should be required arg up front

[Steven Rowe (JIRA)]

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

Steven Rowe edited comment on LUCENE-1560 at 9/20/12 6:03 AM:
--

I think this issue is still valid?

The nabble.com email thread link in the description is broken - here's the 
markmail.org thread: [http://markmail.org/thread/2pcdjsurrrqoxuew].

{{maxDocBytesToAnalyze()}} was deprecated as part of LUCENE-1132 in favor of 
{{maxDocCharsToAnalyze()}}, and then removed with the 3.0 release deprecation 
removals as part of LUCENE-2022.

There is one commented-out vestige that ought to be renamed or removed (my vote 
is removal - this was commented out six years ago):

{code:java|title=Highlighter.java}
265: //   if(lastEndOffset>maxDocBytesToAnalyze)
266: //   {
267: // break;
268: //   }
{code}


  was (Author: steve_rowe):
I think this issue is still valid?

The nabble.com email thread link in the description is broken - here's the 
markmail.org thread: [http://markmail.org/thread/2pcdjsurrrqoxuew].

{{maxDocBytesToAnalyze()}} was deprecated as part of LUCENE-1132 in favor of 
{{maxDocCharsToAnalyze()}}, and then removed with the 3.0 release deprecation 
removals as part of LUCENE-2022.

There is one commented-out vestige that ought to be renamed or removed (my vote 
is removal - this was commented out six years ago):

{code:java}
265: //   if(lastEndOffset>maxDocBytesToAnalyze)
266: //   {
267: // break;
268: //   }
{code}

  
> maxDocBytesToAnalyze should be required arg up front
> 
>
> Key: LUCENE-1560
> URL: https://issues.apache.org/jira/browse/LUCENE-1560
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 2.4.1
>Reporter: Michael McCandless
> Fix For: 4.1
>
>
> We recently changed IndexWriter to require you to specify up-front
> MaxFieldLength, on creation, so that you are aware of this dangerous
> "loses stuff" setting.  Too many developers had fallen into the trap
> of "how come my search can't find this document...".
> I think we should do the same with "maxDocBytesToAnalyze" with
> highlighter?
> Spinoff from this thread:
> 
> http://www.nabble.com/Lucene-Highlighting-and-Dynamic-Summaries-p22385887.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-1560) maxDocBytesToAnalyze should be required arg up front

[Steven Rowe (JIRA)]

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

Steven Rowe commented on LUCENE-1560:
-

I think this issue is still valid?

The nabble.com email thread link in the description is broken - here's the 
markmail.org thread: [http://markmail.org/thread/2pcdjsurrrqoxuew].

{{maxDocBytesToAnalyze()}} was deprecated as part of LUCENE-1132 in favor of 
{{maxDocCharsToAnalyze()}}, and then removed with the 3.0 release deprecation 
removals as part of LUCENE-2022.

There is one commented-out vestige that ought to be renamed or removed (my vote 
is removal - this was commented out six years ago):

{code:java}
265: //   if(lastEndOffset>maxDocBytesToAnalyze)
266: //   {
267: // break;
268: //   }
{code}


> maxDocBytesToAnalyze should be required arg up front
> 
>
> Key: LUCENE-1560
> URL: https://issues.apache.org/jira/browse/LUCENE-1560
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 2.4.1
>Reporter: Michael McCandless
> Fix For: 4.1
>
>
> We recently changed IndexWriter to require you to specify up-front
> MaxFieldLength, on creation, so that you are aware of this dangerous
> "loses stuff" setting.  Too many developers had fallen into the trap
> of "how come my search can't find this document...".
> I think we should do the same with "maxDocBytesToAnalyze" with
> highlighter?
> Spinoff from this thread:
> 
> http://www.nabble.com/Lucene-Highlighting-and-Dynamic-Summaries-p22385887.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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

SpanNearQuery distance issue

[vempap]

Hello All,

I've a issue with respect to the distance measure of SpanNearQuery in
Lucene. Let's say I've following two documents:

DocID: 6, cotent:"1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 1001
1002 1003 1004 1005 1006 1007 1008 1009 1100", 
DocID: 7, content:"a b c d e a b c f g h i j k l m l k j z z z"

If my span query is :
a) "3n(a,e)" - It matches doc 7
But, if it is:
b) "3n(1,5)" - It does not match doc 6
If query is:
c) "4n(1,5)" - it matches doc 6

I have no clue why a) works rather not b). I tried to debug the code, but
couldn't figure it out.

Any help ?



--
View this message in context: 
http://lucene.472066.n3.nabble.com/SpanNearQuery-distance-issue-tp4008974.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

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

[jira] [Resolved] (SOLR-3850) DIH: parameter "cacheKey" was inadvertently renamed "cachePk"

[James Dyer (JIRA)]

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

James Dyer resolved SOLR-3850.
--

Resolution: Fixed

committed.

Trunk: r1387681
4x: r1387683
3x: r1387694

Also updated the wiki documenting this alternate syntax with a warning about 
the parameter name being wrong in 3.6, 3.6.1, 4.0-alpha & 4.0-beta.

> DIH:  parameter "cacheKey" was inadvertently renamed "cachePk"
> --
>
> Key: SOLR-3850
> URL: https://issues.apache.org/jira/browse/SOLR-3850
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 3.6.1, 4.0-BETA
>Reporter: James Dyer
>Assignee: James Dyer
> Fix For: 4.0, 3.6.2
>
> Attachments: SOLR-3850.patch, SOLR-3850.patch
>
>
> CachedSqlEntityProcessor supports an obscure alternate to the "where" 
> parameter.  Instead of  , users can use  ... cacheKey="id" cacheLookup="x.id" />  However, this was broken with 
> SOLR-2382.  "cacheKey" was accidently renamed "cachePk".  For the sake of 
> those who might be using this undocumented syntax and want to upgrade, I 
> think it should be put back to "cacheKey".  Also, I will add documentation in 
> the wiki.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-1307) Remove Contributions page

[Steven Rowe (JIRA)]

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

Steven Rowe resolved LUCENE-1307.
-

   Resolution: Fixed
Fix Version/s: (was: 4.1)
   4.0-ALPHA
Lucene Fields:   (was: New)

The Contributions page appears to have been removed in the 4.0.0-ALPHA site 
documentation cleanup.

> Remove Contributions page
> -
>
> Key: LUCENE-1307
> URL: https://issues.apache.org/jira/browse/LUCENE-1307
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/website
>Reporter: Otis Gospodnetic
>Priority: Minor
> Fix For: 4.0-ALPHA
>
>
> > On Fri, May 16, 2008 at 10:06 PM, Otis Gospodnetic
> >  wrote:
> >> Hola,
> >>
> >> Does anyone think the Contributions page should be removed?
> >> http://lucene.apache.org/java/2_3_2/contributions.html
> >>
> >> It looks so outdated that I think it may give newcomers a bad  
> >> impression of Lucene ("What, this is it for contributions?").
> >> The only really valuable piece there is Luke, but Luke must be  
> >> mentioned in a dozen places on the Wiki anyway.
> >>
> >>
> >> Should we remove the Contributions page?
> Yonik and Grant gave their +1s.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-1167) add compatibility statement to README.txt for all contribs

[Steven Rowe (JIRA)]

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

Steven Rowe commented on LUCENE-1167:
-

Can we close this now that there are no more Lucene contribs?

I couldn't find any back-compat assertions among the current set of modules in 
trunk and branch_4x.

> add compatibility statement to README.txt for all contribs
> --
>
> Key: LUCENE-1167
> URL: https://issues.apache.org/jira/browse/LUCENE-1167
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/other
>Reporter: Hoss Man
> Fix For: 4.1
>
>
> as discussed on the mailing list, all contribs are not created equally, and 
> we should including the comments about the backwards compatibility of each 
> contrib in the README.txt before the next release
> http://www.nabble.com/Back-Compatibility-to14918202.html#a14918202

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: jar error while trying to build

[Andi Vajda]

On Sep 19, 2012, at 8:20, Mohamed Lrhazi  wrote:

> to make sure, I just re-unpacked the tarball and rerun:
> 
> ml623@cab2b:~/tmp/pylucene-3.6.1-2/ > ANT=/opt/ant/bin/ant make

Did you follow the instructions at the top of the Makefile ?

Andi..

> 
> and got the same error.
> 
> Any idea what could be causing this?
> 
> Thanks a lot,
> Mohamed.
> 
> On Tue, Sep 18, 2012 at 6:39 PM, Andi Vajda  wrote:
>> 
>> On Tue, 18 Sep 2012, Mohamed Lrhazi wrote:
>> 
>>> Hello,
>>> 
>>> I am trying to build pylucene on a redhat ent 6.1. the make fails with
>>> an error pasted bellow.
>>> 
>>> Any hints appreciated.
>> 
>> 
>> Your Makefile seems to be broken in a way that --jar somewhere became just
>> jar and it's downhill from there.
>>   jar lucene-java-3.6.1/lucene/build/core/lucene-core-3.6.1.jar --jar
>> 
>> Andi..
>> 
>> 
>>> 
>>> Thanks a lot,
>>> Mohamed.
>>> 
>>> 
>>> cd lucene-java-3.6.1/lucene; (/opt/ant/bin/ant ivy-fail ||
>>> /opt/ant/bin/ant ivy-bootstrap)
>>> Buildfile: /home/ml623/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build.xml
>>> 
>>> ivy-fail:
>>> 
>>> BUILD SUCCESSFUL
>>> Total time: 0 seconds
>>> ICU not installed
>>> jar lucene-java-3.6.1/lucene/build/core/lucene-core-3.6.1.jar --jar
>>> 
>>> lucene-java-3.6.1/lucene/build/contrib/analyzers/common/lucene-analyzers-3.6.1.jar
>>> --jar
>>> lucene-java-3.6.1/lucene/build/contrib/memory/lucene-memory-3.6.1.jar
>>> --jar
>>> lucene-java-3.6.1/lucene/build/contrib/highlighter/lucene-highlighter
>>> -3.6.1.jar --jar build/jar/extensions.jar --jar
>>> lucene-java-3.6.1/lucene/build/contrib/queries/lucene-queries-3.6.1.jar
>>> --jar lucene-java-3.6.1/lucene/
>>> build/contrib/grouping/lucene-grouping-3.6.1.jar --jar
>>> lucene-java-3.6.1/lucene/build/contrib/join/lucene-join-3.6.1.jar
>>> --jar lucene-java-3.6.1/lucene
>>> /build/contrib/facet/lucene-facet-3.6.1.jar --jar
>>> 
>>> lucene-java-3.6.1/lucene/build/contrib/spellchecker/lucene-spellchecker-3.6.1.jar
>>> --package java.lan
>>> g java.lang.System java.lang.Runtime java.lang.IllegalStateException
>>> java.lang.IndexOutOfBoundsException --package java.util
>>> java.util.Arrays java.util
>>> .HashMap java.util.HashSet java.util.NoSuchElementException
>>> java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator
>>> --package java.util.regex --package java.io java.io.StringReader
>>> java.io.InputStreamReader java.io.FileInputStream --exclude
>>> org.apache.lucene.queryParser.Token --exclude
>>> org.apache.lucene.queryParser.TokenMgrError --exclude
>>> org.apache.lucene.queryParser.QueryParserTokenManager --exclude
>>> org.apache.lucene.queryParser.ParseException --exclude
>>> org.apache.lucene.queryParser.CharStream --exclude
>>> org.apache.lucene.search.regex.JakartaRegexpCapabilities --exclude
>>> org.apache.regexp.RegexpTunnel --exclude
>>> org.apache.lucene.analysis.cn.smart.AnalyzerProfile --python lucene
>>> --mapping org.apache.lucene.document.Document
>>> 'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping
>>> java.util.Properties
>>> 'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --sequence
>>> java.util.AbstractList 'size:()I' 'get:(I)Ljava/lang/Object;' --rename
>>> org.apache.lucene.search.highlight.SpanScorer=HighlighterSpanScorer
>>> --rename org.apache.lucene.search.highlight.Scorer=HighlighterScorer
>>> --rename org.apache.lucene.search.spell.Dictionary=SpellDictionary
>>> --rename org.apache.lucene.search.suggest.fst.Sort=SuggestSort
>>> --rename org.apache.lucene.store.DataInput=StoreDataInput --rename
>>> org.apache.lucene.store.DataOutput=StoreDataOutput --rename
>>> org.tartarus.snowball.ext.DutchStemmer=DutchPorterStemmer --rename
>>> org.tartarus.snowball.ext.FrenchStemmer=FrenchPorterStemmer --rename
>>> org.tartarus.snowball.ext.GermanStemmer=GermanPorterStemmer --rename
>>> org.tartarus.snowball.ext.PortugueseStemmer=PortuguesePorterStemmer
>>> --version 3.6.1 --module python/collections.py --module
>>> python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py
>>> --module python/ICUTransformFilter.py  --files  --build
>>> Illegal option: l
>>> Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] [entry-point]
>>> [-C dir] files ...
>>> Options:
>>>   -c  create new archive
>>>   -t  list table of contents for archive
>>> ...
>>> 
>> 

Re: Typo in Javadoc for Solr CopyField.getMaxChars: tha -> the

[Adrien Grand]

Hi Jack,

On Tue, Sep 18, 2012 at 10:43 PM, Jack Krupansky
 wrote:
> /**
> * @return tha maximum number of chars in source field to copy to destination
> field.
> */
> public int getMaxChars() {
>
> "tha" s.b. "the".

I just committed a fix, thanks for reporting this typo.

-- 
Adrien

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

[jira] [Resolved] (LUCENE-4398) "Memory Leak" in TermsHashPerField memory tracking

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-4398.


   Resolution: Fixed
Fix Version/s: 3.6.2

Thanks Tim!

> "Memory Leak" in TermsHashPerField memory tracking
> --
>
> Key: LUCENE-4398
> URL: https://issues.apache.org/jira/browse/LUCENE-4398
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 3.4
>Reporter: Tim Smith
>Assignee: Michael McCandless
> Fix For: 3.6.2
>
> Attachments: LUCENE-4398.patch
>
>
> I am witnessing an apparent leak in the memory tracking used to determine 
> when a flush is necessary.
> Over time, this will result in every single document being flushed into its 
> own segment as the memUsage will remain above the configured buffer size, 
> causing a flush to be triggered after every add/update.
> Best I can figure, this is being caused by TermsHashPerField's tracking of 
> memory usage for postingsHash and/or postingsArray combined with 
> multi-threaded feeding.
> I suspect that the TermsHashPerField's postingsHash is growing in one thread, 
> then, when a segment is flushed, a single, different thread will merge all 
> TermsHashPerFields in FreqProxTermsWriter and then call shrinkHash(). I 
> suspect this call of shrinkHash() is seeing an old postingsHash array, and 
> subsequently not releasing all the memory that was allocated.
> If this is the case, I am also concerned that FreqProxTermsWriter will not 
> write the correct terms into the index, although I have not confirmed that 
> any indexing problem occurs as of yet.
> NOTE: i am witnessing this growth in a test by subtracting the amount or 
> memory allocated (but in a "free" state) by 
> perDocAllocator/byteBlockAllocator/charBlocks/intBlocks from 
> DocumentsWriter.memUsage.get() in IndexWriter.doAfterFlush()
> I will see this stay at a stable point for a while, then on some flushes, i 
> will see this grow by a couple of bytes, and all subsequent flushes will 
> never go back down the the previous state
> I will continue to investigate and post any additional findings

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3852) Admin UI - Cloud Tree with HTTP-Status 500 and an ArrayIndexOutOfBoundsException when using external ZK

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-3852:
---

Woah - i got pinged in email because you mentioned my name - never saw that 
before. Cool.

Yeah, I can take a look.

> Admin UI - Cloud Tree with HTTP-Status 500 and an 
> ArrayIndexOutOfBoundsException when using external ZK
> ---
>
> Key: SOLR-3852
> URL: https://issues.apache.org/jira/browse/SOLR-3852
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0-BETA
> Environment: Tomcat 6, external zookeeper-3.3.5 
>Reporter: Vadim Kisselmann
>
> It works with embedded ZK.
> But when we use an external ZK(3.3.5), and this ZK has another nodes like 
> (hbase, broker, etc. and child-nodes with not specified formats) we get this 
> Error in Admin UI in the "Cloud-Tree" View: Loading of undefined failed with 
> HTTP-Status 500 .
> Important(!): The cluster still works. Our external ZK see the Solr Servers 
> (live-nodes) and has the solr config files from initial import. All the nodes 
> like collections, configs, overseer-elect are here.
> Only the Admin UI has a problem to show the "Cloud-Tree". Cloud-Graph works!
> Catalina-LogFiles are free from Error messages, i have only this stack trace 
> from Firebug:
> Apache Tomcat/6.0.28 - Error report 
> HTTP Status 500 -  noshade="noshade">type Exception reportmessage 
> description The server encountered an internal error 
> () that prevented it from fulfilling this request.exception 
> java.lang.ArrayIndexOutOfBoundsException
> note The full stack trace of the root cause is 
> available in the Apache Tomcat/6.0.28 logs. noshade="noshade">Apache Tomcat/6.0.28

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3850) DIH: parameter "cacheKey" was inadvertently renamed "cachePk"

[James Dyer (JIRA)]

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

James Dyer updated SOLR-3850:
-

Attachment: SOLR-3850.patch

This patch also fixes 2 tests that depended on the incorrect parameter name.

> DIH:  parameter "cacheKey" was inadvertently renamed "cachePk"
> --
>
> Key: SOLR-3850
> URL: https://issues.apache.org/jira/browse/SOLR-3850
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 3.6.1, 4.0-BETA
>Reporter: James Dyer
>Assignee: James Dyer
> Fix For: 4.0, 3.6.2
>
> Attachments: SOLR-3850.patch, SOLR-3850.patch
>
>
> CachedSqlEntityProcessor supports an obscure alternate to the "where" 
> parameter.  Instead of  , users can use  ... cacheKey="id" cacheLookup="x.id" />  However, this was broken with 
> SOLR-2382.  "cacheKey" was accidently renamed "cachePk".  For the sake of 
> those who might be using this undocumented syntax and want to upgrade, I 
> think it should be put back to "cacheKey".  Also, I will add documentation in 
> the wiki.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3852) Admin UI - Cloud Tree with HTTP-Status 500 and an ArrayIndexOutOfBoundsException when using external ZK

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) commented on SOLR-3852:
-

[~markrmil...@gmail.com] would you mind having a look here? With the given 
response the UI is not able to display that Tree, that's pretty sure .. but no 
idea what causes the ArrayIndexOutOfBounds?

> Admin UI - Cloud Tree with HTTP-Status 500 and an 
> ArrayIndexOutOfBoundsException when using external ZK
> ---
>
> Key: SOLR-3852
> URL: https://issues.apache.org/jira/browse/SOLR-3852
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.0-BETA
> Environment: Tomcat 6, external zookeeper-3.3.5 
>Reporter: Vadim Kisselmann
>
> It works with embedded ZK.
> But when we use an external ZK(3.3.5), and this ZK has another nodes like 
> (hbase, broker, etc. and child-nodes with not specified formats) we get this 
> Error in Admin UI in the "Cloud-Tree" View: Loading of undefined failed with 
> HTTP-Status 500 .
> Important(!): The cluster still works. Our external ZK see the Solr Servers 
> (live-nodes) and has the solr config files from initial import. All the nodes 
> like collections, configs, overseer-elect are here.
> Only the Admin UI has a problem to show the "Cloud-Tree". Cloud-Graph works!
> Catalina-LogFiles are free from Error messages, i have only this stack trace 
> from Firebug:
> Apache Tomcat/6.0.28 - Error report 
> HTTP Status 500 -  noshade="noshade">type Exception reportmessage 
> description The server encountered an internal error 
> () that prevented it from fulfilling this request.exception 
> java.lang.ArrayIndexOutOfBoundsException
> note The full stack trace of the root cause is 
> available in the Apache Tomcat/6.0.28 logs. noshade="noshade">Apache Tomcat/6.0.28

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (SOLR-3857) DIH: SqlEntityProcessor with "simple" cache broken

[James Dyer (JIRA)]

James Dyer created SOLR-3857:


 Summary: DIH: SqlEntityProcessor with "simple" cache broken
 Key: SOLR-3857
 URL: https://issues.apache.org/jira/browse/SOLR-3857
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0-BETA, 3.6.1
Reporter: James Dyer


The wiki describes a usage of CachedSqlEntityProcessor like this:

{code:xml}

{code}

This creates what the code refers as a "simple" cache.  Rather than build the 
entire cache up-front, the cache is built on-the-go.  I think this has limited 
use cases but it would be nice to preserve the feature if possible.

Unfortunately this was not included in any (effective) unit tests, and 
SOLR-2382 entirely broke the functionality for 3.6/4.0-alpha+ .  At a first 
glance, the fix may not be entirely straightforward.

This was found while writing tests for SOLR-3856.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3856) DIH: Better tests for SqlEntityProcessor

[James Dyer (JIRA)]

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

James Dyer updated SOLR-3856:
-

Attachment: SOLR-3856.patch
SOLR-3856-3.5.patch

Here is a patch for trunk and also for Solr 3.5.  (3.5 is the latest version 
prior to SOLR-2382 and other changes that may have caused undetected bugs, so 
its a good "control case")

This first patch only replaces the "full-import" tests.  I am working on 
"delta" tests now.

> DIH: Better tests for SqlEntityProcessor
> 
>
> Key: SOLR-3856
> URL: https://issues.apache.org/jira/browse/SOLR-3856
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Reporter: James Dyer
>Assignee: James Dyer
> Attachments: SOLR-3856-3.5.patch, SOLR-3856.patch
>
>
> The current tests for SqlEntityProcessor (& CachedSqlEntityProcessor), while 
> many, do not reliably fail when bugs are introduced!  They are also difficult 
> to look at and understand.  As we move Jenkins onto new environments, we have 
> found several of them fail regularly leading to "@Ignore".  
> My aim here is to write all new tests for (Cached)SqlEntityProcessor, and to 
> document (hopefully fix) any bugs this reveals.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (SOLR-3856) DIH: Better tests for SqlEntityProcessor

[James Dyer (JIRA)]

James Dyer created SOLR-3856:


 Summary: DIH: Better tests for SqlEntityProcessor
 Key: SOLR-3856
 URL: https://issues.apache.org/jira/browse/SOLR-3856
 Project: Solr
  Issue Type: Improvement
  Components: contrib - DataImportHandler
Reporter: James Dyer
Assignee: James Dyer


The current tests for SqlEntityProcessor (& CachedSqlEntityProcessor), while 
many, do not reliably fail when bugs are introduced!  They are also difficult 
to look at and understand.  As we move Jenkins onto new environments, we have 
found several of them fail regularly leading to "@Ignore".  

My aim here is to write all new tests for (Cached)SqlEntityProcessor, and to 
document (hopefully fix) any bugs this reveals.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3855) DocValues support

[Adrien Grand (JIRA)]

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

Adrien Grand commented on SOLR-3855:


I have planned to start working on this when 4.0 is released.

> DocValues support
> -
>
> Key: SOLR-3855
> URL: https://issues.apache.org/jira/browse/SOLR-3855
> Project: Solr
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.1, 5.0
>
>
> It would be nice if Solr supported DocValues:
>  - for ID fields (fewer disk seeks when running distributed search),
>  - for sorting/faceting/function queries (faster warmup time than fieldcache),
>  - better on-disk and in-memory efficiency (you can use packed impls).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (SOLR-3855) DocValues support

[Adrien Grand (JIRA)]

Adrien Grand created SOLR-3855:
--

 Summary: DocValues support
 Key: SOLR-3855
 URL: https://issues.apache.org/jira/browse/SOLR-3855
 Project: Solr
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 4.1, 5.0


It would be nice if Solr supported DocValues:
 - for ID fields (fewer disk seeks when running distributed search),
 - for sorting/faceting/function queries (faster warmup time than fieldcache),
 - better on-disk and in-memory efficiency (you can use packed impls).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: jar error while trying to build

[Mohamed Lrhazi]

to make sure, I just re-unpacked the tarball and rerun:

ml623@cab2b:~/tmp/pylucene-3.6.1-2/ > ANT=/opt/ant/bin/ant make

and got the same error.

Any idea what could be causing this?

Thanks a lot,
Mohamed.

On Tue, Sep 18, 2012 at 6:39 PM, Andi Vajda  wrote:
>
> On Tue, 18 Sep 2012, Mohamed Lrhazi wrote:
>
>> Hello,
>>
>> I am trying to build pylucene on a redhat ent 6.1. the make fails with
>> an error pasted bellow.
>>
>> Any hints appreciated.
>
>
> Your Makefile seems to be broken in a way that --jar somewhere became just
> jar and it's downhill from there.
>jar lucene-java-3.6.1/lucene/build/core/lucene-core-3.6.1.jar --jar
>
> Andi..
>
>
>>
>> Thanks a lot,
>> Mohamed.
>>
>>
>> cd lucene-java-3.6.1/lucene; (/opt/ant/bin/ant ivy-fail ||
>> /opt/ant/bin/ant ivy-bootstrap)
>> Buildfile: /home/ml623/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build.xml
>>
>> ivy-fail:
>>
>> BUILD SUCCESSFUL
>> Total time: 0 seconds
>> ICU not installed
>> jar lucene-java-3.6.1/lucene/build/core/lucene-core-3.6.1.jar --jar
>>
>> lucene-java-3.6.1/lucene/build/contrib/analyzers/common/lucene-analyzers-3.6.1.jar
>> --jar
>> lucene-java-3.6.1/lucene/build/contrib/memory/lucene-memory-3.6.1.jar
>> --jar
>> lucene-java-3.6.1/lucene/build/contrib/highlighter/lucene-highlighter
>> -3.6.1.jar --jar build/jar/extensions.jar --jar
>> lucene-java-3.6.1/lucene/build/contrib/queries/lucene-queries-3.6.1.jar
>> --jar lucene-java-3.6.1/lucene/
>> build/contrib/grouping/lucene-grouping-3.6.1.jar --jar
>> lucene-java-3.6.1/lucene/build/contrib/join/lucene-join-3.6.1.jar
>> --jar lucene-java-3.6.1/lucene
>> /build/contrib/facet/lucene-facet-3.6.1.jar --jar
>>
>> lucene-java-3.6.1/lucene/build/contrib/spellchecker/lucene-spellchecker-3.6.1.jar
>> --package java.lan
>> g java.lang.System java.lang.Runtime java.lang.IllegalStateException
>> java.lang.IndexOutOfBoundsException --package java.util
>> java.util.Arrays java.util
>> .HashMap java.util.HashSet java.util.NoSuchElementException
>> java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator
>> --package java.util.regex --package java.io java.io.StringReader
>> java.io.InputStreamReader java.io.FileInputStream --exclude
>> org.apache.lucene.queryParser.Token --exclude
>> org.apache.lucene.queryParser.TokenMgrError --exclude
>> org.apache.lucene.queryParser.QueryParserTokenManager --exclude
>> org.apache.lucene.queryParser.ParseException --exclude
>> org.apache.lucene.queryParser.CharStream --exclude
>> org.apache.lucene.search.regex.JakartaRegexpCapabilities --exclude
>> org.apache.regexp.RegexpTunnel --exclude
>> org.apache.lucene.analysis.cn.smart.AnalyzerProfile --python lucene
>> --mapping org.apache.lucene.document.Document
>> 'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping
>> java.util.Properties
>> 'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --sequence
>> java.util.AbstractList 'size:()I' 'get:(I)Ljava/lang/Object;' --rename
>> org.apache.lucene.search.highlight.SpanScorer=HighlighterSpanScorer
>> --rename org.apache.lucene.search.highlight.Scorer=HighlighterScorer
>> --rename org.apache.lucene.search.spell.Dictionary=SpellDictionary
>> --rename org.apache.lucene.search.suggest.fst.Sort=SuggestSort
>> --rename org.apache.lucene.store.DataInput=StoreDataInput --rename
>> org.apache.lucene.store.DataOutput=StoreDataOutput --rename
>> org.tartarus.snowball.ext.DutchStemmer=DutchPorterStemmer --rename
>> org.tartarus.snowball.ext.FrenchStemmer=FrenchPorterStemmer --rename
>> org.tartarus.snowball.ext.GermanStemmer=GermanPorterStemmer --rename
>> org.tartarus.snowball.ext.PortugueseStemmer=PortuguesePorterStemmer
>> --version 3.6.1 --module python/collections.py --module
>> python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py
>> --module python/ICUTransformFilter.py  --files  --build
>> Illegal option: l
>> Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] [entry-point]
>> [-C dir] files ...
>> Options:
>>-c  create new archive
>>-t  list table of contents for archive
>> ...
>>
>

Re: [jira] [Commented] (LUCENE-4406) Print out where tests failed at the end of running the Test Suite

[Erick Erickson]

bq:  Last minute commit before leaving - red card.

Worked with a guy once who put a copy-on-write algorithm in the very
base layer upon
which all other layers depended in C++ code on Friday late. And left
for a 2-week holiday
the next day.

This is no foul in comparison 

On Wed, Sep 19, 2012 at 10:20 AM, Dawid Weiss (JIRA)  wrote:
>
> [ 
> https://issues.apache.org/jira/browse/LUCENE-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458714#comment-13458714
>  ]
>
> Dawid Weiss commented on LUCENE-4406:
> -
>
> Thanks guys, my bad -- I actually ran ant precommit but I work on a git 
> checkout and it failed on me (svn required). Last minute commit before 
> leaving - red card.
>
>> Print out where tests failed at the end of running the Test Suite
>> -
>>
>> Key: LUCENE-4406
>> URL: https://issues.apache.org/jira/browse/LUCENE-4406
>> Project: Lucene - Core
>>  Issue Type: Bug
>>  Components: general/test
>>Reporter: Grant Ingersoll
>>Assignee: Dawid Weiss
>>Priority: Minor
>> Fix For: 5.0, 4.0
>>
>>
>> It would be nice if, at the end of running ant test, it spit out the names 
>> of which tests failed so that one doesn't have to go scrolling up through 
>> the output or go run grep on the test-reports as a separate step.
>> For another project, I use:
>> {code}
>> 
>> Looking for summaries in: ${build.dir}/test-reports with basedir: 
>> ${basedir}
>> Errors:
>> 
>> 
>> 
>> 
>> 
>> 
>> Failures:
>> 
>> 
>> 
>> 
>> 
>> 
>>   
>> {code}
>> which can likely be modified for Lucene.  I can do it, but wanted to see if 
>> others had an opinion.
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators
> 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

[jira] [Resolved] (LUCENE-4408) license check fails if you previously built maven release artifacts

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-4408.
-

Resolution: Fixed

> license check fails if you previously built maven release artifacts
> ---
>
> Key: LUCENE-4408
> URL: https://issues.apache.org/jira/browse/LUCENE-4408
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Robert Muir
> Fix For: 4.0
>
>
> Ive been doing a lot of 'ant nightly-smoke' testing the packaging.
> when you build releases, it creates .jar files and puts them in e.g. 
> lucene/dist and solr/package
> But solr/package is not currently excluded from 'ant validate':
> {noformat}
> check-licenses:
>  [echo] License check under: /home/rmuir/workspace/branch_4x/solr
>  [licenses] MISSING sha1 checksum file for: 
> /home/rmuir/workspace/branch_4x/solr/package/maven/org/apache/solr/solr-analysis-extras/4.0/solr-analysis-extras-4.0-javadoc.jar
>  [licenses] MISSING sha1 checksum file for: 
> /home/rmuir/workspace/branch_4x/solr/package/maven/org/apache/solr/solr-analysis-extras/4.0/solr-analysis-extras-4.0-sources.jar
>  [licenses] MISSING sha1 checksum file for: 
> /home/rmuir/workspace/branch_4x/solr/package/maven/org/apache/solr/solr-analysis-extras/4.0/solr-analysis-extras-4.0.jar
> ...
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4408) license check fails if you previously built maven release artifacts

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4408:
-

Simple patch: I'll commit shortly
{noformat}
Index: solr/build.xml
===
--- solr/build.xml  (revision 1387608)
+++ solr/build.xml  (working copy)
@@ -199,6 +199,7 @@
 
 
 
+
   
   
 
{noformat}

But, i REALLY dont like that lucene puts artifacts in dist/ and solr puts them 
in package/

This is something i dont want to deal with for 4.0 though, we should fix it 
after the release.

> license check fails if you previously built maven release artifacts
> ---
>
> Key: LUCENE-4408
> URL: https://issues.apache.org/jira/browse/LUCENE-4408
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Robert Muir
> Fix For: 4.0
>
>
> Ive been doing a lot of 'ant nightly-smoke' testing the packaging.
> when you build releases, it creates .jar files and puts them in e.g. 
> lucene/dist and solr/package
> But solr/package is not currently excluded from 'ant validate':
> {noformat}
> check-licenses:
>  [echo] License check under: /home/rmuir/workspace/branch_4x/solr
>  [licenses] MISSING sha1 checksum file for: 
> /home/rmuir/workspace/branch_4x/solr/package/maven/org/apache/solr/solr-analysis-extras/4.0/solr-analysis-extras-4.0-javadoc.jar
>  [licenses] MISSING sha1 checksum file for: 
> /home/rmuir/workspace/branch_4x/solr/package/maven/org/apache/solr/solr-analysis-extras/4.0/solr-analysis-extras-4.0-sources.jar
>  [licenses] MISSING sha1 checksum file for: 
> /home/rmuir/workspace/branch_4x/solr/package/maven/org/apache/solr/solr-analysis-extras/4.0/solr-analysis-extras-4.0.jar
> ...
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4408) license check fails if you previously built maven release artifacts

[Robert Muir (JIRA)]

Robert Muir created LUCENE-4408:
---

 Summary: license check fails if you previously built maven release 
artifacts
 Key: LUCENE-4408
 URL: https://issues.apache.org/jira/browse/LUCENE-4408
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/build
Reporter: Robert Muir
 Fix For: 4.0


Ive been doing a lot of 'ant nightly-smoke' testing the packaging.

when you build releases, it creates .jar files and puts them in e.g. 
lucene/dist and solr/package

But solr/package is not currently excluded from 'ant validate':
{noformat}
check-licenses:
 [echo] License check under: /home/rmuir/workspace/branch_4x/solr
 [licenses] MISSING sha1 checksum file for: 
/home/rmuir/workspace/branch_4x/solr/package/maven/org/apache/solr/solr-analysis-extras/4.0/solr-analysis-extras-4.0-javadoc.jar
 [licenses] MISSING sha1 checksum file for: 
/home/rmuir/workspace/branch_4x/solr/package/maven/org/apache/solr/solr-analysis-extras/4.0/solr-analysis-extras-4.0-sources.jar
 [licenses] MISSING sha1 checksum file for: 
/home/rmuir/workspace/branch_4x/solr/package/maven/org/apache/solr/solr-analysis-extras/4.0/solr-analysis-extras-4.0.jar
...
{noformat}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4406) Print out where tests failed at the end of running the Test Suite

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-4406:
-

As for maven and sonatype - it shouldn't be a problem, I know, but this time I 
waited. It took 5 hours to sync between sonatype and maven central. I admit it 
is a pain to wait so long before you can make an update to downstream  projects.

> Print out where tests failed at the end of running the Test Suite
> -
>
> Key: LUCENE-4406
> URL: https://issues.apache.org/jira/browse/LUCENE-4406
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Grant Ingersoll
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 5.0, 4.0
>
>
> It would be nice if, at the end of running ant test, it spit out the names of 
> which tests failed so that one doesn't have to go scrolling up through the 
> output or go run grep on the test-reports as a separate step.
> For another project, I use:
> {code}
> 
> Looking for summaries in: ${build.dir}/test-reports with basedir: 
> ${basedir}
> Errors:
> 
> 
> 
> 
> 
> 
> Failures:
> 
> 
> 
> 
> 
> 
>   
> {code} 
> which can likely be modified for Lucene.  I can do it, but wanted to see if 
> others had an opinion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4406) Print out where tests failed at the end of running the Test Suite

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-4406:
-

Thanks guys, my bad -- I actually ran ant precommit but I work on a git 
checkout and it failed on me (svn required). Last minute commit before leaving 
- red card. 

> Print out where tests failed at the end of running the Test Suite
> -
>
> Key: LUCENE-4406
> URL: https://issues.apache.org/jira/browse/LUCENE-4406
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Grant Ingersoll
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 5.0, 4.0
>
>
> It would be nice if, at the end of running ant test, it spit out the names of 
> which tests failed so that one doesn't have to go scrolling up through the 
> output or go run grep on the test-reports as a separate step.
> For another project, I use:
> {code}
> 
> Looking for summaries in: ${build.dir}/test-reports with basedir: 
> ${basedir}
> Errors:
> 
> 
> 
> 
> 
> 
> Failures:
> 
> 
> 
> 
> 
> 
>   
> {code} 
> which can likely be modified for Lucene.  I can do it, but wanted to see if 
> others had an opinion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4406) Print out where tests failed at the end of running the Test Suite

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4406:
-

I'll run ant jar-checksums and fix this.

> Print out where tests failed at the end of running the Test Suite
> -
>
> Key: LUCENE-4406
> URL: https://issues.apache.org/jira/browse/LUCENE-4406
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Grant Ingersoll
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 5.0, 4.0
>
>
> It would be nice if, at the end of running ant test, it spit out the names of 
> which tests failed so that one doesn't have to go scrolling up through the 
> output or go run grep on the test-reports as a separate step.
> For another project, I use:
> {code}
> 
> Looking for summaries in: ${build.dir}/test-reports with basedir: 
> ${basedir}
> Errors:
> 
> 
> 
> 
> 
> 
> Failures:
> 
> 
> 
> 
> 
> 
>   
> {code} 
> which can likely be modified for Lucene.  I can do it, but wanted to see if 
> others had an opinion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: Spatial field names in Solr

[Jan Høydahl]

The class names can be long and descriptive, but the field-type "location_rpt" 
is short and nice.

Questions:
Should we also add a  to make it possible to use it with an unmodified schema?
Should we deprecate the "old" LatLonType in code and docs or would you say that 
both are needed due to features/performance?
If we want people to use the new spatial over the old, the exampledocs should 
also index&query store locations using the new field

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com

19. sep. 2012 kl. 04:02 skrev David Smiley (@MITRE.org) :

> Hi Jack,
> 
> Thanks for your interest. Each SpatialStrategy has its pros and cons.  I'm
> working through creating slides for a conference today in fact: 
> http://www.basistech.com/search-conference/presentations/   Now that the
> Solr adapters are committed, I'll be focusing more on documentation.  That
> means the wiki, and javadoc comments on the SpatialStrategy impls to
> indicate how each works.
> 
> ~ David
> 
> 
> 
> -
> Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
> --
> View this message in context: 
> http://lucene.472066.n3.nabble.com/Spatial-field-names-in-Solr-tp4008769p4008787.html
> Sent from the Lucene - Java Developer mailing list archive at Nabble.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] [Commented] (LUCENE-4406) Print out where tests failed at the end of running the Test Suite

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4406:
---

But SHA1 che chksums are missing:

{noformat}
check-licenses:
 [echo] License check under: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene
 [licenses] MISSING sha1 checksum file for: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/junit4-ant-2.0.1.jar
 [licenses] MISSING sha1 checksum file for: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.0.1.jar
 [licenses] Scanned 19 JAR file(s) for licenses (in 0.26s.), 2 error(s).
{noformat}

> Print out where tests failed at the end of running the Test Suite
> -
>
> Key: LUCENE-4406
> URL: https://issues.apache.org/jira/browse/LUCENE-4406
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Grant Ingersoll
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 5.0, 4.0
>
>
> It would be nice if, at the end of running ant test, it spit out the names of 
> which tests failed so that one doesn't have to go scrolling up through the 
> output or go run grep on the test-reports as a separate step.
> For another project, I use:
> {code}
> 
> Looking for summaries in: ${build.dir}/test-reports with basedir: 
> ${basedir}
> Errors:
> 
> 
> 
> 
> 
> 
> Failures:
> 
> 
> 
> 
> 
> 
>   
> {code} 
> which can likely be modified for Lucene.  I can do it, but wanted to see if 
> others had an opinion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-trunk-Linux (32bit/jdk1.8.0-ea-b51) - Build # 1222 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/1222/
Java: 32bit/jdk1.8.0-ea-b51 -server -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 12248 lines...]
check-licenses:
 [echo] License check under: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene
 [licenses] MISSING sha1 checksum file for: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/junit4-ant-2.0.1.jar
 [licenses] MISSING sha1 checksum file for: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.0.1.jar

[...truncated 1 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:67: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:155: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/custom-tasks.xml:44:
 License check failed. Check the logs.

Total time: 25 minutes 7 seconds
Build step 'Invoke Ant' marked build as failure
Recording test results
Description set: Java: 32bit/jdk1.8.0-ea-b51 -server -XX:+UseG1GC
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Commented] (LUCENE-4406) Print out where tests failed at the end of running the Test Suite

[Steven Rowe (JIRA)]

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

Steven Rowe commented on LUCENE-4406:
-

FYI, Dawid, Maven was able to download the new randomizedtesting-runner:2.0.1 
dependency from the Sonatype OSS repo right after you committed this:

{noformat}
[INFO] 
[INFO] Building Lucene Test Framework
[INFO]task-segment: [install]
[INFO] 
Downloading: 
http://oss.sonatype.org/content/repositories/releases/com/carrotsearch/randomizedtesting/randomizedtesting-runner/2.0.1/randomizedtesting-runner-2.0.1.pom
  
Downloading: 
http://oss.sonatype.org/content/repositories/releases/com/carrotsearch/randomizedtesting/randomizedtesting-parent/2.0.1/randomizedtesting-parent-2.0.1.pom

Downloading: 
http://oss.sonatype.org/content/repositories/releases/com/carrotsearch/randomizedtesting/randomizedtesting-runner/2.0.1/randomizedtesting-runner-2.0.1.jar
190K downloaded  (randomizedtesting-runner-2.0.1.jar)
{noformat}


> Print out where tests failed at the end of running the Test Suite
> -
>
> Key: LUCENE-4406
> URL: https://issues.apache.org/jira/browse/LUCENE-4406
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Grant Ingersoll
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 5.0, 4.0
>
>
> It would be nice if, at the end of running ant test, it spit out the names of 
> which tests failed so that one doesn't have to go scrolling up through the 
> output or go run grep on the test-reports as a separate step.
> For another project, I use:
> {code}
> 
> Looking for summaries in: ${build.dir}/test-reports with basedir: 
> ${basedir}
> Errors:
> 
> 
> 
> 
> 
> 
> Failures:
> 
> 
> 
> 
> 
> 
>   
> {code} 
> which can likely be modified for Lucene.  I can do it, but wanted to see if 
> others had an opinion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4399) Rename AppendingCodec to Appending40Codec

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-4399:


+1 for the patch (correctly detecting format changes & throwing TooNew/Old) and 
for moving AppendingCodec to test-framework.

> Rename AppendingCodec to Appending40Codec
> -
>
> Key: LUCENE-4399
> URL: https://issues.apache.org/jira/browse/LUCENE-4399
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.0
>
> Attachments: LUCENE-4399.patch, LUCENE-4399.patch
>
>
> In order AppendingCodec to follow Lucene codecs version, I think its name 
> should include a version number (so that, for example, if we get to releave 
> Lucene 4.3 with a new Lucene43Codec, there will also be a new 
> Appending43Codec).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4399) Rename AppendingCodec to Appending40Codec

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4399:
-

{quote}
I like this idea better. People who want an appending codec just need to extend 
the last Lucene4xCodec.getPostingsFormatForField and there will be no back 
compat issue. Maybe we should just advertise in Lucene4xCodec javadoc that this 
is how to obtain an appending codec.
{quote}

Right my only hesitation before here was 'exposing our guts' a bit too much. 
For example, this scheme breaks if in lucene 4.2 
you write a fancy new default stored fields format that needs to seek-on-write. 

But I think we shouldnt worry about this: we can just address it as it comes 
(and if a Codec makes sense then, lets deal with it).

Its like the analysis package, if we implement something as a TokenFilter thats 
ok. We don't necessarily need to hide ourselves
by providing an Analyzer too. If we want to make it a Tokenizer later because 
that makes more sense, then we just do that :)

Otherwise we will have a lot of delegates and complex code for only theoretical 
future situations and I think we should avoid this.


> Rename AppendingCodec to Appending40Codec
> -
>
> Key: LUCENE-4399
> URL: https://issues.apache.org/jira/browse/LUCENE-4399
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.0
>
> Attachments: LUCENE-4399.patch, LUCENE-4399.patch
>
>
> In order AppendingCodec to follow Lucene codecs version, I think its name 
> should include a version number (so that, for example, if we get to releave 
> Lucene 4.3 with a new Lucene43Codec, there will also be a new 
> Appending43Codec).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4399) Rename AppendingCodec to Appending40Codec

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-4399:
--

bq. AppendingCodec extends Lucene40Codec and returns AppendingPF for every 
field.

But I think we would like it to extend Lucene43Codec when we release it and 
this will break back compat for Appending?

bq. remove AppendingCodec entirely (just move to test-framework), because 
someone could do the above themselves.

I like this idea better. People who want an appending codec just need to extend 
the last Lucene4xCodec.getPostingsFormatForField and there will be no back 
compat issue. Maybe we should just advertise in Lucene4xCodec javadoc that this 
is how to obtain an appending codec.

+1 for your patch

> Rename AppendingCodec to Appending40Codec
> -
>
> Key: LUCENE-4399
> URL: https://issues.apache.org/jira/browse/LUCENE-4399
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.0
>
> Attachments: LUCENE-4399.patch, LUCENE-4399.patch
>
>
> In order AppendingCodec to follow Lucene codecs version, I think its name 
> should include a version number (so that, for example, if we get to releave 
> Lucene 4.3 with a new Lucene43Codec, there will also be a new 
> Appending43Codec).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3685) Solr Cloud sometimes skipped peersync attempt and replicated instead due to tlog flags not being cleared when no updates were buffered during a previous replication.

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-3685:
-

{quote}So what we're seeing here is the mmapped nodes use more RES and SHR than 
the NIO node. VIRT is as expected. I'll change another node to NIO and keep 
them running again for the next few days and keep sending documents and firing 
queries.{quote}

there is still an issue with mmap and high RES opposed to NIOFS but the actual 
issue is already resolved. I'll open a new issue.

> Solr Cloud sometimes skipped peersync attempt and replicated instead due to 
> tlog flags not being cleared when no updates were buffered during a previous 
> replication.
> -
>
> Key: SOLR-3685
> URL: https://issues.apache.org/jira/browse/SOLR-3685
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java), SolrCloud
>Affects Versions: 4.0-ALPHA
> Environment: Debian GNU/Linux Squeeze 64bit
> Solr 5.0-SNAPSHOT 1365667M - markus - 2012-07-25 19:09:43
>Reporter: Markus Jelsma
>Assignee: Yonik Seeley
>Priority: Critical
> Fix For: 4.0, 5.0
>
> Attachments: info.log, oom-killer.log, pmap.log
>
>
> There's a serious problem with restarting nodes, not cleaning old or unused 
> index directories and sudden replication and Java being killed by the OS due 
> to excessive memory allocation. Since SOLR-1781 was fixed index directories 
> get cleaned up when a node is being restarted cleanly, however, old or unused 
> index directories still pile up if Solr crashes or is being killed by the OS, 
> happening here.
> We have a six-node 64-bit Linux test cluster with each node having two 
> shards. There's 512MB RAM available and no swap. Each index is roughly 27MB 
> so about 50MB per node, this fits easily and works fine. However, if a node 
> is being restarted, Solr will consistently crash because it immediately eats 
> up all RAM. If swap is enabled Solr will eat an additional few 100MB's right 
> after start up.
> This cannot be solved by restarting Solr, it will just crash again and leave 
> index directories in place until the disk is full. The only way i can restart 
> a node safely is to delete the index directories and have it replicate from 
> another node. If i then restart the node it will crash almost consistently.
> I'll attach a log of one of the nodes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4407) XML-forbidden unicode characters break XML test reports

[Dawid Weiss (JIRA)]

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

Dawid Weiss resolved LUCENE-4407.
-

   Resolution: Fixed
Fix Version/s: 4.0
   5.0

Should be fine now (with invalid characters at least). Note that XML output is 
not able to reproduce console output verbatim because of this.

> XML-forbidden unicode characters break XML test reports
> ---
>
> Key: LUCENE-4407
> URL: https://issues.apache.org/jira/browse/LUCENE-4407
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
> Fix For: 5.0, 4.0
>
>
> Disallowed by spec. XML unicode characters (in Strings) produce invalid XML 
> reports which then fail on jenkins.
> I think this would also be the case with regular ant/maven runners but I 
> didn't check. It'd be interesting to see if they cater for this somehow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4406) Print out where tests failed at the end of running the Test Suite

[Dawid Weiss (JIRA)]

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

Dawid Weiss resolved LUCENE-4406.
-

   Resolution: Fixed
Fix Version/s: 4.0
   5.0

> Print out where tests failed at the end of running the Test Suite
> -
>
> Key: LUCENE-4406
> URL: https://issues.apache.org/jira/browse/LUCENE-4406
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Grant Ingersoll
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 5.0, 4.0
>
>
> It would be nice if, at the end of running ant test, it spit out the names of 
> which tests failed so that one doesn't have to go scrolling up through the 
> output or go run grep on the test-reports as a separate step.
> For another project, I use:
> {code}
> 
> Looking for summaries in: ${build.dir}/test-reports with basedir: 
> ${basedir}
> Errors:
> 
> 
> 
> 
> 
> 
> Failures:
> 
> 
> 
> 
> 
> 
>   
> {code} 
> which can likely be modified for Lucene.  I can do it, but wanted to see if 
> others had an opinion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4399) Rename AppendingCodec to Appending40Codec

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-4399:


Attachment: LUCENE-4399.patch

Thinking about this more, in my opinion it could be overkill for e.g. 
AppendingPF to do this.

We should forget about AppendingPF and AppendingCodec and just look at what it 
really is:
a wrapper around BlockTree.

In my opinion the easy win here is to ensure that if we change BlockTree, 
Appending correctly
gets IndexTooOld/IndexTooNew exceptions.

> Rename AppendingCodec to Appending40Codec
> -
>
> Key: LUCENE-4399
> URL: https://issues.apache.org/jira/browse/LUCENE-4399
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.0
>
> Attachments: LUCENE-4399.patch, LUCENE-4399.patch
>
>
> In order AppendingCodec to follow Lucene codecs version, I think its name 
> should include a version number (so that, for example, if we get to releave 
> Lucene 4.3 with a new Lucene43Codec, there will also be a new 
> Appending43Codec).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3854) SolrCloud does not work with https

[Sami Siren (JIRA)]

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

Sami Siren updated SOLR-3854:
-

Attachment: SOLR-3854.patch

Here's a patch against trunk that allows one to use https too.

> SolrCloud does not work with https
> --
>
> Key: SOLR-3854
> URL: https://issues.apache.org/jira/browse/SOLR-3854
> Project: Solr
>  Issue Type: Bug
>Reporter: Sami Siren
>Assignee: Sami Siren
> Fix For: 4.0
>
> Attachments: SOLR-3854.patch
>
>
> There are a few places in current codebase that assume http is used. This 
> prevents using https when running solr in cloud mode.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (SOLR-3854) SolrCloud does not work with https

[Sami Siren (JIRA)]

Sami Siren created SOLR-3854:


 Summary: SolrCloud does not work with https
 Key: SOLR-3854
 URL: https://issues.apache.org/jira/browse/SOLR-3854
 Project: Solr
  Issue Type: Bug
Reporter: Sami Siren
Assignee: Sami Siren
 Fix For: 4.0


There are a few places in current codebase that assume http is used. This 
prevents using https when running solr in cloud mode.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4399) Rename AppendingCodec to Appending40Codec

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4399:
-

I also don't like the .dlg file etc. I think if you want to record the inner 
codec name
you should just read/write a SegmentInfo attribute.

> Rename AppendingCodec to Appending40Codec
> -
>
> Key: LUCENE-4399
> URL: https://issues.apache.org/jira/browse/LUCENE-4399
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.0
>
> Attachments: LUCENE-4399.patch
>
>
> In order AppendingCodec to follow Lucene codecs version, I think its name 
> should include a version number (so that, for example, if we get to releave 
> Lucene 4.3 with a new Lucene43Codec, there will also be a new 
> Appending43Codec).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4399) Rename AppendingCodec to Appending40Codec

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4399:
-

Hmm I'm confused by the changes to AppendingCodec: its not really a 
codec-wrapper
its just coded that way.

Actually the whole thing is very dependent on the implementation details of the 
current
term dictionary right? thats the only place that currently seeks, where it 
changes
the behavior.

so we have a number of alternatives:
* AppendingCodec extends Lucene40Codec and returns AppendingPF for every field.
* remove AppendingCodec entirely (just move to test-framework), because someone 
could do the above themselves.

> Rename AppendingCodec to Appending40Codec
> -
>
> Key: LUCENE-4399
> URL: https://issues.apache.org/jira/browse/LUCENE-4399
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.0
>
> Attachments: LUCENE-4399.patch
>
>
> In order AppendingCodec to follow Lucene codecs version, I think its name 
> should include a version number (so that, for example, if we get to releave 
> Lucene 4.3 with a new Lucene43Codec, there will also be a new 
> Appending43Codec).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4399) Rename AppendingCodec to Appending40Codec

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4399:
-

I dont want to use an SPI loader for postingsbaseformat. 

i dont even like postingsbaseformat :)

SPI is really heavy and we should avoid it, I think we just need to look at how 
we can refactor
this thing so it works the way we want.

> Rename AppendingCodec to Appending40Codec
> -
>
> Key: LUCENE-4399
> URL: https://issues.apache.org/jira/browse/LUCENE-4399
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.0
>
> Attachments: LUCENE-4399.patch
>
>
> In order AppendingCodec to follow Lucene codecs version, I think its name 
> should include a version number (so that, for example, if we get to releave 
> Lucene 4.3 with a new Lucene43Codec, there will also be a new 
> Appending43Codec).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4399) Rename AppendingCodec to Appending40Codec

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-4399:
-

Attachment: LUCENE-4399.patch

This patch attemps to fix the problem for the Appending codec and the Direct 
postings format (BloomFilter already serialized the name of its wrapped 
postings format).

I am not fully satisfied with the way I handle AppendingCodec, suggestions are 
welcome.

I had a look at Pulsing but this looks complicated (to me at least)... For 
Pulsing, should we rather:
 - use a SPI loader for PostingsBaseFormat,
 - or leave it this way for 4.0?

> Rename AppendingCodec to Appending40Codec
> -
>
> Key: LUCENE-4399
> URL: https://issues.apache.org/jira/browse/LUCENE-4399
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.0
>
> Attachments: LUCENE-4399.patch
>
>
> In order AppendingCodec to follow Lucene codecs version, I think its name 
> should include a version number (so that, for example, if we get to releave 
> Lucene 4.3 with a new Lucene43Codec, there will also be a new 
> Appending43Codec).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4397) TestIndexWriterWithThreads.testRollbackAndCommitWithThreads is sometimes very very slow

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-4397.
-

Resolution: Fixed

> TestIndexWriterWithThreads.testRollbackAndCommitWithThreads is sometimes very 
> very slow
> ---
>
> Key: LUCENE-4397
> URL: https://issues.apache.org/jira/browse/LUCENE-4397
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Robert Muir
> Attachments: LUCENE-4397.patch, LUCENE-4397.patch, LUCENE-4397.patch
>
>
> e.g. ant test -Dtestcase=TestIndexWriterWithThreads 
> -Dtests.seed=C9BE919B1BE0DAC7

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4397) TestIndexWriterWithThreads.testRollbackAndCommitWithThreads is sometimes very very slow

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-4397:


Attachment: LUCENE-4397.patch

updated patch: I'd rather just use newDirectory actually. 

This means the test will be occasionally slow on windows, but I think thats ok. 
I dont want to start the path of losing test coverage because of certain os 
brokenness.

> TestIndexWriterWithThreads.testRollbackAndCommitWithThreads is sometimes very 
> very slow
> ---
>
> Key: LUCENE-4397
> URL: https://issues.apache.org/jira/browse/LUCENE-4397
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Robert Muir
> Attachments: LUCENE-4397.patch, LUCENE-4397.patch, LUCENE-4397.patch
>
>
> e.g. ant test -Dtestcase=TestIndexWriterWithThreads 
> -Dtests.seed=C9BE919B1BE0DAC7

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4402) TestAddTaxonomy.testConcurrency failure

[Shai Erera (JIRA)]

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

Shai Erera resolved LUCENE-4402.


   Resolution: Fixed
Fix Version/s: 4.0
   3.6.2
   5.0
 Assignee: Shai Erera

Committed revisions 1387540, 1387542 and 1387546 (3x, trunk and 4x 
respectively).
I also modified testConcurrency to create atLeast(1) categories instead of 
5000, so that we catch such issues sooner (hopefully).

> TestAddTaxonomy.testConcurrency failure
> ---
>
> Key: LUCENE-4402
> URL: https://issues.apache.org/jira/browse/LUCENE-4402
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/facet
>Affects Versions: 3.6.2
>Reporter: Robert Muir
>Assignee: Shai Erera
> Fix For: 5.0, 3.6.2, 4.0
>
>
> on the 3.x branch:
> {noformat}
> [junit] Testsuite: 
> org.apache.lucene.facet.taxonomy.directory.TestAddTaxonomy
> [junit] Testcase: 
> testConcurrency(org.apache.lucene.facet.taxonomy.directory.TestAddTaxonomy):  
>   Caused an ERROR
> [junit] Index: 1, Size: 2
> [junit] java.lang.IndexOutOfBoundsException: Index: 1, Size: 2
> [junit]   at java.util.ArrayList.rangeCheck(ArrayList.java:604)
> [junit]   at java.util.ArrayList.get(ArrayList.java:382)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.writercache.cl2o.CharBlockArray.charAt(CharBlockArray.java:148)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.CategoryPath.equalsToSerialized(CategoryPath.java:888)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.writercache.cl2o.CompactLabelToOrdinal.getOrdinal(CompactLabelToOrdinal.java:323)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.writercache.cl2o.CompactLabelToOrdinal.getOrdinal(CompactLabelToOrdinal.java:163)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.writercache.cl2o.Cl2oTaxonomyWriterCache.get(Cl2oTaxonomyWriterCache.java:49)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.directory.DirectoryTaxonomyWriter.findCategory(DirectoryTaxonomyWriter.java:386)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.directory.DirectoryTaxonomyWriter.addTaxonomy(DirectoryTaxonomyWriter.java:833)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.directory.TestAddTaxonomy.testConcurrency(TestAddTaxonomy.java:206)
> [junit]   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit]   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [junit]   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit]   at java.lang.reflect.Method.invoke(Method.java:601)
> [junit]   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> [junit]   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> [junit]   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> [junit]   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> [junit]   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> [junit]   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:630)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:536)
> [junit]   at 
> org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:67)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:457)
> [junit]   at 
> org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:74)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:508)
> [junit]   at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> [junit]   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> [junit]   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:146)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50)
> [junit]   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> [junit]   at 
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> [junit]   at 
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> [junit]   at 
> org.junit.runners.ParentRunner.access$000(ParentRunne

[jira] [Updated] (LUCENE-4397) TestIndexWriterWithThreads.testRollbackAndCommitWithThreads is sometimes very very slow

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-4397:


Attachment: LUCENE-4397.patch

here's a patch: there are two things,
* the test is too slow in general (too many iterations)
* the test is super-slow on windows because of syncd i/o: i wired it to use 
mmapdirectory.

> TestIndexWriterWithThreads.testRollbackAndCommitWithThreads is sometimes very 
> very slow
> ---
>
> Key: LUCENE-4397
> URL: https://issues.apache.org/jira/browse/LUCENE-4397
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Robert Muir
> Attachments: LUCENE-4397.patch, LUCENE-4397.patch
>
>
> e.g. ant test -Dtestcase=TestIndexWriterWithThreads 
> -Dtests.seed=C9BE919B1BE0DAC7

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4402) TestAddTaxonomy.testConcurrency failure

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4402:
-

Thanks for digging into this Shai!

> TestAddTaxonomy.testConcurrency failure
> ---
>
> Key: LUCENE-4402
> URL: https://issues.apache.org/jira/browse/LUCENE-4402
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/facet
>Affects Versions: 3.6.2
>Reporter: Robert Muir
>
> on the 3.x branch:
> {noformat}
> [junit] Testsuite: 
> org.apache.lucene.facet.taxonomy.directory.TestAddTaxonomy
> [junit] Testcase: 
> testConcurrency(org.apache.lucene.facet.taxonomy.directory.TestAddTaxonomy):  
>   Caused an ERROR
> [junit] Index: 1, Size: 2
> [junit] java.lang.IndexOutOfBoundsException: Index: 1, Size: 2
> [junit]   at java.util.ArrayList.rangeCheck(ArrayList.java:604)
> [junit]   at java.util.ArrayList.get(ArrayList.java:382)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.writercache.cl2o.CharBlockArray.charAt(CharBlockArray.java:148)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.CategoryPath.equalsToSerialized(CategoryPath.java:888)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.writercache.cl2o.CompactLabelToOrdinal.getOrdinal(CompactLabelToOrdinal.java:323)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.writercache.cl2o.CompactLabelToOrdinal.getOrdinal(CompactLabelToOrdinal.java:163)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.writercache.cl2o.Cl2oTaxonomyWriterCache.get(Cl2oTaxonomyWriterCache.java:49)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.directory.DirectoryTaxonomyWriter.findCategory(DirectoryTaxonomyWriter.java:386)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.directory.DirectoryTaxonomyWriter.addTaxonomy(DirectoryTaxonomyWriter.java:833)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.directory.TestAddTaxonomy.testConcurrency(TestAddTaxonomy.java:206)
> [junit]   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit]   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [junit]   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit]   at java.lang.reflect.Method.invoke(Method.java:601)
> [junit]   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> [junit]   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> [junit]   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> [junit]   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> [junit]   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> [junit]   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:630)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:536)
> [junit]   at 
> org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:67)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:457)
> [junit]   at 
> org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:74)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:508)
> [junit]   at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> [junit]   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> [junit]   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:146)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50)
> [junit]   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> [junit]   at 
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> [junit]   at 
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> [junit]   at 
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> [junit]   at 
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> [junit]   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> [junit]   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> [junit]   at 
> org.apache

[jira] [Updated] (LUCENE-3842) Analyzing Suggester

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-3842:
---

Attachment: LUCENE-3842.patch

New patch, with escaping working, and exactFirst now means exact surface-form.  
I also made ctor parameters maxSurfaceFormsPerAnalyzedForm and 
maxGraphExpansions.

I did the simple linear scan for now ... I think that's fine to commit ("N" is 
bounded).  We may be able to optimize later with something similar to 
getByOutput...

I think this patch is ready to commit to the branch ... and I think we are 
close overall to landing ... still a number of nocommits to resolve though.

> Analyzing Suggester
> ---
>
> Key: LUCENE-3842
> URL: https://issues.apache.org/jira/browse/LUCENE-3842
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/spellchecker
>Affects Versions: 3.6, 4.0-ALPHA
>Reporter: Robert Muir
> Attachments: LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, 
> LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, 
> LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, 
> LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, 
> LUCENE-3842-TokenStream_to_Automaton.patch
>
>
> Since we added shortest-path wFSA search in LUCENE-3714, and generified the 
> comparator in LUCENE-3801,
> I think we should look at implementing suggesters that have more capabilities 
> than just basic prefix matching.
> In particular I think the most flexible approach is to integrate with 
> Analyzer at both build and query time,
> such that we build a wFST with:
> input: analyzed text such as ghost0christmas0past <-- byte 0 here is an 
> optional token separator
> output: surface form such as "the ghost of christmas past"
> weight: the weight of the suggestion
> we make an FST with PairOutputs, but only do the shortest path 
> operation on the weight side (like
> the test in LUCENE-3801), at the same time accumulating the output (surface 
> form), which will be the actual suggestion.
> This allows a lot of flexibility:
> * Using even standardanalyzer means you can offer suggestions that ignore 
> stopwords, e.g. if you type in "ghost of chr...",
>   it will suggest "the ghost of christmas past"
> * we can add support for synonyms/wdf/etc at both index and query time (there 
> are tradeoffs here, and this is not implemented!)
> * this is a basis for more complicated suggesters such as Japanese 
> suggesters, where the analyzed form is in fact the reading,
>   so we would add a TokenFilter that copies ReadingAttribute into term text 
> to support that...
> * other general things like offering suggestions that are more "fuzzy" like 
> using a plural stemmer or ignoring accents or whatever.
> According to my benchmarks, suggestions are still very fast with the 
> prototype (e.g. ~ 100,000 QPS), and the FST size does not
> explode (its short of twice that of a regular wFST, but this is still far 
> smaller than TST or JaSpell, etc).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3788) core creation UI screen should redirect browser to details about newly created core

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-3788:
--

That'll teach me to do things before coffee. Works fine if I, you know, set 
things up properly beforehand ...

> core creation UI screen should redirect browser to details about newly 
> created core
> ---
>
> Key: SOLR-3788
> URL: https://issues.apache.org/jira/browse/SOLR-3788
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0-BETA
>Reporter: Hoss Man
>Assignee: Stefan Matheis (steffkes)
> Attachments: SOLR-3788.patch
>
>
> got confused while testing SOLR-3679 because when you create a new SolrCore 
> using the Admin UI, the form goes away, and you are still looking at the 
> "core admin details" page for whatever SolrCore you were on when you clicked 
> the "Add Core" button -- it would be nice if the successful completion of hte 
> "Add Core" form would redirect you to the sub-page for the core you just 
> added.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4402) TestAddTaxonomy.testConcurrency failure

[Shai Erera (JIRA)]

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

Shai Erera commented on LUCENE-4402:


Found the problem. On 3.6, all DirTW methods are synchronized, but addTaxonomy 
wasn't. The idea was to let someone call addTaxo in parallel to addCategory 
(hence the test), while addTaxo itself calls addCategory internally (which is 
synchronized). The problem is that prior to calling addCategory, it calls 
findCategory, which is not synchronized and cache implementations are not 
thread safe (in 3.6).

So the solution is to call addCategory from addTaxonomy in 3x, 4x and trunk. In 
4x and trunk addCategory is not synchronized, checking the cache first, so the 
existing code is redundant. In 3x since we cannot trust findCategory in a 
multi-threaded env., calling addCategory will solve it.

I'll modify the code and commit the changes - a patch is trivial therefore I 
won't post one.

> TestAddTaxonomy.testConcurrency failure
> ---
>
> Key: LUCENE-4402
> URL: https://issues.apache.org/jira/browse/LUCENE-4402
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/facet
>Affects Versions: 3.6.2
>Reporter: Robert Muir
>
> on the 3.x branch:
> {noformat}
> [junit] Testsuite: 
> org.apache.lucene.facet.taxonomy.directory.TestAddTaxonomy
> [junit] Testcase: 
> testConcurrency(org.apache.lucene.facet.taxonomy.directory.TestAddTaxonomy):  
>   Caused an ERROR
> [junit] Index: 1, Size: 2
> [junit] java.lang.IndexOutOfBoundsException: Index: 1, Size: 2
> [junit]   at java.util.ArrayList.rangeCheck(ArrayList.java:604)
> [junit]   at java.util.ArrayList.get(ArrayList.java:382)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.writercache.cl2o.CharBlockArray.charAt(CharBlockArray.java:148)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.CategoryPath.equalsToSerialized(CategoryPath.java:888)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.writercache.cl2o.CompactLabelToOrdinal.getOrdinal(CompactLabelToOrdinal.java:323)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.writercache.cl2o.CompactLabelToOrdinal.getOrdinal(CompactLabelToOrdinal.java:163)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.writercache.cl2o.Cl2oTaxonomyWriterCache.get(Cl2oTaxonomyWriterCache.java:49)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.directory.DirectoryTaxonomyWriter.findCategory(DirectoryTaxonomyWriter.java:386)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.directory.DirectoryTaxonomyWriter.addTaxonomy(DirectoryTaxonomyWriter.java:833)
> [junit]   at 
> org.apache.lucene.facet.taxonomy.directory.TestAddTaxonomy.testConcurrency(TestAddTaxonomy.java:206)
> [junit]   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit]   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [junit]   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit]   at java.lang.reflect.Method.invoke(Method.java:601)
> [junit]   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> [junit]   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> [junit]   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> [junit]   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> [junit]   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> [junit]   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:630)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:536)
> [junit]   at 
> org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:67)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:457)
> [junit]   at 
> org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:74)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:508)
> [junit]   at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> [junit]   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> [junit]   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> [junit]   at 
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:146)
> 

[jira] [Resolved] (SOLR-3376) SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-3376.
--

Resolution: Fixed

I can't make this happen, closing.

> SolrCloud: Specifying shardId not working correctly, although the failures 
> are inconsistent.
> 
>
> Key: SOLR-3376
> URL: https://issues.apache.org/jira/browse/SOLR-3376
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Erick Erickson
>Assignee: Sami Siren
> Fix For: 4.0
>
>
> I'm seeing some odd results when specifying "shardId" parameter. I'm trying 
> the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
> dir   shardId start orderrunnng ZK   port
> example 1   1   y8983
> example22   2   y7574
> example31   3   y8900
> example42   4   y7500 
> And I'm waiting a bit between starting various examples to let ZK settle down.
> Once all of them are started, I was looking at 
> http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks 
> like (pretty cool IMO, especially since I didn't have to do it). The problem 
> was that shard 2 only reported a single instance, while shard1 showed the two 
> instances I was expecting. I'm running with 3 embedded ZK instances, just for 
> yucks. Interestingly the node that didn't show up was the only node that was 
> NOT running ZK.
> When I removed all the "shardId" parameters, nuked zoo_data from all 
> directories and just started them up (with numShards=2 on the bootstrap ZK 
> node), all 4 nodes showed up just fine.
> When starting with shardId specified and trying to go straight to the admin 
> interface on the node that wasn't showing up, I'd get odd errors like "This 
> interface requires that you activate the admin request handlers, add the 
> following configuration to your solrconfig.xml:". I also couldn't search 
> directly on that machine, "http://localhost:7574/solr/select?q=*:*"; returns a 
> 404 error.
> Command starting server that's giving me trouble: java -Xmx1G 
> -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 
> -DshardId=2 -jar start.jar
> Command for one that works fine:   java -Xmx1G 
> -Djetty.port=8900 -DzkRun 
> -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar 
> start.jar
> Sami Siren and he reports similar issues via e-mail conversation. Sami says 
> that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for 
> him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the 
> recent stuff with Ivy, I may have screwed up when/where the JARs were.
> So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which 
> seems highly suspicious to me. It was failing every time before with 3.3.4, 
> so it sounds like gremlins.
> And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the 
> ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other 
> directories)  and it works fine there too now. Sh. Mostly this is a 
> placeholder to insure we try this, I guarantee that sys admins will want to 
> assign specific machines to specific shards, so this'll get used.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4397) TestIndexWriterWithThreads.testRollbackAndCommitWithThreads is sometimes very very slow

[Dawid Weiss (JIRA)]

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

Dawid Weiss updated LUCENE-4397:


Attachment: LUCENE-4397.patch

It's weird, the variance on this test is indeed very high. I think it may have 
something to do with the fact that it spins many threads (that do i/o) so if 
you're running on a multicore and there are other parallel jvms running tests 
you're putting a load on the hardware. If ran in isolation things get much 
faster (for me).

I've replaced some of the random() calls with the non-asserting random; I see 
some difference but not that much.

> TestIndexWriterWithThreads.testRollbackAndCommitWithThreads is sometimes very 
> very slow
> ---
>
> Key: LUCENE-4397
> URL: https://issues.apache.org/jira/browse/LUCENE-4397
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Robert Muir
> Attachments: LUCENE-4397.patch
>
>
> e.g. ant test -Dtestcase=TestIndexWriterWithThreads 
> -Dtests.seed=C9BE919B1BE0DAC7

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3788) core creation UI screen should redirect browser to details about newly created core

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) commented on SOLR-3788:
-

Erick that sounds a bit like the {{new_core}} directory does not exist? in that 
case i get exactly the same message

> core creation UI screen should redirect browser to details about newly 
> created core
> ---
>
> Key: SOLR-3788
> URL: https://issues.apache.org/jira/browse/SOLR-3788
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0-BETA
>Reporter: Hoss Man
>Assignee: Stefan Matheis (steffkes)
> Attachments: SOLR-3788.patch
>
>
> got confused while testing SOLR-3679 because when you create a new SolrCore 
> using the Admin UI, the form goes away, and you are still looking at the 
> "core admin details" page for whatever SolrCore you were on when you clicked 
> the "Add Core" button -- it would be nice if the successful completion of hte 
> "Add Core" form would redirect you to the sub-page for the core you just 
> added.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3788) core creation UI screen should redirect browser to details about newly created core

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-3788:
--

Hmmm, I got:

Error CREATEing SolrCore 'new_core': Can't find resource 'solrconfig.xml' in 
classpath or 'solr/new_core/conf/', cwd=/Users/Erick/apache/4x/solr/example

> core creation UI screen should redirect browser to details about newly 
> created core
> ---
>
> Key: SOLR-3788
> URL: https://issues.apache.org/jira/browse/SOLR-3788
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0-BETA
>Reporter: Hoss Man
>Assignee: Stefan Matheis (steffkes)
> Attachments: SOLR-3788.patch
>
>
> got confused while testing SOLR-3679 because when you create a new SolrCore 
> using the Admin UI, the form goes away, and you are still looking at the 
> "core admin details" page for whatever SolrCore you were on when you clicked 
> the "Add Core" button -- it would be nice if the successful completion of hte 
> "Add Core" form would redirect you to the sub-page for the core you just 
> added.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (SOLR-3853) Solr Replication does not delete temp index folder in case of broken master index

[Robert Benak (JIRA)]

Robert Benak created SOLR-3853:
--

 Summary: Solr Replication does not delete temp index folder in 
case of broken master index
 Key: SOLR-3853
 URL: https://issues.apache.org/jira/browse/SOLR-3853
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 3.6.1
 Environment: 2 CentOS Linux Servers
Reporter: Robert Benak
Priority: Minor


We have a master/slave solr setup. We did some fail over tests with solr 
regarding replication. We corrupted the master index ( we deleted files ) 
during runtime. During the next replication of the slave it trasfered the 
broken index from the master server and during that we got an fileNotFound 
Exception which stopped the replication. So the slave index was not overwritted 
and still working. But there is still a temp folder on the disk ( like 
/data/index.xx/ ). This happened after every replication until the 
disk was full. So a lot of temp folders was created.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3425) CloudSolrServer can't create cores when using the zkHost based constructor

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili commented on SOLR-3425:
---

I had a simple patch for making this work, however I'm not too sure what we 
need to do here (it made sense before but with the new Collections API it may 
be not that urgent).
Maybe we can defer this and get advantage of SOLR-3488 as soon as that's 
finished.


> CloudSolrServer can't create cores when using the zkHost based constructor
> --
>
> Key: SOLR-3425
> URL: https://issues.apache.org/jira/browse/SOLR-3425
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Tommaso Teofili
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.0, 5.0
>
> Attachments: SOLR-3425-test.patch
>
>
> When programmatically creating cores with a running SolrCloud instance the 
> CloudSolrServer uses the slices nodes information to feed the underlying 
> LBHttpSolrServer so it fails to create cores as there aren't any slices for 
> any new collection (as it's still to be created).
> This happens when using the CloudSolrServer constructor which takes the ZK 
> host as only parameter while it can be avoided by using the constructor which 
> also takes the list of Solr URLs and the underlying LBHttpSolrServer is 
> actually used for making the core creation request.
> However it'd be good to use the ZK host live nodes information to 
> automatically issue a core creation command on one of the underlying Solr 
> hosts without having to specify the full list of URLs beforehand.
> The scenario is when one wants to create a collection with N shards so the 
> client sends N core creation requests for the same collection thus the 
> SolrCloud stuff should just take care of choosing the host where to issue the 
> core creation request and update the cluster state.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (SOLR-3852) Admin UI - Cloud Tree with HTTP-Status 500 and an ArrayIndexOutOfBoundsException when using external ZK

[Vadim Kisselmann (JIRA)]

Vadim Kisselmann created SOLR-3852:
--

 Summary: Admin UI - Cloud Tree with HTTP-Status 500 and an 
ArrayIndexOutOfBoundsException when using external ZK
 Key: SOLR-3852
 URL: https://issues.apache.org/jira/browse/SOLR-3852
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0-BETA
 Environment: Tomcat 6, external zookeeper-3.3.5 
Reporter: Vadim Kisselmann


It works with embedded ZK.
But when we use an external ZK(3.3.5), and this ZK has another nodes like 
(hbase, broker, etc. and child-nodes with not specified formats) we get this 
Error in Admin UI in the "Cloud-Tree" View: Loading of undefined failed with 
HTTP-Status 500 .
Important(!): The cluster still works. Our external ZK see the Solr Servers 
(live-nodes) and has the solr config files from initial import. All the nodes 
like collections, configs, overseer-elect are here.
Only the Admin UI has a problem to show the "Cloud-Tree". Cloud-Graph works!

Catalina-LogFiles are free from Error messages, i have only this stack trace 
from Firebug:

Apache Tomcat/6.0.28 - Error report 
HTTP Status 500 - type Exception reportmessage 
description The server encountered an internal error () 
that prevented it from fulfilling this request.exception 
java.lang.ArrayIndexOutOfBoundsException
note The full stack trace of the root cause is available 
in the Apache Tomcat/6.0.28 logs.Apache Tomcat/6.0.28

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-861) SOLRJ Client does not release connections 'nicely' by default

[Sami Siren (JIRA)]

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

Sami Siren resolved SOLR-861.
-

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

I have not heard back anything that suggests that the shutdown() does not do 
it's job. resolving this one as fixed (the work was done in SOLR-2020, 
SOLR-3532).

> SOLRJ Client does not release connections 'nicely' by default
> -
>
> Key: SOLR-861
> URL: https://issues.apache.org/jira/browse/SOLR-861
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 1.3
> Environment: linux
>Reporter: Ian Holsman
>Assignee: Sami Siren
> Fix For: 4.0-BETA
>
> Attachments: SimpleClient.patch
>
>
> as-is the SolrJ Commons HttpServer uses the multi-threaded http connection 
> manager. This manager seems to keep the connection alive for the client and 
> does not close it when the object is dereferenced.
> When you keep on opening new CommonsHttpSolrServer instances it results in a 
> socket that is stuck in the CLOSE_WAIT state. Eventually this will use up all 
> your available file handles, causing your client to die a painful death.
> The solution I propose is that it uses a 'Simple' HttpConnectionManager which 
> is set to not reuse connections if you don't specify a HttpClient.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4407) XML-forbidden unicode characters break XML test reports

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-4407:
-

This is tricky to fix, actually. I patched the serializer and tests pass in rr 
2.0.1. I've pushed the release, will upgrade Lucene soon.

> XML-forbidden unicode characters break XML test reports
> ---
>
> Key: LUCENE-4407
> URL: https://issues.apache.org/jira/browse/LUCENE-4407
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Dawid Weiss
>
> Disallowed by spec. XML unicode characters (in Strings) produce invalid XML 
> reports which then fail on jenkins.
> I think this would also be the case with regular ant/maven runners but I 
> didn't check. It'd be interesting to see if they cater for this somehow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Assigned] (LUCENE-4407) XML-forbidden unicode characters break XML test reports

[Dawid Weiss (JIRA)]

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

Dawid Weiss reassigned LUCENE-4407:
---

Assignee: Dawid Weiss

> XML-forbidden unicode characters break XML test reports
> ---
>
> Key: LUCENE-4407
> URL: https://issues.apache.org/jira/browse/LUCENE-4407
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>
> Disallowed by spec. XML unicode characters (in Strings) produce invalid XML 
> reports which then fail on jenkins.
> I think this would also be the case with regular ant/maven runners but I 
> didn't check. It'd be interesting to see if they cater for this somehow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4407) XML-forbidden unicode characters break XML test reports

[Dawid Weiss (JIRA)]

Dawid Weiss created LUCENE-4407:
---

 Summary: XML-forbidden unicode characters break XML test reports
 Key: LUCENE-4407
 URL: https://issues.apache.org/jira/browse/LUCENE-4407
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/test
Reporter: Dawid Weiss


Disallowed by spec. XML unicode characters (in Strings) produce invalid XML 
reports which then fail on jenkins.

I think this would also be the case with regular ant/maven runners but I didn't 
check. It'd be interesting to see if they cater for this somehow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4406) Print out where tests failed at the end of running the Test Suite

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-4406:
-

I've worked on the release today anyway to fix the problematic non-allowed XML 
characters in reports so I added this as well. It looks pretty much like this 
(the number of failures to show is configurable):

{code}
[junit4:junit4]
[junit4:junit4] Tests with failures (first 2 out of 6):
[junit4:junit4]   - com.carrotsearch.ant.tasks.junit4.tests.TestStatuses.failure
[junit4:junit4]   - com.carrotsearch.ant.tasks.junit4.tests.TestStatuses.error
{code}

I didn't include the throwable's message like Maven does because it really 
doesn't make sense here -- if you care about a failure you'll need the stack 
(and possibly sysouts) too so you'll have to locate it anyway. Btw. remember 
that all failures are also marked with a "<<<" so grepping for this in context 
may also provide a nice shortcut to locate the full failure string.

> Print out where tests failed at the end of running the Test Suite
> -
>
> Key: LUCENE-4406
> URL: https://issues.apache.org/jira/browse/LUCENE-4406
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Grant Ingersoll
>Priority: Minor
>
> It would be nice if, at the end of running ant test, it spit out the names of 
> which tests failed so that one doesn't have to go scrolling up through the 
> output or go run grep on the test-reports as a separate step.
> For another project, I use:
> {code}
> 
> Looking for summaries in: ${build.dir}/test-reports with basedir: 
> ${basedir}
> Errors:
> 
> 
> 
> 
> 
> 
> Failures:
> 
> 
> 
> 
> 
> 
>   
> {code} 
> which can likely be modified for Lucene.  I can do it, but wanted to see if 
> others had an opinion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Assigned] (LUCENE-4406) Print out where tests failed at the end of running the Test Suite

[Dawid Weiss (JIRA)]

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

Dawid Weiss reassigned LUCENE-4406:
---

Assignee: Dawid Weiss

> Print out where tests failed at the end of running the Test Suite
> -
>
> Key: LUCENE-4406
> URL: https://issues.apache.org/jira/browse/LUCENE-4406
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/test
>Reporter: Grant Ingersoll
>Assignee: Dawid Weiss
>Priority: Minor
>
> It would be nice if, at the end of running ant test, it spit out the names of 
> which tests failed so that one doesn't have to go scrolling up through the 
> output or go run grep on the test-reports as a separate step.
> For another project, I use:
> {code}
> 
> Looking for summaries in: ${build.dir}/test-reports with basedir: 
> ${basedir}
> Errors:
> 
> 
> 
> 
> 
> 
> Failures:
> 
> 
> 
> 
> 
> 
>   
> {code} 
> which can likely be modified for Lucene.  I can do it, but wanted to see if 
> others had an opinion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3237) OverseerTest failure (non-reproducible)

[Sami Siren (JIRA)]

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

Sami Siren resolved SOLR-3237.
--

Resolution: Cannot Reproduce

I haven't seen this occur in a while, there was one failure with the same 
method recently but it was not related to this. closing.

> OverseerTest failure (non-reproducible)
> ---
>
> Key: SOLR-3237
> URL: https://issues.apache.org/jira/browse/SOLR-3237
> Project: Solr
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Sami Siren
>Priority: Minor
> Fix For: 4.1
>
>
> Nighly log harvest. Couldn't reproduce, unfortunately.
> {noformat}
> build 13-Mar-2012 06:08:43[junit] Testsuite: 
> org.apache.solr.cloud.OverseerTest
> build 13-Mar-2012 06:08:43[junit] Testcase: 
> testShardLeaderChange(org.apache.solr.cloud.OverseerTest):FAILED
> build 13-Mar-2012 06:08:43[junit] Unexpected shard leader 
> coll:collection1 shard:shard1 expected: but was:
> build 13-Mar-2012 06:08:43[junit] 
> junit.framework.AssertionFailedError: Unexpected shard leader 
> coll:collection1 shard:shard1 expected: but was:
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:549)
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:711)
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729)
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645)
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556)
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
> build 13-Mar-2012 06:08:43[junit] at 
> org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
> build 13-Mar-2012 06:08:43[junit] 
> build 13-Mar-2012 06:08:43[junit] 
> build 13-Mar-2012 06:08:43[junit] Tests run: 7, Failures: 1, Errors: 
> 0, Time elapsed: 74.666 sec
> build 13-Mar-2012 06:08:43[junit] 
> build 13-Mar-2012 06:08:43[junit] - Standard Error 
> -
> build 13-Mar-2012 06:08:43[junit] NOTE: reproduce with: ant test 
> -Dtestcase=OverseerTest -Dtestmethod=testShardLeaderChange 
> -Dtests.seed=48c9960216b3d5d:6c1600de0df53cdd:69c37083161d807d 
> -Dargs="-Dfile.encoding=UTF-8"
> build 13-Mar-2012 06:08:43[junit] WARNING: test class left thread 
> running: Session Sets (4):
> build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:45 MST 
> 2012:
> build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:48 MST 
> 2012:
> build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:51 MST 
> 2012:
> build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:54 MST 
> 2012:
> build 13-Mar-2012 06:08:43[junit] 
> build 13-Mar-2012 06:08:43[junit] RESOURCE LEAK: test class left 1 
> thread(s) running
> build 13-Mar-2012 06:08:43[junit] NOTE: test params are: 
> codec=Lucene40: {}, sim=DefaultSimilarity, locale=zh_TW, 
> timezone=Mexico/BajaSur
> build 13-Mar-2012 06:08:43[junit] NOTE: all tests run in this JVM:
> build 13-Mar-2012 06:08:43[junit] [BasicFunctionalityTest, 
> SolrI

[jira] [Commented] (SOLR-3354) LeaderElectionIntegrationTest

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-3354:
---

I don't think I've seen this one recently. I'll close.

> LeaderElectionIntegrationTest
> -
>
> Key: SOLR-3354
> URL: https://issues.apache.org/jira/browse/SOLR-3354
> Project: Solr
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Sami Siren
>Priority: Minor
>  Labels: not_reproducible
> Fix For: 4.1
>
>
> From my build server.
> {noformat}
> 12-Apr-2012 02:29:21  [junit] Testcase: 
> testSimpleSliceLeaderElection(org.apache.solr.cloud.LeaderElectionIntegrationTest):
> FAILED
> 12-Apr-2012 02:29:21  [junit] We didn't find a new leader! 7004 was 
> shutdown, but it's still showing as the leader
> 12-Apr-2012 02:29:21  [junit] junit.framework.AssertionFailedError: We 
> didn't find a new leader! 7004 was shutdown, but it's still showing as the 
> leader
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.Assert.fail(Assert.java:93)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.solr.cloud.LeaderElectionIntegrationTest.testSimpleSliceLeaderElection(LeaderElectionIntegrationTest.java:174)
> 12-Apr-2012 02:29:21  [junit] at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 12-Apr-2012 02:29:21  [junit] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 12-Apr-2012 02:29:21  [junit] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 12-Apr-2012 02:29:21  [junit] at 
> java.lang.reflect.Method.invoke(Method.java:597)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.rules.RunRules.evaluate(RunRules.java:18)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.intern

[jira] [Resolved] (SOLR-3354) LeaderElectionIntegrationTest

[Dawid Weiss (JIRA)]

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

Dawid Weiss resolved SOLR-3354.
---

Resolution: Cannot Reproduce

> LeaderElectionIntegrationTest
> -
>
> Key: SOLR-3354
> URL: https://issues.apache.org/jira/browse/SOLR-3354
> Project: Solr
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Sami Siren
>Priority: Minor
>  Labels: not_reproducible
> Fix For: 4.1
>
>
> From my build server.
> {noformat}
> 12-Apr-2012 02:29:21  [junit] Testcase: 
> testSimpleSliceLeaderElection(org.apache.solr.cloud.LeaderElectionIntegrationTest):
> FAILED
> 12-Apr-2012 02:29:21  [junit] We didn't find a new leader! 7004 was 
> shutdown, but it's still showing as the leader
> 12-Apr-2012 02:29:21  [junit] junit.framework.AssertionFailedError: We 
> didn't find a new leader! 7004 was shutdown, but it's still showing as the 
> leader
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.Assert.fail(Assert.java:93)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.solr.cloud.LeaderElectionIntegrationTest.testSimpleSliceLeaderElection(LeaderElectionIntegrationTest.java:174)
> 12-Apr-2012 02:29:21  [junit] at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 12-Apr-2012 02:29:21  [junit] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 12-Apr-2012 02:29:21  [junit] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 12-Apr-2012 02:29:21  [junit] at 
> java.lang.reflect.Method.invoke(Method.java:597)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.rules.RunRules.evaluate(RunRules.java:18)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> 12-Apr-2012 02:29:21 

[jira] [Commented] (SOLR-3354) LeaderElectionIntegrationTest

[Sami Siren (JIRA)]

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

Sami Siren commented on SOLR-3354:
--

Dawid are you still seeing this happen? There have been a number of bug fixes 
around the areas that might have caused this, the last failure I could find was 
from July 23th.

> LeaderElectionIntegrationTest
> -
>
> Key: SOLR-3354
> URL: https://issues.apache.org/jira/browse/SOLR-3354
> Project: Solr
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Sami Siren
>Priority: Minor
>  Labels: not_reproducible
> Fix For: 4.1
>
>
> From my build server.
> {noformat}
> 12-Apr-2012 02:29:21  [junit] Testcase: 
> testSimpleSliceLeaderElection(org.apache.solr.cloud.LeaderElectionIntegrationTest):
> FAILED
> 12-Apr-2012 02:29:21  [junit] We didn't find a new leader! 7004 was 
> shutdown, but it's still showing as the leader
> 12-Apr-2012 02:29:21  [junit] junit.framework.AssertionFailedError: We 
> didn't find a new leader! 7004 was shutdown, but it's still showing as the 
> leader
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.Assert.fail(Assert.java:93)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.solr.cloud.LeaderElectionIntegrationTest.testSimpleSliceLeaderElection(LeaderElectionIntegrationTest.java:174)
> 12-Apr-2012 02:29:21  [junit] at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 12-Apr-2012 02:29:21  [junit] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 12-Apr-2012 02:29:21  [junit] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 12-Apr-2012 02:29:21  [junit] at 
> java.lang.reflect.Method.invoke(Method.java:597)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.rules.RunRules.evaluate(RunRules.java:18)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
> 12-Apr-2012 02:29:21  [junit] at 
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> 12-Apr-2012 02:29:21  [junit] at 
> org.junit.ru

[jira] [Commented] (SOLR-3376) SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.

[Sami Siren (JIRA)]

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

Sami Siren commented on SOLR-3376:
--

I started a small cluster with preassigned ids a few times in a row and did not 
see anything strange. So I guess unless Erick chimes in it's safe to close this 
one.

> SolrCloud: Specifying shardId not working correctly, although the failures 
> are inconsistent.
> 
>
> Key: SOLR-3376
> URL: https://issues.apache.org/jira/browse/SOLR-3376
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Erick Erickson
>Assignee: Sami Siren
> Fix For: 4.0
>
>
> I'm seeing some odd results when specifying "shardId" parameter. I'm trying 
> the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
> dir   shardId start orderrunnng ZK   port
> example 1   1   y8983
> example22   2   y7574
> example31   3   y8900
> example42   4   y7500 
> And I'm waiting a bit between starting various examples to let ZK settle down.
> Once all of them are started, I was looking at 
> http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks 
> like (pretty cool IMO, especially since I didn't have to do it). The problem 
> was that shard 2 only reported a single instance, while shard1 showed the two 
> instances I was expecting. I'm running with 3 embedded ZK instances, just for 
> yucks. Interestingly the node that didn't show up was the only node that was 
> NOT running ZK.
> When I removed all the "shardId" parameters, nuked zoo_data from all 
> directories and just started them up (with numShards=2 on the bootstrap ZK 
> node), all 4 nodes showed up just fine.
> When starting with shardId specified and trying to go straight to the admin 
> interface on the node that wasn't showing up, I'd get odd errors like "This 
> interface requires that you activate the admin request handlers, add the 
> following configuration to your solrconfig.xml:". I also couldn't search 
> directly on that machine, "http://localhost:7574/solr/select?q=*:*"; returns a 
> 404 error.
> Command starting server that's giving me trouble: java -Xmx1G 
> -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 
> -DshardId=2 -jar start.jar
> Command for one that works fine:   java -Xmx1G 
> -Djetty.port=8900 -DzkRun 
> -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar 
> start.jar
> Sami Siren and he reports similar issues via e-mail conversation. Sami says 
> that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for 
> him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the 
> recent stuff with Ivy, I may have screwed up when/where the JARs were.
> So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which 
> seems highly suspicious to me. It was failing every time before with 3.3.4, 
> so it sounds like gremlins.
> And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the 
> ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other 
> directories)  and it works fine there too now. Sh. Mostly this is a 
> placeholder to insure we try this, I guarantee that sys admins will want to 
> assign specific machines to specific shards, so this'll get used.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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