date:20120919


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

Dawid Weiss commented on LUCENE-4397:
-

Did you run all these with the same seed?

 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

 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

Re: [JENKINS] Lucene-Solr-4.x-Linux (64bit/ibm-j9-jdk7) - Build # 1199 - Failure!

2012-09-19 Thread Dawid Weiss

I know what this is about: the throwable's message contains unicode
character out of XML spec's text range. XML serialization does not
check this and simply dumps unicode characters to the stream,
resulting in invalid XML.

 Throwable #1: junit.framework.AssertionFailedError: 
 .doc[a_si][0]:org.apache.lucene.document.Field:stored,indexed,tokenizeda_si:€�d!=org.apache.lucene.document.LazyDocument$LazyField:org.apache.lucene.document.LazyDocument$LazyField@4354a7b6

I have already fixed this in master on randomizedtesting. I'll make a
bugfix release today and push to Lucene once it propagates to Maven
central to avoid the issues from before.

Dawid

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

[jira] [Updated] (SOLR-3777) dataimporthandler interface does not send 'false' for unchecked checkboxes. Index is 'clean'ed every time


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

Stefan Matheis (steffkes) updated SOLR-3777:


Attachment: SOLR-3777.patch

updated patch, same functionality using lucene codestyle

 dataimporthandler interface does not send 'false' for unchecked checkboxes.  
 Index is 'clean'ed every time
 --

 Key: SOLR-3777
 URL: https://issues.apache.org/jira/browse/SOLR-3777
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler, web gui
Affects Versions: 4.0-BETA
Reporter: Glenn MacStravic
Assignee: Stefan Matheis (steffkes)
Priority: Minor
 Fix For: 4.0

 Attachments: SOLR-3777.patch, SOLR-3777.patch


 The checkboxes for 'verbose', 'clean', 'optimize', 'commit' are only sent as 
 arguments when checked.  Clearing the checkbox has no effect, so unintended 
 operations are conducted.

--
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-3788) core creation UI screen should redirect browser to details about newly created core


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

Stefan Matheis (steffkes) updated SOLR-3788:


Attachment: SOLR-3788.patch

how about this one?

 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] [Resolved] (SOLR-3777) dataimporthandler interface does not send 'false' for unchecked checkboxes. Index is 'clean'ed every time


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

Stefan Matheis (steffkes) resolved SOLR-3777.
-

Resolution: Fixed

Committed revision 1387467. trunk
Committed revision 1387468. branch_4x

 dataimporthandler interface does not send 'false' for unchecked checkboxes.  
 Index is 'clean'ed every time
 --

 Key: SOLR-3777
 URL: https://issues.apache.org/jira/browse/SOLR-3777
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler, web gui
Affects Versions: 4.0-BETA
Reporter: Glenn MacStravic
Assignee: Stefan Matheis (steffkes)
Priority: Minor
 Fix For: 4.0

 Attachments: SOLR-3777.patch, SOLR-3777.patch


 The checkboxes for 'verbose', 'clean', 'optimize', 'commit' are only sent as 
 arguments when checked.  Clearing the checkbox has no effect, so unintended 
 operations are conducted.

--
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-3851) create a new core/delete an existing core should also update the main/left list of cores

Stefan Matheis (steffkes) created SOLR-3851:
---

 Summary: create a new core/delete an existing core should also 
update the main/left list of cores
 Key: SOLR-3851
 URL: https://issues.apache.org/jira/browse/SOLR-3851
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Affects Versions: 4.0-BETA
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
 Fix For: 4.0


While working on SOLR-3788, i realized that the main/left list of cores 
needs/should also be updated when a new core is created / an existing core is 
deleted, which is right now not the fact.

On a first quick look that should not be that hard, hopefully we can reuse 
existing functionality from app.js, which already generates a list of cores 
when the UI is initialized.

--
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-3376) SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.

[
https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

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


[ 
https://issues.apache.org/jira/browse/SOLR-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
 12-Apr-2012 02:29:21

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


 [ 
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  [junit] at

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


[ 
https://issues.apache.org/jira/browse/SOLR-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 12-Apr-2012 02:29:21

[jira] [Resolved] (SOLR-3237) OverseerTest failure (non-reproducible)


 [ 
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:core4 but was:null
 build 13-Mar-2012 06:08:43[junit] 
 junit.framework.AssertionFailedError: Unexpected shard leader 
 coll:collection1 shard:shard1 expected:core4 but was:null
 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, 
 SolrInfoMBeanTest, SnowballPorterFilterFactoryTest,

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


 [ 
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}
 target name=test-summary
 echoLooking for summaries in: ${build.dir}/test-reports with basedir: 
 ${basedir}/echo
 echoErrors:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=errors=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
 echoFailures:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=failures=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
   /target
 {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


[ 
https://issues.apache.org/jira/browse/LUCENE-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
 target name=test-summary
 echoLooking for summaries in: ${build.dir}/test-reports with basedir: 
 ${basedir}/echo
 echoErrors:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=errors=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
 echoFailures:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=failures=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
   /target
 {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] [Created] (LUCENE-4407) XML-forbidden unicode characters break XML test reports

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] [Assigned] (LUCENE-4407) XML-forbidden unicode characters break XML test reports


 [ 
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] [Commented] (LUCENE-4407) XML-forbidden unicode characters break XML test reports


[ 
https://issues.apache.org/jira/browse/LUCENE-4407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Resolved] (SOLR-861) SOLRJ Client does not release connections 'nicely' by default

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

-
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

2012-09-19 Thread 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:

htmlheadtitleApache Tomcat/6.0.28 - Error report/titlestyle!--H1 
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
 H2 
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
 H3 
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
 BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} 
B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P 
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
 {color : black;}A.name {color : black;}HR {color : #525D76;}--/style 
/headbodyh1HTTP Status 500 - /h1HR size=1 
noshade=noshadepbtype/b Exception report/ppbmessage/b 
u/u/ppbdescription/b uThe server encountered an internal error () 
that prevented it from fulfilling this request./u/ppbexception/b 
prejava.lang.ArrayIndexOutOfBoundsException
/pre/ppbnote/b uThe full stack trace of the root cause is available 
in the Apache Tomcat/6.0.28 logs./u/pHR size=1 
noshade=noshadeh3Apache Tomcat/6.0.28/h3/body/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] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor

2012-09-19 Thread Tommaso Teofili (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-3853) Solr Replication does not delete temp index folder in case of broken master index

2012-09-19 Thread 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-3788) core creation UI screen should redirect browser to details about newly created core

2012-09-19 Thread Erick Erickson (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (SOLR-3788) core creation UI screen should redirect browser to details about newly created core


[ 
https://issues.apache.org/jira/browse/SOLR-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Updated] (LUCENE-4397) TestIndexWriterWithThreads.testRollbackAndCommitWithThreads is sometimes very very slow


 [ 
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] [Resolved] (SOLR-3376) SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.

2012-09-19 Thread 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

-
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

2012-09-19 Thread Shai Erera (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
 [junit]   at

[jira] [Commented] (SOLR-3788) core creation UI screen should redirect browser to details about newly created core

2012-09-19 Thread Erick Erickson (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 G...

 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] [Updated] (LUCENE-3842) Analyzing Suggester


 [ 
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 PairOutputsweight,output, 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] (LUCENE-4402) TestAddTaxonomy.testConcurrency failure


[ 
https://issues.apache.org/jira/browse/LUCENE-4402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:74)
 [junit]

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


 [ 
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] [Resolved] (LUCENE-4402) TestAddTaxonomy.testConcurrency failure

2012-09-19 Thread 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(ParentRunner.java:50)
 [junit]   at

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


 [ 
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-4397) TestIndexWriterWithThreads.testRollbackAndCommitWithThreads is sometimes very very slow


 [ 
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-4399) Rename AppendingCodec to Appending40Codec


 [ 
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] [Commented] (LUCENE-4399) Rename AppendingCodec to Appending40Codec


[ 
https://issues.apache.org/jira/browse/LUCENE-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (LUCENE-4399) Rename AppendingCodec to Appending40Codec


[ 
https://issues.apache.org/jira/browse/LUCENE-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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


[ 
https://issues.apache.org/jira/browse/LUCENE-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Created] (SOLR-3854) SolrCloud does not work with https

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] [Updated] (SOLR-3854) SolrCloud does not work with https


 [ 
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] [Updated] (LUCENE-4399) Rename AppendingCodec to Appending40Codec


 [ 
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] [Resolved] (LUCENE-4406) Print out where tests failed at the end of running the Test Suite


 [ 
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}
 target name=test-summary
 echoLooking for summaries in: ${build.dir}/test-reports with basedir: 
 ${basedir}/echo
 echoErrors:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=errors=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
 echoFailures:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=failures=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
   /target
 {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] (LUCENE-4407) XML-forbidden unicode characters break XML test reports


 [ 
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] [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.

2012-09-19 Thread Markus Jelsma (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.

-
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

[
https://issues.apache.org/jira/browse/LUCENE-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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).

-
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

[
https://issues.apache.org/jira/browse/LUCENE-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

-
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


[ 
https://issues.apache.org/jira/browse/LUCENE-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-4406) Print out where tests failed at the end of running the Test Suite


[ 
https://issues.apache.org/jira/browse/LUCENE-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
 target name=test-summary
 echoLooking for summaries in: ${build.dir}/test-reports with basedir: 
 ${basedir}/echo
 echoErrors:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=errors=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
 echoFailures:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=failures=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
   /target
 {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!

2012-09-19 Thread 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

2012-09-19 Thread Uwe Schindler (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
 target name=test-summary
 echoLooking for summaries in: ${build.dir}/test-reports with basedir: 
 ${basedir}/echo
 echoErrors:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=errors=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
 echoFailures:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=failures=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
   /target
 {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

2012-09-19 Thread 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 dynamicField name=*_geo type=location_rpt 
multiValued=true  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 indexquery 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) dsmi...@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


[ 
https://issues.apache.org/jira/browse/LUCENE-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
 target name=test-summary
 echoLooking for summaries in: ${build.dir}/test-reports with basedir: 
 ${basedir}/echo
 echoErrors:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=errors=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
 echoFailures:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=failures=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
   /target
 {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


[ 
https://issues.apache.org/jira/browse/LUCENE-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
 target name=test-summary
 echoLooking for summaries in: ${build.dir}/test-reports with basedir: 
 ${basedir}/echo
 echoErrors:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=errors=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
 echoFailures:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=failures=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
   /target
 {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


[ 
https://issues.apache.org/jira/browse/LUCENE-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
 target name=test-summary
 echoLooking for summaries in: ${build.dir}/test-reports with basedir: 
 ${basedir}/echo
 echoErrors:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=errors=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
 echoFailures:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=failures=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
   /target
 {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] [Created] (LUCENE-4408) license check fails if you previously built maven release artifacts

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-4408) license check fails if you previously built maven release artifacts


[ 
https://issues.apache.org/jira/browse/LUCENE-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 @@
 exclude name=example/start.jar /
 exclude name=example/exampledocs/post.jar /
 exclude name=example/solr-webapp/** /
+exclude name=package/**/
   /additional-excludes
   additional-filters
 replaceregex pattern=jetty([^/]+)$ replace=jetty flags=gi /
{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] [Resolved] (LUCENE-4408) license check fails if you previously built maven release artifacts


 [ 
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

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

2012-09-19 Thread 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 G

On Wed, Sep 19, 2012 at 10:20 AM, Dawid Weiss (JIRA) j...@apache.org wrote:

 [ 
 https://issues.apache.org/jira/browse/LUCENE-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
 target name=test-summary
 echoLooking for summaries in: ${build.dir}/test-reports with basedir: 
 ${basedir}/echo
 echoErrors:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=errors=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
 echoFailures:/echo
 exec executable=grep
 arg value=-r/
 arg value=-rl/
 arg value=failures=\quot;[1-9]\quot;/
 arg value=${build.dir}/test-reports/
 /exec
   /target
 {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

Re: jar error while trying to build

2012-09-19 Thread 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 va...@apache.org 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
 ...

[jira] [Created] (SOLR-3855) DocValues support

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

[jira] [Commented] (SOLR-3855) DocValues support


[ 
https://issues.apache.org/jira/browse/SOLR-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-3856) DIH: Better tests for SqlEntityProcessor

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] [Updated] (SOLR-3856) DIH: Better tests for SqlEntityProcessor

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

-
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 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}
entity name=y query=select * from y where xid=${x.id} 
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

[jira] [Commented] (SOLR-3852) Admin UI - Cloud Tree with HTTP-Status 500 and an ArrayIndexOutOfBoundsException when using external ZK


[ 
https://issues.apache.org/jira/browse/SOLR-3852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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:
 htmlheadtitleApache Tomcat/6.0.28 - Error report/titlestyle!--H1 
 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
  H2 
 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
  H3 
 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
  BODY 
 {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B 
 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P 
 {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
  {color : black;}A.name {color : black;}HR {color : #525D76;}--/style 
 /headbodyh1HTTP Status 500 - /h1HR size=1 
 noshade=noshadepbtype/b Exception report/ppbmessage/b 
 u/u/ppbdescription/b uThe server encountered an internal error 
 () that prevented it from fulfilling this request./u/ppbexception/b 
 prejava.lang.ArrayIndexOutOfBoundsException
 /pre/ppbnote/b uThe full stack trace of the root cause is 
 available in the Apache Tomcat/6.0.28 logs./u/pHR size=1 
 noshade=noshadeh3Apache Tomcat/6.0.28/h3/body/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] [Updated] (SOLR-3850) DIH: parameter cacheKey was inadvertently renamed cachePk


 [ 
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 entity ... where='id=x.id' / , users can use entity 
 ... 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

2012-09-19 Thread Mark Miller (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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:
 htmlheadtitleApache Tomcat/6.0.28 - Error report/titlestyle!--H1 
 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
  H2 
 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
  H3 
 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
  BODY 
 {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B 
 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P 
 {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
  {color : black;}A.name {color : black;}HR {color : #525D76;}--/style 
 /headbodyh1HTTP Status 500 - /h1HR size=1 
 noshade=noshadepbtype/b Exception report/ppbmessage/b 
 u/u/ppbdescription/b uThe server encountered an internal error 
 () that prevented it from fulfilling this request./u/ppbexception/b 
 prejava.lang.ArrayIndexOutOfBoundsException
 /pre/ppbnote/b uThe full stack trace of the root cause is 
 available in the Apache Tomcat/6.0.28 logs./u/pHR size=1 
 noshade=noshadeh3Apache Tomcat/6.0.28/h3/body/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] [Resolved] (LUCENE-4398) Memory Leak in TermsHashPerField memory tracking


 [ 
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

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

2012-09-19 Thread Adrien Grand

Hi Jack,

On Tue, Sep 18, 2012 at 10:43 PM, Jack Krupansky
j...@basetechnology.com 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

Re: jar error while trying to build

2012-09-19 Thread Andi Vajda


On Sep 19, 2012, at 8:20, Mohamed Lrhazi ml...@georgetown.edu 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 va...@apache.org 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
 ...

[jira] [Commented] (LUCENE-1167) add compatibility statement to README.txt for all contribs


[ 
https://issues.apache.org/jira/browse/LUCENE-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

[jira] [Resolved] (LUCENE-1307) Remove Contributions page


 [ 
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
  otis_gospodne...@yahoo.com 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] [Resolved] (SOLR-3850) DIH: parameter cacheKey was inadvertently renamed cachePk


 [ 
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 entity ... where='id=x.id' / , users can use entity 
 ... 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

SpanNearQuery distance issue

2012-09-19 Thread 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] [Commented] (LUCENE-1560) maxDocBytesToAnalyze should be required arg up front


[ 
https://issues.apache.org/jira/browse/LUCENE-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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(lastEndOffsetmaxDocBytesToAnalyze)
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] [Comment Edited] (LUCENE-1560) maxDocBytesToAnalyze should be required arg up front


[ 
https://issues.apache.org/jira/browse/LUCENE-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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(lastEndOffsetmaxDocBytesToAnalyze)
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(lastEndOffsetmaxDocBytesToAnalyze)
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-1597) New Document and Field API


[ 
https://issues.apache.org/jira/browse/LUCENE-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

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

2012-09-19 Thread 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/PythonMultiFieldQueryParser

 Traceback (most recent call last):
   File

[jira] [Commented] (LUCENE-1689) supplementary character handling

[
https://issues.apache.org/jira/browse/LUCENE-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.

-
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


 [ 
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] [Updated] (LUCENE-4404) Add ListOfOutputs FST Outputs, replacing UpToTwoPositiveIntOutputs

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

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

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

2012-09-19 Thread Yonik Seeley (JIRA)


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

Yonik Seeley commented on SOLR-3815:


Committed fix to preserve shard properties:
trunk: http://svn.apache.org/viewvc?rev=1387747view=rev
4x: http://svn.apache.org/viewvc?rev=1387749view=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] (SOLR-3087) XInclude not working on schema.xml


 [ 
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.init(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 -
 ?xml version=1.0 encoding=UTF-8 ?
 schema name=default version=1.1
   types
  !-- Stuff --
  xi:include href=schema_integration.xml 
 xmlns:xi=http://www.w3.org/2001/XInclude/
   /types
   !-- Stuff --
 /schema
 schema_integration.xml -
 ?xml version=1.0 encoding=UTF-8 ?
 fieldType name=string2

Re: SpanNearQuery distance issue

2012-09-19 Thread 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] [Commented] (SOLR-3087) XInclude not working on schema.xml

2012-09-19 Thread Amit Nithian (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.init(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 -
 ?xml version=1.0 encoding=UTF-8 ?
 schema name=default version=1.1
   types
  !-- Stuff --
  xi:include href=schema_integration.xml 
 xmlns:xi=http://www.w3.org/2001/XInclude/
   /types
   !-- Stuff --
 /schema
 schema_integration.xml -
 ?xml version=1.0 encoding=UTF-8 ?
 fieldType name=string2 class=solr.StrField sortMissingLast=true 
 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] [Resolved] (SOLR-3087) XInclude not working on schema.xml


 [ 
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.init(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 -
 ?xml version=1.0 encoding=UTF-8 ?
 schema name=default version=1.1
   types
  !-- Stuff --
  xi:include href=schema_integration.xml 
 xmlns:xi=http://www.w3.org/2001/XInclude/
   /types
   !-- Stuff --
 /schema
 schema_integration.xml -
 ?xml version=1.0 encoding=UTF-8 ?
 fieldType name=string2 class=solr.StrField sortMissingLast=true 
 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] [Created] (SOLR-3858) Doc-to-shard assignment based on range property on shards

2012-09-19 Thread 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] [Created] (SOLR-3859) SolrCloud admin graph is showing leader as state recovery failed, but it's working

2012-09-19 Thread 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] [Reopened] (LUCENE-3747) Support Unicode 6.1.0


 [ 
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 
 {{*Impl3X}}; 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] [Updated] (LUCENE-3747) Support Unicode 6.1.0


 [ 
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 
 {{*Impl3X}}; 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

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

2012-09-19 Thread hudsonseviltwin

See http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/8125/

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

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

resolve:

init:

compile-lucene-core:

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

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

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: 
http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/build/memory/test
[junit4: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 = 
http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

resolve:

common.init:

compile-lucene-core:

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

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 = 
http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

resolve:

common.init:

compile-lucene-core:

init:

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

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

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 = 
http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

resolve:

init:

compile-lucene-core:

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

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

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: 
http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/build/misc/test
[junit4: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=http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/build
 -Dtests.codec=random -Dtests.postingsformat=random -Dtests.locale=random 
-Dtests.timezone=random -Dtests.directory=random 
-Dtests.linedocsfile=europarl.lines.txt.gz

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

2012-09-19 Thread 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,  hudsonsevilt...@gmail.com wrote:
 See http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/8125/

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

 ivy-availability-check:

 ivy-fail:

 ivy-configure:
 [ivy:configure] :: loading settings :: file = 
 http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

 resolve:

 init:

 compile-lucene-core:

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

 ivy-availability-check:

 ivy-fail:

 ivy-configure:
 [ivy:configure] :: loading settings :: file = 
 http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

 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: 
 http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/build/memory/test
 [junit4: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 = 
 http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

 resolve:

 common.init:

 compile-lucene-core:

 ivy-availability-check:

 ivy-fail:

 ivy-configure:
 [ivy:configure] :: loading settings :: file = 
 http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

 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 = 
 http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

 resolve:

 common.init:

 compile-lucene-core:

 init:

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

 ivy-availability-check:

 ivy-fail:

 ivy-configure:
 [ivy:configure] :: loading settings :: file = 
 http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

 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 = 
 http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

 resolve:

 init:

 compile-lucene-core:

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

 ivy-availability-check:

 ivy-fail:

 ivy-configure:
 [ivy:configure] :: loading settings :: file = 
 http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml

 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: 
 http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/build/misc/test
 [junit4: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=

Jenkins build is back to normal : Lucene-Core-4x-Beasting #8126

2012-09-19 Thread hudsonseviltwin

See http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/8126/


-
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


 [ 
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}
 lst name=error
   str name=tracejava.lang.NullPointerException/str
   int name=code500/int
 /lst
 {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] [Resolved] (SOLR-3783) Facet pivots produces NPE when facet.missing is turned on


 [ 
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}
 lst name=error
   str name=tracejava.lang.NullPointerException/str
   int name=code500/int
 /lst
 {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] [Resolved] (LUCENE-3747) Support Unicode 6.1.0


 [ 
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=1387813view=rev]
- branch_4x [r1387837|https://svn.apache.org/viewvc?rev=1387837view=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 
 {{*Impl3X}}; 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] (LUCENE-4409) implement javadocs linting with eclipse ecj compiler