date:20121212

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

Shai Erera updated LUCENE-4610:
---

Attachment: LUCENE-4610.patch

Patch implements NoParentsAggregator and a matching test. Note the nocommits -
the aggregator still does not dedup parents as it counts them. I wonder what's
the best way to do it, i.e. a FixedBitSet, an IntHashSet or something else. If
you have any insights, please share !

Implement a NoParentsAccumulator

Key: LUCENE-4610
URL: https://issues.apache.org/jira/browse/LUCENE-4610
Project: Lucene - Core
Issue Type: New Feature
Components: modules/facet
Reporter: Shai Erera
Attachments: LUCENE-4610.patch

Mike experimented with encoding just the exact categories ordinals on
LUCENE-4602, and I added OrdinalPolicy.NO_PARENTS, with a comment saying that
this requires a special FacetsAccumulator.
The idea is to write the exact categories only for each document, and then at
search time count up the parents chain to compute requested facets (I say
count, but it can be any weight).
One limitation of such accumulator is that it cannot be used when e.g. a
document is associated with two categories who share the same parent, because
that may result in incorrect weights computed (e.g. a document might have
several Authors, and so counting the Author facet may yield wrong counts). So
it can be used only when the app knows it doesn't add such facets, or that it
always asks to aggregate a 'root' that in its path this criteria doesn't hold
(no categories share the same parent).

--
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: svn commit: r1420580 - /lucene/dev/trunk/build.xml

2012-12-12 Thread Uwe Schindler

Hi,

I committed the reorder of the checks. The dependency validation task fails in 
Solr:

[licenses] MISSING sha1 checksum file for: C:\Users\Uwe 
Schindler\.m2\repository\org\jboss\netty\netty\3.2.2.Final\netty-3.2.2.Fina
l.jar
 [licenses] Scanned 30 JAR file(s) for licenses (in 0.27s.), 1 error(s).

So it looks like Maven-ANT-build adds an extra dependency to Solr that is not 
used in the conventional-ANT-build (trunk). I have no idea how to fix this.

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


 -Original Message-
 From: uschind...@apache.org [mailto:uschind...@apache.org]
 Sent: Wednesday, December 12, 2012 10:20 AM
 To: comm...@lucene.apache.org
 Subject: svn commit: r1420580 - /lucene/dev/trunk/build.xml
 
 Author: uschindler
 Date: Wed Dec 12 09:19:55 2012
 New Revision: 1420580
 
 URL: http://svn.apache.org/viewvc?rev=1420580view=rev
 Log:
 change order of jenkins-maven job
 
 Modified:
 lucene/dev/trunk/build.xml
 
 Modified: lucene/dev/trunk/build.xml
 URL:
 http://svn.apache.org/viewvc/lucene/dev/trunk/build.xml?rev=1420580r1
 =1420579r2=1420580view=diff
 ==
 
 --- lucene/dev/trunk/build.xml (original)
 +++ lucene/dev/trunk/build.xml Wed Dec 12 09:19:55 2012
 @@ -368,7 +368,7 @@
!-- Jenkins tasks --
target name=jenkins-hourly depends=clean,test-with-
 heapdumps,validate,documentation-lint,jar-checksums,check-svn-working-
 copy/
 
 -  target name=jenkins-maven-nightly depends=clean,remove-maven-
 artifacts,generate-maven-artifacts,run-maven-build,validate-maven-
 dependencies/
 +  target name=jenkins-maven-nightly
 + depends=clean,remove-maven-artifacts,generate-maven-artifacts,validat
 + e-maven-dependencies,run-maven-build/
 
target name=jenkins-clover depends=run-clover/  /project



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

[jira] [Commented] (SOLR-4114) Collection API: Allow multiple shards from one collection on the same Solr server

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

Per Steffensen commented on SOLR-4114:
--

bq. Great patch! I just had to make a couple small tweaks to make the policeman
happy - added license files for the test jars, changed the new test to extend
LuceneTestCase. Good stuff found by the long but useful precommit ant target.

Yes, I do not do precommit test before sending a patch. Of course I will do
before committing myself if/when I become committer.

Just out of curiosity, why do tests HAVE to extend LuceneTestCase?

bq. I think that covers all of your points Per - let me know

Checking only on branch_4x, hopeing that you did the exact same changes on
trunk. Updated my local checkout of branch_4x, made a check to see if
everything seemed to be there. It was. I am ready to close this ticket.

Collection API: Allow multiple shards from one collection on the same Solr
server
-

Key: SOLR-4114
URL: https://issues.apache.org/jira/browse/SOLR-4114
Project: Solr
Issue Type: New Feature
Components: multicore, SolrCloud
Affects Versions: 4.0
Environment: Solr 4.0.0 release
Reporter: Per Steffensen
Assignee: Mark Miller
Labels: collection-api, multicore, shard, shard-allocation
Fix For: 4.1, 5.0

Attachments:
SOLR-4114_mocking_OverseerCollectionProcessorTest_branch_4x.patch,
SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch,
SOLR-4114_trunk.patch

We should support running multiple shards from one collection on the same
Solr server - the run a collection with 8 shards on a 4 Solr server cluster
(each Solr server running 2 shards).
Performance tests at our side has shown that this is a good idea, and it is
also a good idea for easy elasticity later on - it is much easier to move an
entire existing shards from one Solr server to another one that just joined
the cluter than it is to split an exsiting shard among the Solr that used to
run it and the new Solr.
See dev mailing list discussion Multiple shards for one collection on the
same Solr server

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

[jira] [Commented] (SOLR-4136) SolrCloud bugs when servlet context contains / or _


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

Per Steffensen commented on SOLR-4136:
--

Can confirm that Marks patch for OverseerCollectionProcessorTest seems to be 
good. In a mocked test you mock components used by the class under test 
(OverseerCollectionProcessor in this case) and basically tells those mocks how 
to behave when used by the class under test. This way you test only the logic 
in the class under test and at the same time you get to verify that it 
communicates (calles stuff on) the components in interacts with (the mocked 
ones) in exactly the way you expect. I guess you have changed createCollection 
so that it also calls zkStateReaderMock.getZkClient().getBaseUrlForNodeName() 
which it didnt before, so that call wasnt expected by the test and you didnt 
tell the mocked component (ZkStateReader) how to simulate correct behaviour. 
Mark added this and the test should be fine again. 

Basically since you changed createCollection in a way so that it did not 
anylonger behave exactly as verified by the OverseerCollectionProcessorTest you 
needed to tweak the test also. This is a nice thing!

 SolrCloud bugs when servlet context contains / or _
 ---

 Key: SOLR-4136
 URL: https://issues.apache.org/jira/browse/SOLR-4136
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0
Reporter: Hoss Man
Assignee: Hoss Man
 Attachments: SOLR-4136.patch, SOLR-4136.patch, SOLR-4136.patch, 
 SOLR-4136.patch, SOLR-4136.patch


 SolrCloud does not work properly with non-trivial values for hostContext 
 (ie: the servlet context path).  In particular...
 * Using a hostContext containing a  / (ie: a servlet context with a subdir 
 path, semi-common among people who organize webapps hierarchically for lod 
 blanacer rules) is explicitly forbidden in ZkController because of how the 
 hostContext is used to build a ZK nodeName
 * Using a hostContext containing a \_ causes problems in 
 OverseerCollectionProcessor where it assumes all \_ characters should be 
 converted to / to reconstitute a URL from nodeName (NOTE: this code 
 specifically has a TODO to fix this, and then has a subsequent TODO about 
 assuming http://; labeled this sucks)

--
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-4114) Collection API: Allow multiple shards from one collection on the same Solr server


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

Per Steffensen commented on SOLR-4114:
--

bq. Feel free to give feedback in that issue - this was my first experience 
looking at easymock.

I added a comment on SOLR-4136, but basically you did a fine job!

Now that SOLR-4114 is closed would you mind continuing with SOLR-4120, Mark?

 Collection API: Allow multiple shards from one collection on the same Solr 
 server
 -

 Key: SOLR-4114
 URL: https://issues.apache.org/jira/browse/SOLR-4114
 Project: Solr
  Issue Type: New Feature
  Components: multicore, SolrCloud
Affects Versions: 4.0
 Environment: Solr 4.0.0 release
Reporter: Per Steffensen
Assignee: Mark Miller
  Labels: collection-api, multicore, shard, shard-allocation
 Fix For: 4.1, 5.0

 Attachments: 
 SOLR-4114_mocking_OverseerCollectionProcessorTest_branch_4x.patch, 
 SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, 
 SOLR-4114_trunk.patch


 We should support running multiple shards from one collection on the same 
 Solr server - the run a collection with 8 shards on a 4 Solr server cluster 
 (each Solr server running 2 shards).
 Performance tests at our side has shown that this is a good idea, and it is 
 also a good idea for easy elasticity later on - it is much easier to move an 
 entire existing shards from one Solr server to another one that just joined 
 the cluter than it is to split an exsiting shard among the Solr that used to 
 run it and the new Solr.
 See dev mailing list discussion Multiple shards for one collection on the 
 same Solr server

--
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-4114) Collection API: Allow multiple shards from one collection on the same Solr server


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

Per Steffensen resolved SOLR-4114.
--

Resolution: Fixed

 Collection API: Allow multiple shards from one collection on the same Solr 
 server
 -

 Key: SOLR-4114
 URL: https://issues.apache.org/jira/browse/SOLR-4114
 Project: Solr
  Issue Type: New Feature
  Components: multicore, SolrCloud
Affects Versions: 4.0
 Environment: Solr 4.0.0 release
Reporter: Per Steffensen
Assignee: Mark Miller
  Labels: collection-api, multicore, shard, shard-allocation
 Fix For: 4.1, 5.0

 Attachments: 
 SOLR-4114_mocking_OverseerCollectionProcessorTest_branch_4x.patch, 
 SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, 
 SOLR-4114_trunk.patch


 We should support running multiple shards from one collection on the same 
 Solr server - the run a collection with 8 shards on a 4 Solr server cluster 
 (each Solr server running 2 shards).
 Performance tests at our side has shown that this is a good idea, and it is 
 also a good idea for easy elasticity later on - it is much easier to move an 
 entire existing shards from one Solr server to another one that just joined 
 the cluter than it is to split an exsiting shard among the Solr that used to 
 run it and the new Solr.
 See dev mailing list discussion Multiple shards for one collection on the 
 same Solr server

--
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-4120) Collection API: Support for specifying a list of solrs to spread a new collection across


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

Per Steffensen commented on SOLR-4120:
--

I will find time soon to make you a trunk-based patch. Thanks, Mark!

In the meantime you could look at SOLR-4140 :-) I know I am pushing it now...

 Collection API: Support for specifying a list of solrs to spread a new 
 collection across
 

 Key: SOLR-4120
 URL: https://issues.apache.org/jira/browse/SOLR-4120
 Project: Solr
  Issue Type: New Feature
  Components: multicore, SolrCloud
Affects Versions: 4.0
Reporter: Per Steffensen
Assignee: Mark Miller
Priority: Minor
  Labels: collection-api, multicore, shard, shard-allocation
 Fix For: 4.1, 5.0

 Attachments: SOLR-4120.patch, SOLR-4120_trunk.patch


 When creating a new collection through the Collection API, the Overseer 
 (handling the creation) will spread shards for this new collection across all 
 live nodes.
 Sometimes you dont want a collection spread across all available nodes. Allow 
 for the create operation of the Collection API, to take a createNodeSet 
 parameter containing a list of Solr to spread the new shards across. If not 
 provided it will just spread across all available nodes (default).
 For an example of a concrete case of usage see: 
 https://issues.apache.org/jira/browse/SOLR-4114?focusedCommentId=13505506page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13505506

--
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-MAVEN] Lucene-Solr-Maven-4.x #181: POMs out of sync

2012-12-12 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/181/

No tests ran.

Build Log:
[...truncated 11359 lines...]



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

[jira] [Updated] (SOLR-4141) EDismax: Strange combination of subqueries with parentheses


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

Leonhard Maylein updated SOLR-4141:
---

Issue Type: Improvement  (was: Bug)

 EDismax: Strange combination of subqueries with parentheses
 ---

 Key: SOLR-4141
 URL: https://issues.apache.org/jira/browse/SOLR-4141
 Project: Solr
  Issue Type: Improvement
  Components: query parsers
Affects Versions: 4.0
Reporter: Leonhard Maylein

 fi = field name, mm=100% (all examples)
 The query 'fi:a fi:b'
 (parsed query: '(+((fi:a fi:b)~2))/no_coord')
 is interpreted as 'fi:a AND fi:b'
 This also applies to the queries '(fi:a fi:b)' respectively 
 'fi:(a b)'.
 But the query '(fi:a fi:b) (fi:a fi:b)'
 (parsed query: '(+(((fi:a fi:b) (fi:a fi:b))~2))/no_coord')
 shows the same result as 'fi:a OR fi:b'.
 I'm not sure but I think this is a bug, isn't it?
 If it's a intended behavior I think it is very difficult
 to explain this to a searcher.

--
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-4141) EDismax: Strange combination of subqueries with parentheses


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

Leonhard Maylein commented on SOLR-4141:


In combination with the WordDelimiterFilter setting of mm to 100%
is worthless even if you do not have explicit sub-queries because
of the implicit sub-queries for search terms splitted up by the
WordDelimiterFilter (camel case words, words with hyphens or
letters followed by a digit).

I have changed the Type of this issue from bug to improvement.

 EDismax: Strange combination of subqueries with parentheses
 ---

 Key: SOLR-4141
 URL: https://issues.apache.org/jira/browse/SOLR-4141
 Project: Solr
  Issue Type: Improvement
  Components: query parsers
Affects Versions: 4.0
Reporter: Leonhard Maylein

 fi = field name, mm=100% (all examples)
 The query 'fi:a fi:b'
 (parsed query: '(+((fi:a fi:b)~2))/no_coord')
 is interpreted as 'fi:a AND fi:b'
 This also applies to the queries '(fi:a fi:b)' respectively 
 'fi:(a b)'.
 But the query '(fi:a fi:b) (fi:a fi:b)'
 (parsed query: '(+(((fi:a fi:b) (fi:a fi:b))~2))/no_coord')
 shows the same result as 'fi:a OR fi:b'.
 I'm not sure but I think this is a bug, isn't it?
 If it's a intended behavior I think it is very difficult
 to explain this to a searcher.

--
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-4153) eDismax: Misinterpretation of hyphens


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

Leonhard Maylein updated SOLR-4153:
---

Issue Type: Improvement  (was: Bug)

 eDismax: Misinterpretation of hyphens
 -

 Key: SOLR-4153
 URL: https://issues.apache.org/jira/browse/SOLR-4153
 Project: Solr
  Issue Type: Improvement
  Components: query parsers
Affects Versions: 4.0
Reporter: Leonhard Maylein

 The eDismax parser treats hyphens as OR operator:
 q: 
   british history 1815-1914
 qf: 
   ti sw
 Parsed as:
 (+((DisjunctionMaxQuery((sw:british | ti:british)) 
 DisjunctionMaxQuery((sw:history | ti:history)) DisjunctionMaxQuery(((sw:1815 
 sw:1914) | (ti:1815 ti:1914~3))/no_coord
 What is the reason for this behavior? Wouldn't it be better
 to treat 'term1-term2' as a PhraseQuery term1 term2 (as the 
 WordDelimiterFilter does)?

--
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-4153) eDismax: Misinterpretation of hyphens


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

Leonhard Maylein commented on SOLR-4153:


This problem is related to SOLR-4141.

 eDismax: Misinterpretation of hyphens
 -

 Key: SOLR-4153
 URL: https://issues.apache.org/jira/browse/SOLR-4153
 Project: Solr
  Issue Type: Improvement
  Components: query parsers
Affects Versions: 4.0
Reporter: Leonhard Maylein

 The eDismax parser treats hyphens as OR operator:
 q: 
   british history 1815-1914
 qf: 
   ti sw
 Parsed as:
 (+((DisjunctionMaxQuery((sw:british | ti:british)) 
 DisjunctionMaxQuery((sw:history | ti:history)) DisjunctionMaxQuery(((sw:1815 
 sw:1914) | (ti:1815 ti:1914~3))/no_coord
 What is the reason for this behavior? Wouldn't it be better
 to treat 'term1-term2' as a PhraseQuery term1 term2 (as the 
 WordDelimiterFilter does)?

--
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-4160) eDismax should not split search terms between letters and digits


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

Leonhard Maylein commented on SOLR-4160:


This problem is related to SOLR-4141.

 eDismax should not split search terms between letters and digits
 

 Key: SOLR-4160
 URL: https://issues.apache.org/jira/browse/SOLR-4160
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.0
Reporter: Leonhard Maylein

 The eDismax handler parses the query
 is:038729080x into
 +((is:038729080 is:x)~2)
 The query parser should not separate camel
 case words or mixtures of letters and digits.
 This is the job of the analyzers.
 Otherwise there are special types of data
 (like isbn or issn numbers) which could not be
 searched via the eDismax query parser.

--
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-MAVEN] Lucene-Solr-Maven-4.x #181: POMs out of sync

2012-12-12 Thread Uwe Schindler

The problem here is:
The Maven job uploads the artifacts tot he remote reporsitoy, but does not 
install it locally, so the dependency check does not work. It worked before in 
an incorrect way, because it only verified the results of the Maven build, not 
our artifact creation with Ant.

I think we should split those 2 jenkins tasks and have a separate one that only 
deploys to apache snapshots, but does not validate (which does not work, see 
above).

I will remove the dependency checks for now in the maven task and move it the 
half-hourly builds.

Uwe

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


 -Original Message-
 From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
 Sent: Wednesday, December 12, 2012 12:24 PM
 To: dev@lucene.apache.org
 Subject: [JENKINS-MAVEN] Lucene-Solr-Maven-4.x #181: POMs out of sync
 
 Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/181/
 
 No tests ran.
 
 Build Log:
 [...truncated 11359 lines...]
 



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

[jira] [Created] (SOLR-4169) The test suite should consistently pass

Robert Muir created SOLR-4169:
-

 Summary: The test suite should consistently pass
 Key: SOLR-4169
 URL: https://issues.apache.org/jira/browse/SOLR-4169
 Project: Solr
  Issue Type: Bug
  Components: Tests
Reporter: Robert Muir
Priority: Blocker
 Fix For: 4.1


I'm at the end of my rope. 

Last week I tried to help with this: but its already wednesday and solr tests 
are 20x worse.

Users are complaining that they cannot get snapshots and test them, because the 
tests fail all the time.

Maven dependencies are wrong, but we never knew, because the tests never 
succeeded so the validation task hasn't actually run in months.

I think fixing this situation is a blocker to release: I can't imagine a bigger 
blocker actually.

--
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: svn commit: r1420580 - /lucene/dev/trunk/build.xml

2012-12-12 Thread Steve Rowe

Thanks Uwe, I'll look into it.
On Dec 12, 2012 4:30 AM, Uwe Schindler u...@thetaphi.de wrote:

 Hi,

 I committed the reorder of the checks. The dependency validation task
 fails in Solr:

 [licenses] MISSING sha1 checksum file for: C:\Users\Uwe
 Schindler\.m2\repository\org\jboss\netty\netty\3.2.2.Final\netty-3.2.2.Fina
 l.jar
  [licenses] Scanned 30 JAR file(s) for licenses (in 0.27s.), 1 error(s).

 So it looks like Maven-ANT-build adds an extra dependency to Solr that is
 not used in the conventional-ANT-build (trunk). I have no idea how to fix
 this.

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


  -Original Message-
  From: uschind...@apache.org [mailto:uschind...@apache.org]
  Sent: Wednesday, December 12, 2012 10:20 AM
  To: comm...@lucene.apache.org
  Subject: svn commit: r1420580 - /lucene/dev/trunk/build.xml
 
  Author: uschindler
  Date: Wed Dec 12 09:19:55 2012
  New Revision: 1420580
 
  URL: http://svn.apache.org/viewvc?rev=1420580view=rev
  Log:
  change order of jenkins-maven job
 
  Modified:
  lucene/dev/trunk/build.xml
 
  Modified: lucene/dev/trunk/build.xml
  URL:
  http://svn.apache.org/viewvc/lucene/dev/trunk/build.xml?rev=1420580r1
  =1420579r2=1420580view=diff
  ==
  
  --- lucene/dev/trunk/build.xml (original)
  +++ lucene/dev/trunk/build.xml Wed Dec 12 09:19:55 2012
  @@ -368,7 +368,7 @@
 !-- Jenkins tasks --
 target name=jenkins-hourly depends=clean,test-with-
  heapdumps,validate,documentation-lint,jar-checksums,check-svn-working-
  copy/
 
  -  target name=jenkins-maven-nightly depends=clean,remove-maven-
  artifacts,generate-maven-artifacts,run-maven-build,validate-maven-
  dependencies/
  +  target name=jenkins-maven-nightly
  + depends=clean,remove-maven-artifacts,generate-maven-artifacts,validat
  + e-maven-dependencies,run-maven-build/
 
 target name=jenkins-clover depends=run-clover/  /project



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

[jira] [Created] (LUCENE-4619) Create a specialized path for facets counting

Shai Erera created LUCENE-4619:
--

 Summary: Create a specialized path for facets counting
 Key: LUCENE-4619
 URL: https://issues.apache.org/jira/browse/LUCENE-4619
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Reporter: Shai Erera


Mike and I have been discussing that on several issues (LUCENE-4600, 
LUCENE-4602) and on GTalk ... it looks like the current API abstractions may be 
responsible for some of the performance loss that we see, compared to 
specialized code.

During our discussion, we've decided to target a specific use case - facets 
counting and work on it, top-to-bottom by reusing as much code as possible. 
Specifically, we'd like to implement a FacetsCollector/Accumulator which can do 
only counting (i.e. respects only CountFacetRequest), no sampling, partitions 
and complements. The API allows us to do so very cleanly, and in the context of 
that issue, we'd like to do the following:

* Implement a FacetsField which takes a TaxonomyWriter, FacetIndexingParams and 
CategoryPath (List, Iterable, whatever) and adds the needed information to both 
the taxonomy index as well as the search index.
** That API is similar in nature to CategoryDocumentBuilder, only easier to 
consume -- it's just another field that you add to the Document.
** We'll have two extensions for it: PayloadFacetsField and 
DocValuesFacetsField, so that we can benchmark the two approaches. Eventually, 
one of them we believe, will be eliminated, and we'll remain w/ just one 
(hopefully the DV one).

* Implement either a FacetsAccumulator/Collector which takes a bunch of 
CountFacetRequests and returns the top-counts.
** Aggregations are done in-collection, rather than post. Note that we have 
LUCENE-4600 open for exploring that. Either we finish this exploration here, or 
do it there. Just FYI that the issue exists.
** Reuses the CategoryListIterator, IntDecoder and Aggregator code. I'll open a 
separate issue to explore improving that API to be bulk, and then we can decide 
if this specialized Collector should use those abstractions, or be really 
optimized for the facet counting case.

* At the moment, this path will assume that a document holds multiple 
dimensions, but only one value from each (i.e. no Author/Shai, Author/Mike for 
a document), and therefore use OrdPolicy.NO_PARENTS.
** Later, we'd like to explore how to have this specialized path handle the 
ALL_PARENTS case too, as it shouldn't be so hard to do.


--
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-4620) Explore IntEncoder/Decoder bulk API

Shai Erera created LUCENE-4620:
--

 Summary: Explore IntEncoder/Decoder bulk API
 Key: LUCENE-4620
 URL: https://issues.apache.org/jira/browse/LUCENE-4620
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Reporter: Shai Erera


Today, IntEncoder/Decoder offer a streaming API, where you can encode(int) and 
decode(int). Originally, we believed that this layer can be useful for other 
scenarios, but in practice it's used only for writing/reading the category 
ordinals from payload/DV.

Therefore, Mike and I would like to explore a bulk API, something like 
encode(IntsRef, BytesRef) and decode(BytesRef, IntsRef). Perhaps the Encoder 
can still be streaming (as we don't know in advance how many ints will be 
written), dunno. Will figure this out as we go.

One thing to check is whether the bulk API can work w/ e.g. facet associations, 
which can write arbitrary byte[], and so may decoding to an IntsRef won't make 
sense. This too we'll figure out as we go. I don't rule out that associations 
will use a different bulk API.

At the end of the day, the requirement is for someone to be able to configure 
how ordinals are written (i.e. different encoding schemes: VInt, PackedInts 
etc.) and later read, with as little overhead as possible.

--
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-4170) Exception while creating snapshot

2012-12-12 Thread Marcin Rzewucki (JIRA)

Marcin Rzewucki created SOLR-4170:
-

 Summary: Exception while creating snapshot
 Key: SOLR-4170
 URL: https://issues.apache.org/jira/browse/SOLR-4170
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0
Reporter: Marcin Rzewucki


I'm using SolrCloud. When I'm trying to create index snapshot - exception 
occurs:
INFO: [test] webapp=/solr path=/replication 
params={command=backupnumberToKeep=1} status=0 QTime=1
Dec 07, 2012 6:00:02 PM org.apache.solr.handler.SnapShooter createSnapshot
SEVERE: Exception while creating snapshot
java.io.FileNotFoundException: File /solr/cores/test/data/index/segments_g does 
not exist
at 
org.apache.solr.handler.SnapShooter$FileCopier.copyFile(SnapShooter.java:194)
at 
org.apache.solr.handler.SnapShooter$FileCopier.copyFiles(SnapShooter.java:185)
at 
org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:105)
at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:78)

Issue occurs randomly. Reloading core usually helps, but sometimes core has to 
be reloaded couple of times to make snapshot possible.

--
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-4621) FacetIndexing/SearchParams house cleaning

Shai Erera created LUCENE-4621:
--

 Summary: FacetIndexing/SearchParams house cleaning
 Key: LUCENE-4621
 URL: https://issues.apache.org/jira/browse/LUCENE-4621
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Reporter: Shai Erera


FacetIndexingParams lets you configure few things such as OrdinalPolicy, 
PathPolicy and partitionSize. However, in order to set them you must extend 
DefaultFacetIndexingParams and override fixedXY(), as the respective getters 
are final.

I'd like to do the following:
* Turn FacetIndexingParams and FacetSearchParams into concrete classes, rather 
than interfaces. The reason they are interfaces because one app once wants to 
have one class which implements both. Since FSP holds FIP, I don't think that's 
needed.

* Add setters to FacetIndexingParams for the relevant configuration parameters, 
rather than forcing someone to extend the class. Extensions should really be 
for special cases, which we haven't identified so far (except overriding these 
settings), hence why there's only DefaultFIP/FSP.

* Add some javadocs...

* I'm sure, w/ my pedantic and perfectionist nature, that more thing will be 
done once I get to it :).

--
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-4622) TopKFacetsResultHandler should tie break sort by label not ord?

Michael McCandless created LUCENE-4622:
--

 Summary: TopKFacetsResultHandler should tie break sort by label 
not ord?
 Key: LUCENE-4622
 URL: https://issues.apache.org/jira/browse/LUCENE-4622
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/facet
Reporter: Michael McCandless


EG I now get these facets:
{noformat}
Author (5)
 Lisa (2)
 Frank (1)
 Susan (1)
 Bob (1)
{noformat}

The primary sort is by count, but secondary is by ord (= order in which they 
were indexed), which is not really understandable/transparent to the end user.  
I think it'd be best if we could do tie-break sort by label ...

But talking to Shai, this seems hard/costly to fix, because when visiting the 
facet ords to collect the top K, we don't currently resolve to label, and in 
the worst case (say my example had a million labels with count 1) that's a lot 
of extra label lookups ...

--
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-4619) Create a specialized path for facets counting

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

Michael McCandless updated LUCENE-4619:
---

Attachment: LUCENE-4619.patch

Attached starting patch with a PayloadFacetField, and a new
TestDemoFacets using it.

I think a simple-to-use field is easier for basic usage. Ie user just
does this:
{noformat}
doc.add(new PayloadFacetField(...));
{noformat}
instead of what must be done today:
{noformat}
CategoryDocumentBuilder docBuilder = new CategoryDocumentBuilder(...);
docBuilder.setCategoryPaths(...);
docBuilder.build(doc);
{noformat}

Create a specialized path for facets counting
-

Key: LUCENE-4619
URL: https://issues.apache.org/jira/browse/LUCENE-4619
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Shai Erera
Attachments: LUCENE-4619.patch

Mike and I have been discussing that on several issues (LUCENE-4600,
LUCENE-4602) and on GTalk ... it looks like the current API abstractions may
be responsible for some of the performance loss that we see, compared to
specialized code.
During our discussion, we've decided to target a specific use case - facets
counting and work on it, top-to-bottom by reusing as much code as possible.
Specifically, we'd like to implement a FacetsCollector/Accumulator which can
do only counting (i.e. respects only CountFacetRequest), no sampling,
partitions and complements. The API allows us to do so very cleanly, and in
the context of that issue, we'd like to do the following:
* Implement a FacetsField which takes a TaxonomyWriter, FacetIndexingParams
and CategoryPath (List, Iterable, whatever) and adds the needed information
to both the taxonomy index as well as the search index.
** That API is similar in nature to CategoryDocumentBuilder, only easier to
consume -- it's just another field that you add to the Document.
** We'll have two extensions for it: PayloadFacetsField and
DocValuesFacetsField, so that we can benchmark the two approaches.
Eventually, one of them we believe, will be eliminated, and we'll remain w/
just one (hopefully the DV one).
* Implement either a FacetsAccumulator/Collector which takes a bunch of
CountFacetRequests and returns the top-counts.
** Aggregations are done in-collection, rather than post. Note that we have
LUCENE-4600 open for exploring that. Either we finish this exploration here,
or do it there. Just FYI that the issue exists.
** Reuses the CategoryListIterator, IntDecoder and Aggregator code. I'll open
a separate issue to explore improving that API to be bulk, and then we can
decide if this specialized Collector should use those abstractions, or be
really optimized for the facet counting case.
* At the moment, this path will assume that a document holds multiple
dimensions, but only one value from each (i.e. no Author/Shai, Author/Mike
for a document), and therefore use OrdPolicy.NO_PARENTS.
** Later, we'd like to explore how to have this specialized path handle the
ALL_PARENTS case too, as it shouldn't be so hard to do.

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

[jira] [Commented] (LUCENE-4622) TopKFacetsResultHandler should tie break sort by label not ord?

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

Shai Erera commented on LUCENE-4622:

I think that there are two issues here Mike - which facets get into the top-K
list and how is that list sorted to the user?

Currently, the facets that make it into the top-K list are the ones that have
the higher weight (default, can be reversed). If there are collisions, then the
facets with the lower ordinals win. That's very similar to regular Lucene Sort,
which breaks ties on doc IDs, and can be easily explained to users as if
facets have same counts, the top K is determined by which facet was added first
to the index ... really like doc IDs.

The second issue is how the top-K categories are sorted on ties. Currently they
are not re-sorted by label. All of the applications that I've seen sort the
categories in the UI lexicographically (as a secondary sort). And some
applications that used facets for computing a tag cloud, sort the tag cloud by
label (first sort) and apply UI techniques to emphasize a category by its
weight. We figured that it's just a waste of CPU time to do this sort, someone
can very easily do that w/ the FacetResults that he gets.

So in my opinion:
* We should still break on ordinal for entering into the Top-K. It'd be very
costly otherwise, and I'm not sure how critical it is.
* Sorting by weight + label worries me. Why should an app pay for that if e.g.
it's going to sort in the UI anyway, say by the user's Locale? Or if it doesn't
care about the sort?

I would rather that we don't change the default, but maybe add an API for doing
that, like a utility class, or as a method on FacetResult. Whoever cares about
sorting, just call this method.

What worries me is that it may not be so obvious to apps that don't want the
sort, but get it sorted, that there's some extra work being done behind the
scenes. However for apps that get the results not sorted and care about it,
it's very clear to them that they need to do something, and for that we'll have
an API, or they can really implement by themselves?

Sorting when depth1 by label is going to be even trickier ...

Maybe as a compromise we can make FacetResultNode comparable and there break
ties on label? Then you could traverse your tree of results and call
Collections.sort(resultNodes) at each level?

TopKFacetsResultHandler should tie break sort by label not ord?
---

Key: LUCENE-4622
URL: https://issues.apache.org/jira/browse/LUCENE-4622
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Reporter: Michael McCandless

EG I now get these facets:
{noformat}
Author (5)
Lisa (2)
Frank (1)
Susan (1)
Bob (1)
{noformat}
The primary sort is by count, but secondary is by ord (= order in which they
were indexed), which is not really understandable/transparent to the end
user. I think it'd be best if we could do tie-break sort by label ...
But talking to Shai, this seems hard/costly to fix, because when visiting the
facet ords to collect the top K, we don't currently resolve to label, and in
the worst case (say my example had a million labels with count 1) that's a
lot of extra label lookups ...

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

RE: svn commit: r1420580 - /lucene/dev/trunk/build.xml

2012-12-12 Thread Uwe Schindler

I committed another  fix fort he Maven-ANT artifact creation.

This problem is still there, but I ignored it from my side.

 

-

Uwe Schindler

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

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

eMail: u...@thetaphi.de

 

From: Steve Rowe [mailto:sar...@gmail.com] 
Sent: Wednesday, December 12, 2012 1:32 PM
To: lucene dev
Subject: RE: svn commit: r1420580 - /lucene/dev/trunk/build.xml

 

Thanks Uwe, I'll look into it.

On Dec 12, 2012 4:30 AM, Uwe Schindler u...@thetaphi.de wrote:

Hi,

I committed the reorder of the checks. The dependency validation task fails in 
Solr:

[licenses] MISSING sha1 checksum file for: C:\Users\Uwe 
Schindler\.m2\repository\org\jboss\netty\netty\3.2.2.Final\netty-3.2.2.Fina
l.jar
 [licenses] Scanned 30 JAR file(s) for licenses (in 0.27s.), 1 error(s).

So it looks like Maven-ANT-build adds an extra dependency to Solr that is not 
used in the conventional-ANT-build (trunk). I have no idea how to fix this.

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


 -Original Message-
 From: uschind...@apache.org [mailto:uschind...@apache.org]
 Sent: Wednesday, December 12, 2012 10:20 AM
 To: comm...@lucene.apache.org
 Subject: svn commit: r1420580 - /lucene/dev/trunk/build.xml

 Author: uschindler
 Date: Wed Dec 12 09:19:55 2012
 New Revision: 1420580

 URL: http://svn.apache.org/viewvc?rev=1420580 
 http://svn.apache.org/viewvc?rev=1420580view=rev view=rev
 Log:
 change order of jenkins-maven job

 Modified:
 lucene/dev/trunk/build.xml

 Modified: lucene/dev/trunk/build.xml
 URL:
 http://svn.apache.org/viewvc/lucene/dev/trunk/build.xml?rev=1420580 
 http://svn.apache.org/viewvc/lucene/dev/trunk/build.xml?rev=1420580r1 r1
 =1420579r2=1420580view=diff
 ==
 
 --- lucene/dev/trunk/build.xml (original)
 +++ lucene/dev/trunk/build.xml Wed Dec 12 09:19:55 2012
 @@ -368,7 +368,7 @@
!-- Jenkins tasks --
target name=jenkins-hourly depends=clean,test-with-
 heapdumps,validate,documentation-lint,jar-checksums,check-svn-working-
 copy/

 -  target name=jenkins-maven-nightly depends=clean,remove-maven-
 artifacts,generate-maven-artifacts,run-maven-build,validate-maven-
 dependencies/
 +  target name=jenkins-maven-nightly
 + depends=clean,remove-maven-artifacts,generate-maven-artifacts,validat
 + e-maven-dependencies,run-maven-build/

target name=jenkins-clover depends=run-clover/  /project



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

[jira] [Commented] (LUCENE-4620) Explore IntEncoder/Decoder bulk API

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

Shai Erera commented on LUCENE-4620:

Also, today there are few IntEncoders which are used during indexing only, e.g.
SortingIntEncoder and UniqueIntEncoder which guarantee that an ordinal will be
written just once to the payload, and sort them so that DGap can be computed
afterwards. These do not have a matching Decoder, and they shouldn't have,
because at search time you don't care if the ords are sorted or not, and you
can assume they are unique.

Another thing that I think we should do is move those encoders into the *.facet
package. They are currently under the facet module, but o.a.l.util, b/c again
we thought at the time that they are a generic piece of code for
encoding/decoding integers. Lucene has PackedInts and DataInput/Output for
doing block and VInt encodings. Users can write Codecs for other encoding
algorithms ... IntEncoder/Decoder are not that generic :).

Explore IntEncoder/Decoder bulk API
---

Key: LUCENE-4620
URL: https://issues.apache.org/jira/browse/LUCENE-4620
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Shai Erera

Today, IntEncoder/Decoder offer a streaming API, where you can encode(int)
and decode(int). Originally, we believed that this layer can be useful for
other scenarios, but in practice it's used only for writing/reading the
category ordinals from payload/DV.
Therefore, Mike and I would like to explore a bulk API, something like
encode(IntsRef, BytesRef) and decode(BytesRef, IntsRef). Perhaps the Encoder
can still be streaming (as we don't know in advance how many ints will be
written), dunno. Will figure this out as we go.
One thing to check is whether the bulk API can work w/ e.g. facet
associations, which can write arbitrary byte[], and so may decoding to an
IntsRef won't make sense. This too we'll figure out as we go. I don't rule
out that associations will use a different bulk API.
At the end of the day, the requirement is for someone to be able to configure
how ordinals are written (i.e. different encoding schemes: VInt, PackedInts
etc.) and later read, with as little overhead as possible.

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

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

2012-12-12 Thread Apache Jenkins Server

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

No tests ran.

Build Log:
[...truncated 11036 lines...]



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

[jira] [Commented] (SOLR-4114) Collection API: Allow multiple shards from one collection on the same Solr server


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

Mark Miller commented on SOLR-4114:
---

I don't often run precommit - takes too long - but I generally do when adding 
new dependencies because i know there will be license stuff. Jenkins will catch 
it even if we dont before commit though.

You have to extend LuceneTestCase because thats what hooks you into our test 
framework I believe - eg it enforces things like setup and teardown calling 
super and a ton of other nice stuff.

If you don't do it, jenkins will complain and fail.

I'll look at SOLR-4120.

 Collection API: Allow multiple shards from one collection on the same Solr 
 server
 -

 Key: SOLR-4114
 URL: https://issues.apache.org/jira/browse/SOLR-4114
 Project: Solr
  Issue Type: New Feature
  Components: multicore, SolrCloud
Affects Versions: 4.0
 Environment: Solr 4.0.0 release
Reporter: Per Steffensen
Assignee: Mark Miller
  Labels: collection-api, multicore, shard, shard-allocation
 Fix For: 4.1, 5.0

 Attachments: 
 SOLR-4114_mocking_OverseerCollectionProcessorTest_branch_4x.patch, 
 SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, 
 SOLR-4114_trunk.patch


 We should support running multiple shards from one collection on the same 
 Solr server - the run a collection with 8 shards on a 4 Solr server cluster 
 (each Solr server running 2 shards).
 Performance tests at our side has shown that this is a good idea, and it is 
 also a good idea for easy elasticity later on - it is much easier to move an 
 entire existing shards from one Solr server to another one that just joined 
 the cluter than it is to split an exsiting shard among the Solr that used to 
 run it and the new Solr.
 See dev mailing list discussion Multiple shards for one collection on the 
 same Solr server

--
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-4623) facets should index drill-down fields using DOCS_ONLY

Michael McCandless created LUCENE-4623:
--

 Summary: facets should index drill-down fields using DOCS_ONLY
 Key: LUCENE-4623
 URL: https://issues.apache.org/jira/browse/LUCENE-4623
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Reporter: Michael McCandless


Today we index as DOCS_AND_POSITIONS, which is necessary because we stuff the 
payload into one of those tokens.

If we indexed under two fields instead, then we could make the drill-down field 
DOCS_ONLY.

But ... once/if we cutover to doc values then we could use one field again.

--
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-4623) facets should index drill-down fields using DOCS_ONLY

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

Shai Erera commented on LUCENE-4623:

Yes, that's a bug that's bugging me for some time. I thought that we could just
turn off the other indexing options for the drill-down terms, but then the
entire field gets screwed up.

If we're going to fix that, we'll need to provide index migration utilities,
either on the fly or as a one op (preferably on the fly). The drill-down terms
are used only for drill-down .. well in the case of associations it may not be
so, but nm them for now.

If we cutover to DV, we need index migration too. So maybe we stop everything
and develop some migration abilities? :)

facets should index drill-down fields using DOCS_ONLY
-

Key: LUCENE-4623
URL: https://issues.apache.org/jira/browse/LUCENE-4623
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Michael McCandless

Today we index as DOCS_AND_POSITIONS, which is necessary because we stuff the
payload into one of those tokens.
If we indexed under two fields instead, then we could make the drill-down
field DOCS_ONLY.
But ... once/if we cutover to doc values then we could use one field again.

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

[jira] [Commented] (LUCENE-4622) TopKFacetsResultHandler should tie break sort by label not ord?

2012-12-12 Thread Gilad Barkai (JIRA)

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

Gilad Barkai commented on LUCENE-4622:
--

I'm not fond of the post processing...
Today the sort is consistent. Lucene breaks even on doc ids, which order may
not be consistent due to out of order merges. This is not the case with
category ordinals.

If one wishes to post process they should be able to do so quite easy? But as
pointed out, it might not produce the results as intended due to a lot of
categories which scored the same and were left out.

TopKFacetsResultHandler should tie break sort by label not ord?
---

Key: LUCENE-4622
URL: https://issues.apache.org/jira/browse/LUCENE-4622
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Reporter: Michael McCandless

-
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-Windows (32bit/jdk1.6.0_37) - Build # 2138 - Still Failing!

2012-12-12 Thread Mark Miller


On Dec 12, 2012, at 1:08 AM, Shawn Heisey s...@elyograg.org wrote:

 On 12/11/2012 8:19 PM, Mark Miller wrote:
 I think there are two different issues at least going on - mostly around 
 replication. Just happens the solrcloud tests do a lot of that, so they tend 
 to pick up on issues there.
 
 I look and see if they are slower than normal - my test runs are looking a 
 little longer lately, but not by too much.
 
 The BasicDistributedZk* test are actually many tests rolled up into one - 
 mostly to save time on jetty construction/destruction steps. That is part of 
 why they are longer. There are a few things that add up - one is that we 
 start jetties sequentially due to system properyy issues - we also currently 
 stop them sequentially, just because no one has gotten to doing that in 
 parallel. There are a variety of other things as well.
 
 These tests end up catching many none solrcloud bugs though - most of the 
 solrcloud stuff is built on existing features and stresses them more than 
 usual.
 
 If the amount of time that these tests is taking is considered normal 
 (consistently just over 4 minutes for the one test/seed I singled out to 
 fail), then I'll just have to live with it.  Since these tests do catch bugs, 
 they are good things to have.
 
 I'm just feeling annoyance that the build time is dominated by tests for 
 features I don't use, especially because when I have a test failure, it's 
 almost always those tests.  I'll get over it once the problems are found and 
 they stop failing so often.
 
 I haven't gotten a single successful test run since this morning, even when I 
 just run ant clean test from branch_4x/solr.  I think it's time to go to 
 bed now.
 
 Thanks,
 Shawn

Well, I guess normal depends on who you are - for my machine it's closer to 2 
minutes. If it's 4 minutes for a lot of people, it may make sense to break it 
into 2 sets.

Right now these tests are catching a problem around replication and shutdown 
like I mentioned. The replication test hits the same thing sometimes, but much 
less often.

If you don't use replication, you are right - this probably has no effect on 
you. But they are not SolrCloud specific fails.

- Mark


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

[jira] [Commented] (SOLR-4169) The test suite should consistently pass


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

Michael McCandless commented on SOLR-4169:
--

+1

 The test suite should consistently pass
 ---

 Key: SOLR-4169
 URL: https://issues.apache.org/jira/browse/SOLR-4169
 Project: Solr
  Issue Type: Bug
  Components: Tests
Reporter: Robert Muir
Priority: Blocker
 Fix For: 4.1


 I'm at the end of my rope. 
 Last week I tried to help with this: but its already wednesday and solr tests 
 are 20x worse.
 Users are complaining that they cannot get snapshots and test them, because 
 the tests fail all the time.
 Maven dependencies are wrong, but we never knew, because the tests never 
 succeeded so the validation task hasn't actually run in months.
 I think fixing this situation is a blocker to release: I can't imagine a 
 bigger blocker actually.

--
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-4169) The test suite should consistently pass

2012-12-12 Thread Jack Krupansky (JIRA)

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

Jack Krupansky commented on SOLR-4169:
--

Maybe especially problematic tests could be disabled, but coverage would still
need to be fairly decent.

Also, put a hard limit of, say, 20 seconds per test. You could argue that even
that is too generous. But if someone is going to run tests on an especially
slow box, they should be able to raise that as needed.

The test suite should consistently pass
---

Key: SOLR-4169
URL: https://issues.apache.org/jira/browse/SOLR-4169
Project: Solr
Issue Type: Bug
Components: Tests
Reporter: Robert Muir
Priority: Blocker
Fix For: 4.1

I'm at the end of my rope.
Last week I tried to help with this: but its already wednesday and solr tests
are 20x worse.
Users are complaining that they cannot get snapshots and test them, because
the tests fail all the time.
Maven dependencies are wrong, but we never knew, because the tests never
succeeded so the validation task hasn't actually run in months.
I think fixing this situation is a blocker to release: I can't imagine a
bigger blocker actually.

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

[jira] [Created] (SOLR-4171) CachingDirectoryFactory should not return any directories after it has been closed.

Mark Miller created SOLR-4171:
-

 Summary: CachingDirectoryFactory should not return any directories 
after it has been closed.
 Key: SOLR-4171
 URL: https://issues.apache.org/jira/browse/SOLR-4171
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.1, 5.0


If something like the replication handler gets a directory after the factory 
has been closed, it may not be closed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4169) The test suite should consistently pass


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

Robert Muir commented on SOLR-4169:
---

{quote}
Maybe especially problematic tests could be disabled, but coverage would still 
need to be fairly decent.
{quote}

If a test fails all the time it has 0% coverage.

 The test suite should consistently pass
 ---

 Key: SOLR-4169
 URL: https://issues.apache.org/jira/browse/SOLR-4169
 Project: Solr
  Issue Type: Bug
  Components: Tests
Reporter: Robert Muir
Priority: Blocker
 Fix For: 4.1


 I'm at the end of my rope. 
 Last week I tried to help with this: but its already wednesday and solr tests 
 are 20x worse.
 Users are complaining that they cannot get snapshots and test them, because 
 the tests fail all the time.
 Maven dependencies are wrong, but we never knew, because the tests never 
 succeeded so the validation task hasn't actually run in months.
 I think fixing this situation is a blocker to release: I can't imagine a 
 bigger blocker actually.

--
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-4169) The test suite should consistently pass


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

Mark Miller commented on SOLR-4169:
---

Many of the current fails are existing bugs that have been exposed in tests by 
recent changes. Im excited to see these fails! This is good stuff.

 The test suite should consistently pass
 ---

 Key: SOLR-4169
 URL: https://issues.apache.org/jira/browse/SOLR-4169
 Project: Solr
  Issue Type: Bug
  Components: Tests
Reporter: Robert Muir
Priority: Blocker
 Fix For: 4.1


 I'm at the end of my rope. 
 Last week I tried to help with this: but its already wednesday and solr tests 
 are 20x worse.
 Users are complaining that they cannot get snapshots and test them, because 
 the tests fail all the time.
 Maven dependencies are wrong, but we never knew, because the tests never 
 succeeded so the validation task hasn't actually run in months.
 I think fixing this situation is a blocker to release: I can't imagine a 
 bigger blocker actually.

--
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-4169) The test suite should consistently pass

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

Mark Miller commented on SOLR-4169:
---

bq. If a test fails all the time it has 0% coverage.

Thats not true! This feedback and a variety of output from the fails over time
is invaluable! Even knowing it can pass sometimes and not others is more
valuable information. Call me sherlock holmes, but I love it. Such a help.

The test suite should consistently pass
---

Key: SOLR-4169
URL: https://issues.apache.org/jira/browse/SOLR-4169
Project: Solr
Issue Type: Bug
Components: Tests
Reporter: Robert Muir
Priority: Blocker
Fix For: 4.1

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

[jira] [Commented] (SOLR-3911) Make Directory and DirectoryFactory first class so that the majority of Solr's features work with any custom implementations.


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

Mark Miller commented on SOLR-3911:
---

Okay, this is pretty firmed up now - I'm ready to bring it back. Currently, 4x 
is having more issues with replication than 5x. There are multiple problems 
showing up in 4x, none of them currently showing up in 5x - so I think it's 
better we move down to one set of code to track and debug.

 Make Directory and DirectoryFactory first class so that the majority of 
 Solr's features work with any custom implementations.
 -

 Key: SOLR-3911
 URL: https://issues.apache.org/jira/browse/SOLR-3911
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.1, 5.0

 Attachments: SOLR-3911.patch, SOLR-3911.patch, SOLR-3911.patch


 The biggest issue is that many parts of Solr rely on a local file system 
 based Directory implementation - most notably, replication. This should all 
 be changed to use the Directory and DirectoryFactory abstractions.
 Other parts of the code that count on the local file system for making paths 
 and getting file sizes should also be changed to use Directory and/or 
 DirectoryFactory.
 Original title: Replication should work with any Directory impl, not just 
 local filesystem based Directories.
 I've wanted to do this for a long time - there is no reason replication 
 should not support any directory impl. This will let us use the mockdir for 
 replication tests rather than having to force an FSDir and lose all the extra 
 test checks and simulations. This will improve our testing around replication 
 a lot, and allow custom Directory impls to be used on multi node Solr.
 Expanded scope - full first class support for DirectoryFactory and Directory.

--
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-3911) Make Directory and DirectoryFactory first class so that the majority of Solr's features work with any custom implementations.

2012-12-12 Thread Yonik Seeley (JIRA)


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

Yonik Seeley commented on SOLR-3911:


+1... merging any of these bug issues targeted for 4.1 (but not yet merged) 
alone seems really hard at this point.  let's just do them together to make 
sure we don't miss anything.  AFAIK, there have been no changes to solr 
specifically targeted toward 5.

 Make Directory and DirectoryFactory first class so that the majority of 
 Solr's features work with any custom implementations.
 -

 Key: SOLR-3911
 URL: https://issues.apache.org/jira/browse/SOLR-3911
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.1, 5.0

 Attachments: SOLR-3911.patch, SOLR-3911.patch, SOLR-3911.patch


 The biggest issue is that many parts of Solr rely on a local file system 
 based Directory implementation - most notably, replication. This should all 
 be changed to use the Directory and DirectoryFactory abstractions.
 Other parts of the code that count on the local file system for making paths 
 and getting file sizes should also be changed to use Directory and/or 
 DirectoryFactory.
 Original title: Replication should work with any Directory impl, not just 
 local filesystem based Directories.
 I've wanted to do this for a long time - there is no reason replication 
 should not support any directory impl. This will let us use the mockdir for 
 replication tests rather than having to force an FSDir and lose all the extra 
 test checks and simulations. This will improve our testing around replication 
 a lot, and allow custom Directory impls to be used on multi node Solr.
 Expanded scope - full first class support for DirectoryFactory and Directory.

--
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-4171) CachingDirectoryFactory should not return any directories after it has been closed.


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

Commit Tag Bot commented on SOLR-4171:
--

[trunk commit] Mark Robert Miller
http://svn.apache.org/viewvc?view=revisionrevision=1420779

SOLR-4171: CachingDirectoryFactory should not return any directories after it 
has been closed.


 CachingDirectoryFactory should not return any directories after it has been 
 closed.
 ---

 Key: SOLR-4171
 URL: https://issues.apache.org/jira/browse/SOLR-4171
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.1, 5.0


 If something like the replication handler gets a directory after the factory 
 has been closed, it may not be closed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4619) Create a specialized path for facets counting

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

Shai Erera commented on LUCENE-4619:

Few comments:

* You can remove TestDemoFacets from the patch? (since you committed it)

* DEFAULT_INDEXING_PARAMS is a good idea, but it can change (it's mutable).
However, I plan to add {{freeze()}} to it in LUCENE-4621, so maybe update the
nocommit to call freeze() on it?

* Adding the field more than once ... that's tricky. It will of course create
multiple positions, but the entire code now assumes a single position for
facets. Is there any way we can prevent it? I guess not. Maybe put a WARNING
for now?
** It should be ok to add it more than once, with different FIParams, e.g.
different CLPs.
** I guess that's where CDB simplifies things?

* The check that you do in the ctor:
** I think it can be simplified to just check FIP.getAllCLPs().size() != 1? If
so, throw the exception
** Also note that you have a typo in the exception msg

* The rest of the code just freaks the hell out of me! :)
** I think that you need the stream because that's the only way to add the
field with the drill-down term and fulltree posting.
** Would rather if that was simplified ... but I don't want to implement a
different TokenStream, not sure there's much value in it.
** Still, maybe put a TODO (not nocommit) to check if it can be simplified?

* BTW, when I look at the test, adding the PayloadFacetField is super neat. I
wonder if we simplified CDB to have less API, then all this would still be
required. E.g.:

{code}
ListCPath categories; // you need to prepare that w/ PayloadFacetField too!
Document doc = new Document();
cdb.addFields(doc, categories);
{code}

It's not a Field, but it works w/ multiple CLPs and all (basically the code
today). Only you don't need to set the categories. It can also mask in the
future the case where we put the fulltree under one field and the terms under
another, or everything as a DV ... What do you think?

Sorry that I don't fix the patch myself, but I'm rather short on time now. I
can do it later. I'm also going to tackle LUCENE-4621 now.

Create a specialized path for facets counting
-

Key: LUCENE-4619
URL: https://issues.apache.org/jira/browse/LUCENE-4619
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Shai Erera
Attachments: LUCENE-4619.patch

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

[jira] [Commented] (SOLR-4169) The test suite should consistently pass


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

Mark Miller commented on SOLR-4169:
---

One nice thing about all the jenkins now, pumping away all the time, is that it 
was really quick to be able to tell that I would have a lot easier time finding 
things using my windows VM - it seemed more fails happening there. I was able 
to determine that pretty quickly compared to how long (if ever) id have to wait 
in the old days!

I also was able to tell a lot by the difference between 4x and 5x fails - again 
in a fairly short period of time.

This stuff is great!

 The test suite should consistently pass
 ---

 Key: SOLR-4169
 URL: https://issues.apache.org/jira/browse/SOLR-4169
 Project: Solr
  Issue Type: Bug
  Components: Tests
Reporter: Robert Muir
Priority: Blocker
 Fix For: 4.1


 I'm at the end of my rope. 
 Last week I tried to help with this: but its already wednesday and solr tests 
 are 20x worse.
 Users are complaining that they cannot get snapshots and test them, because 
 the tests fail all the time.
 Maven dependencies are wrong, but we never knew, because the tests never 
 succeeded so the validation task hasn't actually run in months.
 I think fixing this situation is a blocker to release: I can't imagine a 
 bigger blocker actually.

--
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-3911) Make Directory and DirectoryFactory first class so that the majority of Solr's features work with any custom implementations.


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

Mark Miller commented on SOLR-3911:
---

Okay, makes sense. There should only be the lazy cores issue other this this 
and custom hashing. Anything else that is different should be a mistake. 

 Make Directory and DirectoryFactory first class so that the majority of 
 Solr's features work with any custom implementations.
 -

 Key: SOLR-3911
 URL: https://issues.apache.org/jira/browse/SOLR-3911
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.1, 5.0

 Attachments: SOLR-3911.patch, SOLR-3911.patch, SOLR-3911.patch


 The biggest issue is that many parts of Solr rely on a local file system 
 based Directory implementation - most notably, replication. This should all 
 be changed to use the Directory and DirectoryFactory abstractions.
 Other parts of the code that count on the local file system for making paths 
 and getting file sizes should also be changed to use Directory and/or 
 DirectoryFactory.
 Original title: Replication should work with any Directory impl, not just 
 local filesystem based Directories.
 I've wanted to do this for a long time - there is no reason replication 
 should not support any directory impl. This will let us use the mockdir for 
 replication tests rather than having to force an FSDir and lose all the extra 
 test checks and simulations. This will improve our testing around replication 
 a lot, and allow custom Directory impls to be used on multi node Solr.
 Expanded scope - full first class support for DirectoryFactory and Directory.

--
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-4169) The test suite should consistently pass

2012-12-12 Thread Adrien Grand (JIRA)

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

Adrien Grand commented on SOLR-4169:

bq. Im excited to see these fails!

I don't agree. When I worked on SOLR-3855, I very often got errors from
BasicDistributedZkTest.testDistribSearch, but I couldn't know whether I
introduced a bug or if it was a random failure. This is very frustrating and
can make us commit buggy stuff because we assume the bug is in the test.

The test suite should consistently pass
---

Key: SOLR-4169
URL: https://issues.apache.org/jira/browse/SOLR-4169
Project: Solr
Issue Type: Bug
Components: Tests
Reporter: Robert Muir
Priority: Blocker
Fix For: 4.1

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

Re: svn commit: r1420786 - /lucene/dev/trunk/dev-tools/maven/solr/solrj/src/java/pom.xml.template

2012-12-12 Thread Robert Muir

thanks for tracking this down!

On Wed, Dec 12, 2012 at 10:49 AM,  sar...@apache.org wrote:
 Author: sarowe
 Date: Wed Dec 12 15:49:43 2012
 New Revision: 1420786

 URL: http://svn.apache.org/viewvc?rev=1420786view=rev
 Log:
 Maven configuration: Solrj: exclude unused netty dependency from zookeeper 
 dependency

 Modified:
 lucene/dev/trunk/dev-tools/maven/solr/solrj/src/java/pom.xml.template

 Modified: 
 lucene/dev/trunk/dev-tools/maven/solr/solrj/src/java/pom.xml.template
 URL: 
 http://svn.apache.org/viewvc/lucene/dev/trunk/dev-tools/maven/solr/solrj/src/java/pom.xml.template?rev=1420786r1=1420785r2=1420786view=diff
 ==
 --- lucene/dev/trunk/dev-tools/maven/solr/solrj/src/java/pom.xml.template 
 (original)
 +++ lucene/dev/trunk/dev-tools/maven/solr/solrj/src/java/pom.xml.template Wed 
 Dec 12 15:49:43 2012
 @@ -63,6 +63,10 @@
artifactIdlog4j/artifactId
  /exclusion
  exclusion
 +  groupIdorg.jboss.netty/groupId
 +  artifactIdnetty/artifactId
 +/exclusion
 +exclusion
groupIdorg.slf4j/groupId
artifactIdslf4j-log4j12/artifactId
  /exclusion



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

[jira] [Commented] (SOLR-4168) In recovery, replication occurs but all files are 0 in length and trying to open an indexwriter on the index fails, causing a loop with this issue.


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

Mark Miller commented on SOLR-4168:
---

So something is still happening here - doesn't seem that was the issue or only 
issue. Still not a problem seen on 5.x though. 

 In recovery, replication occurs but all files are 0 in length and trying to 
 open an indexwriter on the index fails, causing a loop with this issue.
 ---

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


 Reported on the user list and evident in tests.

--
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-4169) The test suite should consistently pass

2012-12-12 Thread selckin (JIRA)


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

selckin commented on SOLR-4169:
---

Also see issues like SOLR-2608 that are ignored, i've been running lucene tests 
in a loop on and off for periods, and basically gave up on solr tests aswel, 
they randomly fail all the time

 The test suite should consistently pass
 ---

 Key: SOLR-4169
 URL: https://issues.apache.org/jira/browse/SOLR-4169
 Project: Solr
  Issue Type: Bug
  Components: Tests
Reporter: Robert Muir
Priority: Blocker
 Fix For: 4.1


 I'm at the end of my rope. 
 Last week I tried to help with this: but its already wednesday and solr tests 
 are 20x worse.
 Users are complaining that they cannot get snapshots and test them, because 
 the tests fail all the time.
 Maven dependencies are wrong, but we never knew, because the tests never 
 succeeded so the validation task hasn't actually run in months.
 I think fixing this situation is a blocker to release: I can't imagine a 
 bigger blocker actually.

--
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-4169) The test suite should consistently pass

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

Mark Miller commented on SOLR-4169:
---

Any test that catches a bug is good test to me! The bugs need to be fixed - I'd
rather have complaints about them then not even know they are there!

Individuals can still locally ignore tests, use @slow, etc.

Some of these fails take a while to track down, still others are introduced
inadvertently over time in other code.

If any test is failing too often for you, you should make a JIRA issue and we
can work down to the problem - that has generally worked out well. I usually
have these test passing consistently in many jenkins envs or am otherwise
working on making it so.

Im still excited when existing bugs are unearthed by our tests - call me crazy!
:)

The test suite should consistently pass
---

Key: SOLR-4169
URL: https://issues.apache.org/jira/browse/SOLR-4169
Project: Solr
Issue Type: Bug
Components: Tests
Reporter: Robert Muir
Priority: Blocker
Fix For: 4.1

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

[jira] [Commented] (SOLR-4169) The test suite should consistently pass

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

Mark Miller commented on SOLR-4169:
---

bq. Also see issues like SOLR-2608

That issue was never ignored! Test replication handler has been exposing
problems with a handler running after core shutdown for a long time. It has
found many bugs that I have fixed!

In fact, I think Ive finally got that test near 100%. That ignored test has
gotten a ton of my time this year - finally about to pay off. Sorry Im not as
fast as Id like to be :) Its in very good shape on 5x right now I think. The
fact that the test passes 99% of the time says a lot even before - if it didnt
run at all, we would just introduce more bugs.

The test suite should consistently pass
---

Key: SOLR-4169
URL: https://issues.apache.org/jira/browse/SOLR-4169
Project: Solr
Issue Type: Bug
Components: Tests
Reporter: Robert Muir
Priority: Blocker
Fix For: 4.1

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

[jira] [Commented] (SOLR-4169) The test suite should consistently pass

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

Mark Miller commented on SOLR-4169:
---

For to add a bit of history:

Most of these fails never would have been fails when most of this code was
written. Back then, we didnt check for directories not being closed, we didnt
run tests in parallel, tests ran once a day, we didn't have an awesome test
framework that failed based on all these things.

So before, most of what randomly fails now, would not even have failed before.

The original coders for a lot of the tests and code failing had moved on to
other things. It's taken time to slowly harden everything. SolrCloud and its
jetty based tests introduced a new layer.

Meanwhile, I do a lot of solr development and i find the tests very useful. If
you need some help, please, ask me and I can lend you hand.

The tests have made great strides - I and a couple others are reducing the
failures all the time. Sometimes they flair up due to some change or mix of
changes - currently that is happening due to a couple issues that are well
documented and attended to on the list. Real issues that need to be dealt with.

The random fails are not usually test issues - but nor are they always critical
issues. In fact, most involve shutdown - an area we just have not cared a great
deal about in Solr in the past. So what if shutdown wasnt perfect. SolrCloud
changes that a bit.

Anyhow, I put a lot of effort into improving the tests, and I know I've made a
lot of ground, and will continue to do so. There are a lot of challenges. Like
I said, Ive been in the Lucene world too, and the nature of it being a library
without jetty or large integration tests really made it an breeze in
comparison. Lucene also is lucky enough to have more people that are test
fanatics at the moment.

The test suite should consistently pass
---

Key: SOLR-4169
URL: https://issues.apache.org/jira/browse/SOLR-4169
Project: Solr
Issue Type: Bug
Components: Tests
Reporter: Robert Muir
Priority: Blocker
Fix For: 4.1

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

[jira] [Comment Edited] (SOLR-4169) The test suite should consistently pass

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

Mark Miller edited comment on SOLR-4169 at 12/12/12 4:31 PM:
-

To add a bit of history:

So before, most of what randomly fails now, would not even have failed before.

The original coders for a lot of the tests and code failing had moved on to
other things. It's taken time to slowly harden everything. SolrCloud and its
jetty based tests introduced a new layer.

Meanwhile, I do a lot of solr development and i find the tests very useful. If
you need some help, please, ask me and I can lend you hand.

was (Author: markrmil...@gmail.com):
For to add a bit of history:

So before, most of what randomly fails now, would not even have failed before.

The original coders for a lot of the tests and code failing had moved on to
other things. It's taken time to slowly harden everything. SolrCloud and its
jetty based tests introduced a new layer.

Meanwhile, I do a lot of solr development and i find the tests very useful. If
you need some help, please, ask me and I can lend you hand.

The test suite should consistently pass
---

Key: SOLR-4169
URL: https://issues.apache.org/jira/browse/SOLR-4169
Project: Solr
Issue Type: Bug
Components: Tests
Reporter: Robert Muir
Priority: Blocker
Fix For: 4.1

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

[jira] [Created] (SOLR-4172) Web GUI should provide the base URL required for SolrJ and other APIs

2012-12-12 Thread Shawn Heisey (JIRA)

Shawn Heisey created SOLR-4172:
--

 Summary: Web GUI should provide the base URL required for SolrJ 
and other APIs
 Key: SOLR-4172
 URL: https://issues.apache.org/jira/browse/SOLR-4172
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Affects Versions: 4.0
Reporter: Shawn Heisey
Priority: Minor
 Fix For: 4.1, 5.0


When you click on a core in the web gui, you get a URL like the following in 
the browser URL bar:

http://server:port/solr/#/corename

There have been some instances on the mailing list where users try to use this 
URL in an API like SolrJ.  If the main core page were to display the proper 
URL, there would be less confusion.  Unless we make it so that accessing the 
proper base URL gives a helpful message in the browser, it should not be a 
link.  I'll file another feature request for that helpful message.


--
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-4169) The test suite should consistently pass


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

Mark Miller commented on SOLR-4169:
---

bq. can make us commit buggy stuff because we assume the bug is in the test.

By the way, your in the same boat without the test - you would commit the same 
buggy code - you just would also have a possible false sense of comfort.

 The test suite should consistently pass
 ---

 Key: SOLR-4169
 URL: https://issues.apache.org/jira/browse/SOLR-4169
 Project: Solr
  Issue Type: Bug
  Components: Tests
Reporter: Robert Muir
Priority: Blocker
 Fix For: 4.1


 I'm at the end of my rope. 
 Last week I tried to help with this: but its already wednesday and solr tests 
 are 20x worse.
 Users are complaining that they cannot get snapshots and test them, because 
 the tests fail all the time.
 Maven dependencies are wrong, but we never knew, because the tests never 
 succeeded so the validation task hasn't actually run in months.
 I think fixing this situation is a blocker to release: I can't imagine a 
 bigger blocker actually.

--
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-4172) Web GUI should provide the base URL required for SolrJ and other APIs


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

Mark Miller commented on SOLR-4172:
---

+1

 Web GUI should provide the base URL required for SolrJ and other APIs
 -

 Key: SOLR-4172
 URL: https://issues.apache.org/jira/browse/SOLR-4172
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Affects Versions: 4.0
Reporter: Shawn Heisey
Priority: Minor
 Fix For: 4.1, 5.0


 When you click on a core in the web gui, you get a URL like the following in 
 the browser URL bar:
 http://server:port/solr/#/corename
 There have been some instances on the mailing list where users try to use 
 this URL in an API like SolrJ.  If the main core page were to display the 
 proper URL, there would be less confusion.  Unless we make it so that 
 accessing the proper base URL gives a helpful message in the browser, it 
 should not be a link.  I'll file another feature request for that helpful 
 message.

--
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-4173) SolrJ API base URL returns 404 - print helpful message instead

2012-12-12 Thread Shawn Heisey (JIRA)

Shawn Heisey created SOLR-4173:
--

 Summary: SolrJ API base URL returns 404 - print helpful message 
instead
 Key: SOLR-4173
 URL: https://issues.apache.org/jira/browse/SOLR-4173
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Affects Versions: 4.0
Reporter: Shawn Heisey
Priority: Minor
 Fix For: 4.1, 5.0


If you put the URL that's correct for an API like SolrJ into a browser, you get 
a 404 error.

It would be really helpful if it were to instead display a helpful message 
letting a user know that they have accessed the core's base URL, which is only 
useful in API calls.

It should offer a link with its own URL as a handy place to right-click  copy. 
 That self-link should either have or not have the trailing slash, according to 
what is the current recommended practice.  Side note: I do include the trailing 
slash in my SolrJ URLs.

The message should probably also offer a link back to the admin GUI page for 
that core, and any other links that people might find useful.


--
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-2608) TestReplicationHandler is flakey


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

Mark Miller commented on SOLR-2608:
---

There are many issues this test has been exposing - it should be getting fairly 
hardened on 5x these days though.

 TestReplicationHandler is flakey
 

 Key: SOLR-2608
 URL: https://issues.apache.org/jira/browse/SOLR-2608
 Project: Solr
  Issue Type: Bug
Reporter: selckin

 I've been running some while(1) tests on trunk, and TestReplicationHandler is 
 very flakey it fails about every 10th run.
 Probably not a bug, but the test not waiting correctly
 {code}
 [junit] Testsuite: org.apache.solr.handler.TestReplicationHandler
 [junit] Testcase: org.apache.solr.handler.TestReplicationHandler:   FAILED
 [junit] ERROR: SolrIndexSearcher opens=48 closes=47
 [junit] junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher 
 opens=48 closes=47
 [junit] at 
 org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:131)
 [junit] at 
 org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:74)
 [junit] 
 [junit] 
 [junit] Tests run: 8, Failures: 1, Errors: 0, Time elapsed: 40.772 sec
 [junit] 
 [junit] - Standard Error -
 [junit] 19-Jun-2011 21:26:44 org.apache.solr.handler.SnapPuller 
 fetchLatestIndex
 [junit] SEVERE: Master at: http://localhost:51817/solr/replication is not 
 available. Index fetch failed. Exception: Connection refused
 [junit] 19-Jun-2011 21:26:49 org.apache.solr.common.SolrException log
 [junit] SEVERE: java.util.concurrent.RejectedExecutionException
 [junit] at 
 java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
 [junit] at 
 java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
 [junit] at 
 java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
 [junit] at 
 java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:92)
 [junit] at 
 java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:603)
 [junit] at 
 org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1149)
 [junit] at 
 org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:346)
 [junit] at 
 org.apache.solr.handler.SnapPuller.doCommit(SnapPuller.java:483)
 [junit] at 
 org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:332)
 [junit] at 
 org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:267)
 [junit] at 
 org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:166)
 [junit] at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 [junit] at 
 java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
 [junit] at 
 java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
 [junit] at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
 [junit] at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
 [junit] at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
 [junit] at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 [junit] at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 [junit] at java.lang.Thread.run(Thread.java:662)
 [junit] 
 [junit] 19-Jun-2011 21:26:51 org.apache.solr.update.SolrIndexWriter 
 finalize
 [junit] SEVERE: SolrIndexWriter was not closed prior to finalize(), 
 indicates a bug -- POSSIBLE RESOURCE LEAK!!!
 [junit] 19-Jun-2011 21:26:51 
 org.apache.solr.common.util.ConcurrentLRUCache finalize
 [junit] SEVERE: ConcurrentLRUCache was not destroyed prior to finalize(), 
 indicates a bug -- POSSIBLE RESOURCE LEAK!!!
 [junit] 19-Jun-2011 21:27:13 org.apache.solr.handler.SnapPuller 
 fetchLatestIndex
 [junit] SEVERE: Master at: http://localhost:46559/solr/replication is not 
 available. Index fetch failed. Exception: Connection refused
 [junit] 19-Jun-2011 21:27:14 org.apache.solr.handler.SnapPuller 
 fetchLatestIndex
 [junit] SEVERE: Master at: http://localhost:46559/solr/replication is not 
 available. Index fetch failed. Exception: Connection refused
 [junit] 19-Jun-2011 21:27:14 org.apache.solr.SolrTestCaseJ4 
 endTrackingSearchers
 [junit] SEVERE: ERROR: SolrIndexSearcher opens=48 closes=47
 [junit] -

[jira] [Updated] (LUCENE-4617) remove FST.pack() method


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

Robert Muir updated LUCENE-4617:


Attachment: LUCENE-4617.patch

Here's a start. I have no idea what all these packing params are: so i stole 
the defaults from MemoryPostings.

 remove FST.pack() method
 

 Key: LUCENE-4617
 URL: https://issues.apache.org/jira/browse/LUCENE-4617
 Project: Lucene - Core
  Issue Type: Sub-task
  Components: core/FSTs
Reporter: Robert Muir
 Attachments: LUCENE-4617.patch


 Current method to make a packed FST:
 1. Create an FST Builder with willPack=true, telling it you are later going 
 to pack() it.
 2. Create your fst with finish() as normal.
 3. Take that fst, and call pack() on it to get another FST.
 This makes no sense. if you pass willPack=true, then I think finish() should 
 just return a packed fst.

--
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-4169) The test suite should consistently pass

2012-12-12 Thread Dawid Weiss (JIRA)

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

Dawid Weiss commented on SOLR-4169:
---

bq. Back then, we didnt check for directories not being closed, we didnt run
tests in parallel, tests ran once a day

I agree with Mark that the restrictions put on tests have made it more
difficult for the complex stuff to pass. And every Lucene/Solr committer should
try to fix at least one Solr test to get the taste of how complex those tests
are :) These aren't necessarily regressions -- they're existing weak spots
uncovered by more rigorous test sandbox rules.

This said, I still think it'd be nice if we could somehow disable those tests
that we know produce a lot of noise and only enable them on a build plan that
would run with a specific e-mail prefix or with an entire different e-mail
sink. Once somebody decides they're ok to be included in all plans they can do
so; if builds start to fail again -- switch them back to the unstable zone.
Much like in-progress branches, really.

The test suite should consistently pass
---

Key: SOLR-4169
URL: https://issues.apache.org/jira/browse/SOLR-4169
Project: Solr
Issue Type: Bug
Components: Tests
Reporter: Robert Muir
Priority: Blocker
Fix For: 4.1

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

[jira] [Commented] (SOLR-4169) The test suite should consistently pass

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

Robert Muir commented on SOLR-4169:
---

{quote}
And every Lucene/Solr committer should try to fix at least one Solr test to get
the taste of how complex those tests are
{quote}

But this isn't a good thing really. The tests shouldnt be complex to debug. its
junit, they should be unit tests.

maybe these integration tests should be yanked out into a separate part of the
build.

The test suite should consistently pass
---

Key: SOLR-4169
URL: https://issues.apache.org/jira/browse/SOLR-4169
Project: Solr
Issue Type: Bug
Components: Tests
Reporter: Robert Muir
Priority: Blocker
Fix For: 4.1

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

[jira] [Commented] (SOLR-4169) The test suite should consistently pass

2012-12-12 Thread Dawid Weiss (JIRA)


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

Dawid Weiss commented on SOLR-4169:
---

This would be an ideal situation, I agree. But then what would unit tests for 
Solr be? :)

 The test suite should consistently pass
 ---

 Key: SOLR-4169
 URL: https://issues.apache.org/jira/browse/SOLR-4169
 Project: Solr
  Issue Type: Bug
  Components: Tests
Reporter: Robert Muir
Priority: Blocker
 Fix For: 4.1


 I'm at the end of my rope. 
 Last week I tried to help with this: but its already wednesday and solr tests 
 are 20x worse.
 Users are complaining that they cannot get snapshots and test them, because 
 the tests fail all the time.
 Maven dependencies are wrong, but we never knew, because the tests never 
 succeeded so the validation task hasn't actually run in months.
 I think fixing this situation is a blocker to release: I can't imagine a 
 bigger blocker actually.

--
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-4169) The test suite should consistently pass

2012-12-12 Thread Adrien Grand (JIRA)

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

Adrien Grand commented on SOLR-4169:

bq. By the way, your in the same boat without the test - you would commit the
same buggy code - you just would also have a possible false sense of comfort.

Agreed, but still this situation makes it hard for new Solr contributors like
me to know whether their patchs are committable or not.

The test suite should consistently pass
---

Key: SOLR-4169
URL: https://issues.apache.org/jira/browse/SOLR-4169
Project: Solr
Issue Type: Bug
Components: Tests
Reporter: Robert Muir
Priority: Blocker
Fix For: 4.1

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

[jira] [Commented] (SOLR-4169) The test suite should consistently pass

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

Mark Miller commented on SOLR-4169:
---

I dont mind if integration tests were separate, but I dont think it would
change too much. Youd still have to run them the same - I find them more
important than unit tests for having any faith in the system. For me, unit
tests are nice and super useful, integration tests are essential.

The main difference is that you could iterate in dev faster by just running
faster unit tests and then run integration tests before committing.

But that seems the same as @slow to me now, so I don't think it buys much.

The test suite should consistently pass
---

Key: SOLR-4169
URL: https://issues.apache.org/jira/browse/SOLR-4169
Project: Solr
Issue Type: Bug
Components: Tests
Reporter: Robert Muir
Priority: Blocker
Fix For: 4.1

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

[jira] [Commented] (SOLR-4169) The test suite should consistently pass

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

Robert Muir commented on SOLR-4169:
---

{quote}
This would be an ideal situation, I agree. But then what would unit tests for
Solr be?
{quote}

For instance: tests that test a query parser can just create that QP, and do:

{code}
Query expected = ...
assertEquals(expected, parser.parse(someString));
{code}

Just like unit tests everywhere else.

But nobody writes solr tests this way (i dont know why, ive definitely written
such unit tests for solr components before).
Instead e.g. all the queryparser tests actually index documents and assert
XPATH shit against the response.

This makes them significantly harder to debug for no good reason.

The test suite should consistently pass
---

Key: SOLR-4169
URL: https://issues.apache.org/jira/browse/SOLR-4169
Project: Solr
Issue Type: Bug
Components: Tests
Reporter: Robert Muir
Priority: Blocker
Fix For: 4.1

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

[jira] [Created] (LUCENE-4624) Compare Lucene memory estimator with terracota's

2012-12-12 Thread Dawid Weiss (JIRA)

Dawid Weiss created LUCENE-4624:
---

 Summary: Compare Lucene memory estimator with terracota's
 Key: LUCENE-4624
 URL: https://issues.apache.org/jira/browse/LUCENE-4624
 Project: Lucene - Core
  Issue Type: Task
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Minor


Alex Snaps informed me that there's a sizeof estimator in terracota --

http://svn.terracotta.org/svn/ehcache/trunk/ehcache/ehcache-core/src/main/java/net/sf/ehcache/pool/sizeof/

looks interesting, they have some VM-specific methods. Didn't look too deeply 
though; if somebody has the time to check out the differences and maybe compare 
the estimation differences it'd be nice.

--
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-4169) The test suite should consistently pass

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

Mark Miller commented on SOLR-4169:
---

bq. makes it hard for new Solr contributors like me to know whether their
patchs are committable or not.

Dude, I don't doubt you! I spent more time on tests this year than feature dev
because of that very issue. But these tests are critically useful regardless. I
cant help that - I can just keep helping make them hardier.

And if contributors have questions about a fail, I can give some guidance
depending on the test and fail.

I mean, hopefully we get to very few fails - but its a constant moving battle.
I feel like we have been gaining a lot of ground.

The test suite should consistently pass
---

Key: SOLR-4169
URL: https://issues.apache.org/jira/browse/SOLR-4169
Project: Solr
Issue Type: Bug
Components: Tests
Reporter: Robert Muir
Priority: Blocker
Fix For: 4.1

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

[jira] [Updated] (LUCENE-4613) CompressingStoredFieldsWriter ignores the segment suffix if writing aborted

2012-12-12 Thread Renaud Delbru (JIRA)


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

Renaud Delbru updated LUCENE-4613:
--

Attachment: LUCENE-4613.patch

A first refactoring to try to keep backward compatibility of the 
{{CompressingCodec#randomInstance(Random random)}}. Let me know if this is good 
enough. Tests are passing, as well as the specific TestIndexFileDeleter test 
case you previously reported.

 CompressingStoredFieldsWriter ignores the segment suffix if writing aborted
 ---

 Key: LUCENE-4613
 URL: https://issues.apache.org/jira/browse/LUCENE-4613
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/codecs
Affects Versions: 4.1
Reporter: Renaud Delbru
 Fix For: 4.1

 Attachments: LUCENE-4613.patch, LUCENE-4613.patch, LUCENE-4613.patch


 If the writing is aborted, CompressingStoredFieldsWriter does not remove 
 partially-written files as the segment suffix is not taken into consideration.

--
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-4617) remove FST.pack() method


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

Michael McCandless commented on LUCENE-4617:


+1

 remove FST.pack() method
 

 Key: LUCENE-4617
 URL: https://issues.apache.org/jira/browse/LUCENE-4617
 Project: Lucene - Core
  Issue Type: Sub-task
  Components: core/FSTs
Reporter: Robert Muir
 Attachments: LUCENE-4617.patch


 Current method to make a packed FST:
 1. Create an FST Builder with willPack=true, telling it you are later going 
 to pack() it.
 2. Create your fst with finish() as normal.
 3. Take that fst, and call pack() on it to get another FST.
 This makes no sense. if you pass willPack=true, then I think finish() should 
 just return a packed fst.

--
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-4171) CachingDirectoryFactory should not return any directories after it has been closed.


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

Mark Miller commented on SOLR-4171:
---

You can see that this causes an issue with delete the core's directory on 
unload in a recent test failure.

 CachingDirectoryFactory should not return any directories after it has been 
 closed.
 ---

 Key: SOLR-4171
 URL: https://issues.apache.org/jira/browse/SOLR-4171
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.1, 5.0


 If something like the replication handler gets a directory after the factory 
 has been closed, it may not be closed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-2592) Custom Hashing

2012-12-12 Thread Shawn Heisey (JIRA)


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

Shawn Heisey commented on SOLR-2592:


I use the hot shard concept in Solr 3.5.0.  For the cold shards, I split 
documents using a MOD on the CRC32 hash of a MySQL bigint autoincrement field - 
my MySQL query does the CRC32 and the MOD.  That field's actual value is 
translated to a tlong field in the schema.  For the hot shard, I simply use a 
split point on the actual value of that field.  Everything less than or equal 
to the split point goes to the cold shards, everything greater than the split 
point goes to the hot shard.  Multiple shards are handled by a single Solr 
instance - seven shards live on two servers.

This arrangement requires that I do a daily distribute process where I index 
(from MySQL) data between the old split point and the new split point to the 
cold shards, then delete that data from the hot shard. Full reindexes are done 
with the dataimport handler and controlled by SolrJ, everything else (including 
the distribute) is done directly with SolrJ.

How much of that could be automated and put server-side with the features added 
by this issue?  If I have to track shard and core names myself in order to do 
the distribute, then I will have to decide whether the other automation I would 
gain is worth switching to SolrCloud.

If I could avoid the client-side distribute indexing and have Solr shuffle the 
data around itself, that would be awesome, but I'm not sure that's possible, 
and it may be somewhat complicated by the fact that I have a number of unstored 
fields that I search on.

At some point I will test performance on an index where I do not have a hot 
shard, where the data is simply hashed between several large shards.  This 
entire concept was implemented for fast indexing of new data - because Solr 1.4 
did not have NRT features.


 Custom Hashing
 --

 Key: SOLR-2592
 URL: https://issues.apache.org/jira/browse/SOLR-2592
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud
Affects Versions: 4.0-ALPHA
Reporter: Noble Paul
Assignee: Yonik Seeley
 Fix For: 4.1

 Attachments: dbq_fix.patch, pluggable_sharding.patch, 
 pluggable_sharding_V2.patch, SOLR-2592.patch, SOLR-2592_progress.patch, 
 SOLR-2592_query_try1.patch, SOLR-2592_r1373086.patch, 
 SOLR-2592_r1384367.patch, SOLR-2592_rev_2.patch, 
 SOLR_2592_solr_4_0_0_BETA_ShardPartitioner.patch


 If the data in a cloud can be partitioned on some criteria (say range, hash, 
 attribute value etc) It will be easy to narrow down the search to a smaller 
 subset of shards and in effect can achieve more efficient search.  

--
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-Windows (32bit/jdk1.6.0_37) - Build # 2138 - Still Failing!

2012-12-12 Thread Shawn Heisey


On 12/12/2012 7:43 AM, Mark Miller wrote:

Well, I guess normal depends on who you are - for my machine it's closer to 2 
minutes. If it's 4 minutes for a lot of people, it may make sense to break it 
into 2 sets.

Right now these tests are catching a problem around replication and shutdown 
like I mentioned. The replication test hits the same thing sometimes, but much 
less often.

If you don't use replication, you are right - this probably has no effect on 
you. But they are not SolrCloud specific fails.


I don't use replication or SolrCloud.  If SolrCloud can eventually 
support the way that I divide up my shards and cores (lazily watching 
SOLR-2592), I may one day move to using two separate cloud 
installations.  I've found a lot of value in updating both copies of my 
index independently, so I don't foresee using replication until our 
query volume requires additional servers.


Because these failures are caused by real problems and aren't from buggy 
tests, I'll stop complaining about failures now.  I'd like to have the 
tests run faster, but if that's not possible, it's not possible.  I 
really like what you're saying on SOLR-4169, btw. The idea of separating 
unit tests and integration tests is intriguing.  For the kind of quick 
simple changes that I make myself, I could skip the integration tests, 
but do them when I 'svn up' and before deploying to production.


Thanks,
Shawn


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

[jira] [Commented] (SOLR-4171) CachingDirectoryFactory should not return any directories after it has been closed.


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

Mark Miller commented on SOLR-4171:
---

Im going to change it so that removing a dir persistent storage by path doesn't 
require that the dir factory be open.

 CachingDirectoryFactory should not return any directories after it has been 
 closed.
 ---

 Key: SOLR-4171
 URL: https://issues.apache.org/jira/browse/SOLR-4171
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.1, 5.0


 If something like the replication handler gets a directory after the factory 
 has been closed, it may not be closed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4619) Create a specialized path for facets counting

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

Michael McCandless commented on LUCENE-4619:

bq. You can remove TestDemoFacets from the patch? (since you committed it)

Will do.

bq. DEFAULT_INDEXING_PARAMS is a good idea, but it can change (it's mutable).
However, I plan to add freeze() to it in LUCENE-4621, so maybe update the
nocommit to call freeze() on it?

OK.

bq. Adding the field more than once ... that's tricky. It will of course create
multiple positions, but the entire code now assumes a single position for
facets. Is there any way we can prevent it? I guess not. Maybe put a WARNING
for now?

Yeah I think a big warning in the javadocs is all we can do for now ... would
be nice to somehow catch it but I can't think of a way now.

Separately this duality of dimension/field is sort of confusing. Shouldn't I
be adding FacetField(Author) and FacetField(Publish Date) to my Document?
Instead of a single FacetField taking these two dimensions as
CategoryPaths... I know that's a major change but it's still confusing to my
[somewhat] new eyes ...

{quote}
It should be ok to add it more than once, with different FIParams, e.g.
different CLPs.
I guess that's where CDB simplifies things?
{quote}

Right ... I wouldn't say CDB simplifies things (for the basic usage).

{quote}
The check that you do in the ctor:
I think it can be simplified to just check FIP.getAllCLPs().size() != 1? If so,
throw the exception
Also note that you have a typo in the exception msg
{quote}

OK good! Hmm that's an Iterable ... and ... I don't really want to iterate
over it if I'm iterating over the CPs anyway ... I think? Or maybe we have it
return a List instead? Hmm but this call (in DefaultFIP) makes a new ArrayList
every time ... we should just use Collections.singletonList here ... I'll fix
that. So what to do?

bq. The rest of the code just freaks the hell out of me!

LOL!! Me too :) Trying to figure out how to just get a byte[] out (so I can
do the DocValuesFacetField) is not easy ...

bq. I think that you need the stream because that's the only way to add the
field with the drill-down term and fulltree posting.

OK.

bq. Would rather if that was simplified ... but I don't want to implement a
different TokenStream, not sure there's much value in it.

This TokenStream somehow adds one position w/ the payload (with token
fulltree, if no partitioning I think?), and then provides more tokens so they
are indexed for drilldown?

bq. Still, maybe put a TODO (not nocommit) to check if it can be simplified?

OK will do.

{quote}
BTW, when I look at the test, adding the PayloadFacetField is super neat. I
wonder if we simplified CDB to have less API, then all this would still be
required. E.g.:
{noformat}
ListCPath categories; // you need to prepare that w/ PayloadFacetField too!
Document doc = new Document();
cdb.addFields(doc, categories);
{noformat}
It's not a Field, but it works w/ multiple CLPs and all (basically the code
today). Only you don't need to set the categories. It can also mask in the
future the case where we put the fulltree under one field and the terms under
another, or everything as a DV ... What do you think?
{quote}
I think that's a step in the right direction ... but I think a FacetField is
even easier to consume?

bq. Sorry that I don't fix the patch myself, but I'm rather short on time now.
I can do it later. I'm also going to tackle LUCENE-4621 now.

No prob, I'll fix.

I'm also working on hacked up DocValuesFacetField. Wait til you see how I get
the byte[] to feed to DV :)

Create a specialized path for facets counting
-

Key: LUCENE-4619
URL: https://issues.apache.org/jira/browse/LUCENE-4619
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Shai Erera
Attachments: LUCENE-4619.patch

[jira] [Commented] (LUCENE-4619) Create a specialized path for facets counting

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

Shai Erera commented on LUCENE-4619:

Let's leave the ctor for now, I'll make sure that FIP returns the right API in
LUCENE-4621. Iterable is great, but I think that we can risk a List? ;).

I thought about the FacetsField more. FacetsField is not really a field, right?
You cannot set its FieldType (not critical) and any of Field's set()/get()
methods are just in the way when you look at it. Also, it cannot actually
create two fields (won't be needed hopefully w/ DV), and adding the same
FacetsField twice w/ different categories will create multiple positions, which
is something that I'm not sure we should introduce.

So maybe we improve CDB's API to make it more approachable? I.e., for reusing
FacetsField you'd have to add setCPs to it? That's really like CDB. The only
different that remains then is the ability to Document.add(new FacetsField) vs.
CDB.addFields(Document).

You could do new FacetsField(Author), but that doesn't simplify a lot I
think? I.e. you could still add the same field twice. And thinking about the
faceted search apps that I wrote, I don't always know which facets I'm going to
add. Sometimes I just get a list of CPs (read them from JSON, XML, programmatic
API) and I add them all in one shot. Starting to break that into fields will be
a mess.

While we could always say let's add FacetsField for the common people and keep
CDB for the crazy ones, I prefer if there was one entry point. It's also
easier down the line to make changes / fix bugs?

And that that CDB is a Builder, lets you do iw.addDocument(cdb.addFields(new
Document())), ain't that awesome !? :)

I mean in the end of the day, CDB is not of type Field. But though FacetsField
is, it's very limited and app has to excess more logic when dealing with it.
Vs. CDB where you just call addFields(CPs, doc)?

Create a specialized path for facets counting
-

Key: LUCENE-4619
URL: https://issues.apache.org/jira/browse/LUCENE-4619
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Shai Erera
Attachments: LUCENE-4619.patch

-
To unsubscribe, e-mail:

[jira] [Commented] (SOLR-4169) The test suite should consistently pass

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

Robert Muir commented on SOLR-4169:
---

By the way: I want to make sure its clear I'm not trying to blame Mark here.

I suspect he takes some of this personally because he is the main guy actually
working on fixing these problems.

I just opened an issue for the general problem that we need to stabilize the
solr test suite so we can trust it.

Part of that means that more people than Mark have to somehow be involved
fixing this stuff.

The test suite should consistently pass
---

Key: SOLR-4169
URL: https://issues.apache.org/jira/browse/SOLR-4169
Project: Solr
Issue Type: Bug
Components: Tests
Reporter: Robert Muir
Priority: Blocker
Fix For: 4.1

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

[jira] [Updated] (SOLR-4171) CachingDirectoryFactory should not return any directories after it has been closed.


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

Mark Miller updated SOLR-4171:
--

Attachment: SOLR-4171.patch

patch with the change

 CachingDirectoryFactory should not return any directories after it has been 
 closed.
 ---

 Key: SOLR-4171
 URL: https://issues.apache.org/jira/browse/SOLR-4171
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.1, 5.0

 Attachments: SOLR-4171.patch


 If something like the replication handler gets a directory after the factory 
 has been closed, it may not be closed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4613) CompressingStoredFieldsWriter ignores the segment suffix if writing aborted


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

Commit Tag Bot commented on LUCENE-4613:


[trunk commit] Adrien Grand
http://svn.apache.org/viewvc?view=revisionrevision=1420907

LUCENE-4613: CompressingStoredFieldsFormat: fix .abort() when the segment 
suffix is not empty.



 CompressingStoredFieldsWriter ignores the segment suffix if writing aborted
 ---

 Key: LUCENE-4613
 URL: https://issues.apache.org/jira/browse/LUCENE-4613
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/codecs
Affects Versions: 4.1
Reporter: Renaud Delbru
 Fix For: 4.1

 Attachments: LUCENE-4613.patch, LUCENE-4613.patch, LUCENE-4613.patch


 If the writing is aborted, CompressingStoredFieldsWriter does not remove 
 partially-written files as the segment suffix is not taken into consideration.

--
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-4619) Create a specialized path for facets counting

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

Michael McCandless commented on LUCENE-4619:

Maybe if we rename CDB to FacetsDocumentBuilder, move it to oal.document, make
it a single method call for the user (FDB.addFields), that's good enough
progress for the common case for now?

I still don't like this field/dimension duality: it feels like the facet module
is hiding what should be separate fields, within a single Lucene field. If I
need to store these fields (because I want to present them in the the UI), I'm
already adding them as separate fields.

I think doc.add(new FacetField(...)) is more intuitive than fdb.addFields(doc,
) for a the common/basic use case... but at least improving CDB here would
be progress.

Create a specialized path for facets counting
-

Key: LUCENE-4619
URL: https://issues.apache.org/jira/browse/LUCENE-4619
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Shai Erera
Attachments: LUCENE-4619.patch

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

[jira] [Closed] (LUCENE-4613) CompressingStoredFieldsWriter ignores the segment suffix if writing aborted

2012-12-12 Thread Adrien Grand (JIRA)


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

Adrien Grand closed LUCENE-4613.


Resolution: Fixed
  Assignee: Adrien Grand

I just committed. Thank you Renaud!

 CompressingStoredFieldsWriter ignores the segment suffix if writing aborted
 ---

 Key: LUCENE-4613
 URL: https://issues.apache.org/jira/browse/LUCENE-4613
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/codecs
Affects Versions: 4.1
Reporter: Renaud Delbru
Assignee: Adrien Grand
 Fix For: 4.1

 Attachments: LUCENE-4613.patch, LUCENE-4613.patch, LUCENE-4613.patch


 If the writing is aborted, CompressingStoredFieldsWriter does not remove 
 partially-written files as the segment suffix is not taken into consideration.

--
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-4613) CompressingStoredFieldsWriter ignores the segment suffix if writing aborted


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

Commit Tag Bot commented on LUCENE-4613:


[branch_4x commit] Adrien Grand
http://svn.apache.org/viewvc?view=revisionrevision=1420913

LUCENE-4613: CompressingStoredFieldsFormat: fix .abort() when the segment 
suffix is not empty (merged from r1420907).



 CompressingStoredFieldsWriter ignores the segment suffix if writing aborted
 ---

 Key: LUCENE-4613
 URL: https://issues.apache.org/jira/browse/LUCENE-4613
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/codecs
Affects Versions: 4.1
Reporter: Renaud Delbru
Assignee: Adrien Grand
 Fix For: 4.1

 Attachments: LUCENE-4613.patch, LUCENE-4613.patch, LUCENE-4613.patch


 If the writing is aborted, CompressingStoredFieldsWriter does not remove 
 partially-written files as the segment suffix is not taken into consideration.

--
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-4171) CachingDirectoryFactory should not return any directories after it has been closed.


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

Commit Tag Bot commented on SOLR-4171:
--

[trunk commit] Mark Robert Miller
http://svn.apache.org/viewvc?view=revisionrevision=1420911

SOLR-4171: add a new release(path) method that can be called after factory 
shutdown and have unload core use it to remove a directory after a core has 
been shutdown


 CachingDirectoryFactory should not return any directories after it has been 
 closed.
 ---

 Key: SOLR-4171
 URL: https://issues.apache.org/jira/browse/SOLR-4171
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.1, 5.0

 Attachments: SOLR-4171.patch


 If something like the replication handler gets a directory after the factory 
 has been closed, it may not be closed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4174) If you merge an index, it should drop the current updatelog as it won't be valid anymore.

Mark Miller created SOLR-4174:
-

 Summary: If you merge an index, it should drop the current 
updatelog as it won't be valid anymore.
 Key: SOLR-4174
 URL: https://issues.apache.org/jira/browse/SOLR-4174
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.1, 5.0




--
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-4136) SolrCloud bugs when servlet context contains / or _

2012-12-12 Thread Hoss Man (JIRA)


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

Hoss Man updated SOLR-4136:
---

Fix Version/s: 5.0
   4.1

FYI: staled on backporting due to other test instabilities on 4x at the moment 
... i don't wnat to risk making the situation worse.

 SolrCloud bugs when servlet context contains / or _
 ---

 Key: SOLR-4136
 URL: https://issues.apache.org/jira/browse/SOLR-4136
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.1, 5.0

 Attachments: SOLR-4136.patch, SOLR-4136.patch, SOLR-4136.patch, 
 SOLR-4136.patch, SOLR-4136.patch


 SolrCloud does not work properly with non-trivial values for hostContext 
 (ie: the servlet context path).  In particular...
 * Using a hostContext containing a  / (ie: a servlet context with a subdir 
 path, semi-common among people who organize webapps hierarchically for lod 
 blanacer rules) is explicitly forbidden in ZkController because of how the 
 hostContext is used to build a ZK nodeName
 * Using a hostContext containing a \_ causes problems in 
 OverseerCollectionProcessor where it assumes all \_ characters should be 
 converted to / to reconstitute a URL from nodeName (NOTE: this code 
 specifically has a TODO to fix this, and then has a subsequent TODO about 
 assuming http://; labeled this sucks)

--
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-4136) SolrCloud bugs when servlet context contains / or _


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

Mark Miller commented on SOLR-4136:
---

Good call. Looks like Yonik is merging back some critical work in 5x that will 
help with those fails.

When doing the Directory first class issue, some of the changes actually 
introduced a bunch of fails that i fixed on 5x.

Somehow, some similar issues seem to have been recently exposed on 4x - but the 
fixes (both test and core code) are not there yet.

I'm holding off on back porting to 4x until this merge up is complete.

 SolrCloud bugs when servlet context contains / or _
 ---

 Key: SOLR-4136
 URL: https://issues.apache.org/jira/browse/SOLR-4136
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.1, 5.0

 Attachments: SOLR-4136.patch, SOLR-4136.patch, SOLR-4136.patch, 
 SOLR-4136.patch, SOLR-4136.patch


 SolrCloud does not work properly with non-trivial values for hostContext 
 (ie: the servlet context path).  In particular...
 * Using a hostContext containing a  / (ie: a servlet context with a subdir 
 path, semi-common among people who organize webapps hierarchically for lod 
 blanacer rules) is explicitly forbidden in ZkController because of how the 
 hostContext is used to build a ZK nodeName
 * Using a hostContext containing a \_ causes problems in 
 OverseerCollectionProcessor where it assumes all \_ characters should be 
 converted to / to reconstitute a URL from nodeName (NOTE: this code 
 specifically has a TODO to fix this, and then has a subsequent TODO about 
 assuming http://; labeled this sucks)

--
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] (SOLR-4136) SolrCloud bugs when servlet context contains / or _

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

Mark Miller edited comment on SOLR-4136 at 12/12/12 7:44 PM:
-

Good call. Looks like Yonik is merging back some critical work in 5x that will
help with those fails.

When doing the Directory first class issue, some of the changes actually
-introduced-/exposed a bunch of fails that i fixed on 5x.

Somehow, some similar issues seem to have been recently exposed on 4x - but the
fixes (both test and core code) are not there yet.

I'm holding off on back porting to 4x until this merge up is complete.

was (Author: markrmil...@gmail.com):
Good call. Looks like Yonik is merging back some critical work in 5x that
will help with those fails.

When doing the Directory first class issue, some of the changes actually
introduced a bunch of fails that i fixed on 5x.

Somehow, some similar issues seem to have been recently exposed on 4x - but the
fixes (both test and core code) are not there yet.

I'm holding off on back porting to 4x until this merge up is complete.

SolrCloud bugs when servlet context contains / or _
---

Key: SOLR-4136
URL: https://issues.apache.org/jira/browse/SOLR-4136
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Reporter: Hoss Man
Assignee: Hoss Man
Fix For: 4.1, 5.0

Attachments: SOLR-4136.patch, SOLR-4136.patch, SOLR-4136.patch,
SOLR-4136.patch, SOLR-4136.patch

SolrCloud does not work properly with non-trivial values for hostContext
(ie: the servlet context path). In particular...
* Using a hostContext containing a / (ie: a servlet context with a subdir
path, semi-common among people who organize webapps hierarchically for lod
blanacer rules) is explicitly forbidden in ZkController because of how the
hostContext is used to build a ZK nodeName
* Using a hostContext containing a \_ causes problems in
OverseerCollectionProcessor where it assumes all \_ characters should be
converted to / to reconstitute a URL from nodeName (NOTE: this code
specifically has a TODO to fix this, and then has a subsequent TODO about
assuming http://; labeled this sucks)

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

[jira] [Commented] (LUCENE-4618) reproducable failure of TestMaxFailuresRule


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

Commit Tag Bot commented on LUCENE-4618:


[trunk commit] Chris M. Hostetter
http://svn.apache.org/viewvc?view=revisionrevision=1420941

LUCENE-4618: fix test to not be so lucky about avoiding failures when we 
actually want them


 reproducable failure of TestMaxFailuresRule
 ---

 Key: LUCENE-4618
 URL: https://issues.apache.org/jira/browse/LUCENE-4618
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Dawid Weiss
 Attachments: LUCENE-4618.patch


 james mentioned on the dev list that TestMaxFailuresRule fails reliable for 
 him on multiple platforms when using 
 -Dtests.seed=3FACDC7EBD23CB80:3D65D783617F94F1
 I was able to reproduce on my linux box as of trunk r1420486.

--
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-4618) reproducable failure of TestMaxFailuresRule

2012-12-12 Thread Hoss Man (JIRA)


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

Hoss Man resolved LUCENE-4618.
--

   Resolution: Fixed
Fix Version/s: 5.0
   4.1
 Assignee: Hoss Man  (was: Dawid Weiss)

Thanks for reviewing Dawid.

Committed revision 1420941.
Committed revision 1420943.

(didn't bother with CHANGES.txt)

 reproducable failure of TestMaxFailuresRule
 ---

 Key: LUCENE-4618
 URL: https://issues.apache.org/jira/browse/LUCENE-4618
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.1, 5.0

 Attachments: LUCENE-4618.patch


 james mentioned on the dev list that TestMaxFailuresRule fails reliable for 
 him on multiple platforms when using 
 -Dtests.seed=3FACDC7EBD23CB80:3D65D783617F94F1
 I was able to reproduce on my linux box as of trunk r1420486.

--
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-4618) reproducable failure of TestMaxFailuresRule


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

Commit Tag Bot commented on LUCENE-4618:


[branch_4x commit] Chris M. Hostetter
http://svn.apache.org/viewvc?view=revisionrevision=1420943

LUCENE-4618: fix test to not be so lucky about avoiding failures when we 
actually want them (merge r1420941)


 reproducable failure of TestMaxFailuresRule
 ---

 Key: LUCENE-4618
 URL: https://issues.apache.org/jira/browse/LUCENE-4618
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.1, 5.0

 Attachments: LUCENE-4618.patch


 james mentioned on the dev list that TestMaxFailuresRule fails reliable for 
 him on multiple platforms when using 
 -Dtests.seed=3FACDC7EBD23CB80:3D65D783617F94F1
 I was able to reproduce on my linux box as of trunk r1420486.

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

Welcome Sami Siren to the PMC

2012-12-12 Thread Mark Miller

I'm please to announce that Sami Siren has accepted the PMC's
invitation to join.

Welcome Sami!

- Mark

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

[jira] [Updated] (LUCENE-4617) remove FST.pack() method


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

Robert Muir updated LUCENE-4617:


Attachment: LUCENE-4617.patch

updated patch with fixed javadocs and fixing some tests (still calling the 
pkg-private pack before).

I think its ready

 remove FST.pack() method
 

 Key: LUCENE-4617
 URL: https://issues.apache.org/jira/browse/LUCENE-4617
 Project: Lucene - Core
  Issue Type: Sub-task
  Components: core/FSTs
Reporter: Robert Muir
 Attachments: LUCENE-4617.patch, LUCENE-4617.patch


 Current method to make a packed FST:
 1. Create an FST Builder with willPack=true, telling it you are later going 
 to pack() it.
 2. Create your fst with finish() as normal.
 3. Take that fst, and call pack() on it to get another FST.
 This makes no sense. if you pass willPack=true, then I think finish() should 
 just return a packed fst.

--
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-4.x-Linux (32bit/jdk1.6.0_37) - Build # 3189 - Still Failing!

2012-12-12 Thread Policeman Jenkins Server

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/3189/
Java: 32bit/jdk1.6.0_37 -server -XX:+UseParallelGC

1 tests failed.
REGRESSION:  
org.apache.lucene.codecs.compressing.TestCompressingStoredFieldsFormat.testDeletePartiallyWrittenFilesIfAbort

Error Message:
expected:2 but was:0

Stack Trace:
java.lang.AssertionError: expected:2 but was:0
at 
__randomizedtesting.SeedInfo.seed([3CD76ABF62B468ED:63F777E803714901]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.lucene.codecs.compressing.TestCompressingStoredFieldsFormat.testDeletePartiallyWrittenFilesIfAbort(TestCompressingStoredFieldsFormat.java:398)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:841)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:662)




Build Log:
[...truncated 300 lines...]
[junit4:junit4] Suite:

Re: Welcome Sami Siren to the PMC

2012-12-12 Thread Michael McCandless

Welcome Sami!

Mike McCandless

http://blog.mikemccandless.com


On Wed, Dec 12, 2012 at 3:17 PM, Mark Miller markrmil...@gmail.com wrote:
 I'm please to announce that Sami Siren has accepted the PMC's
 invitation to join.

 Welcome Sami!

 - Mark

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


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

Re: Welcome Sami Siren to the PMC

2012-12-12 Thread Dawid Weiss

Welcome Sami!

Dawid

On Wed, Dec 12, 2012 at 9:22 PM, Michael McCandless
luc...@mikemccandless.com wrote:
 Welcome Sami!

 Mike McCandless

 http://blog.mikemccandless.com


 On Wed, Dec 12, 2012 at 3:17 PM, Mark Miller markrmil...@gmail.com wrote:
 I'm please to announce that Sami Siren has accepted the PMC's
 invitation to join.

 Welcome Sami!

 - Mark

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


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


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

Re: Welcome Sami Siren to the PMC

2012-12-12 Thread Otis Gospodnetic

Welcome Suomi! ;)

Otis




On Wed, Dec 12, 2012 at 3:17 PM, Mark Miller markrmil...@gmail.com wrote:

 I'm please to announce that Sami Siren has accepted the PMC's
 invitation to join.

 Welcome Sami!

 - Mark

 -
 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 (32bit/jdk1.6.0_37) - Build # 3189 - Still Failing!

2012-12-12 Thread Robert Muir

3.x codec i think it also got Thai

On Wed, Dec 12, 2012 at 3:21 PM, Policeman Jenkins Server
jenk...@sd-datasolutions.de wrote:
 Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/3189/
 Java: 32bit/jdk1.6.0_37 -server -XX:+UseParallelGC

 1 tests failed.
 REGRESSION:  
 org.apache.lucene.codecs.compressing.TestCompressingStoredFieldsFormat.testDeletePartiallyWrittenFilesIfAbort

 Error Message:
 expected:2 but was:0

 Stack Trace:
 java.lang.AssertionError: expected:2 but was:0
 at 
 __randomizedtesting.SeedInfo.seed([3CD76ABF62B468ED:63F777E803714901]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at org.junit.Assert.assertEquals(Assert.java:456)
 at 
 org.apache.lucene.codecs.compressing.TestCompressingStoredFieldsFormat.testDeletePartiallyWrittenFilesIfAbort(TestCompressingStoredFieldsFormat.java:398)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:841)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
 at 
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at

[jira] [Commented] (LUCENE-4617) remove FST.pack() method


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

Michael McCandless commented on LUCENE-4617:


+1

 remove FST.pack() method
 

 Key: LUCENE-4617
 URL: https://issues.apache.org/jira/browse/LUCENE-4617
 Project: Lucene - Core
  Issue Type: Sub-task
  Components: core/FSTs
Reporter: Robert Muir
 Attachments: LUCENE-4617.patch, LUCENE-4617.patch


 Current method to make a packed FST:
 1. Create an FST Builder with willPack=true, telling it you are later going 
 to pack() it.
 2. Create your fst with finish() as normal.
 3. Take that fst, and call pack() on it to get another FST.
 This makes no sense. if you pass willPack=true, then I think finish() should 
 just return a packed fst.

--
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 (64bit/jdk1.8.0-ea-b65) - Build # 3199 - Failure!

2012-12-12 Thread Policeman Jenkins Server

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3199/
Java: 64bit/jdk1.8.0-ea-b65 -XX:+UseG1GC

1 tests failed.
REGRESSION:  
org.apache.lucene.codecs.compressing.TestCompressingStoredFieldsFormat.testDeletePartiallyWrittenFilesIfAbort

Error Message:
expected:2 but was:0

Stack Trace:
java.lang.AssertionError: expected:2 but was:0
at 
__randomizedtesting.SeedInfo.seed([24C9A5A7AABC331:5D6C870D1B6EE2DD]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.lucene.codecs.compressing.TestCompressingStoredFieldsFormat.testDeletePartiallyWrittenFilesIfAbort(TestCompressingStoredFieldsFormat.java:399)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:474)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:841)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:722)




Build Log:
[...truncated 1176 lines...]
[junit4:junit4] Suite: 
org.apache.lucene.codecs.compressing.TestCompressingStoredFieldsFormat

[jira] [Commented] (LUCENE-4617) remove FST.pack() method


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

Commit Tag Bot commented on LUCENE-4617:


[trunk commit] Robert Muir
http://svn.apache.org/viewvc?view=revisionrevision=1420951

LUCENE-4617: remove fst.pack method


 remove FST.pack() method
 

 Key: LUCENE-4617
 URL: https://issues.apache.org/jira/browse/LUCENE-4617
 Project: Lucene - Core
  Issue Type: Sub-task
  Components: core/FSTs
Reporter: Robert Muir
 Attachments: LUCENE-4617.patch, LUCENE-4617.patch


 Current method to make a packed FST:
 1. Create an FST Builder with willPack=true, telling it you are later going 
 to pack() it.
 2. Create your fst with finish() as normal.
 3. Take that fst, and call pack() on it to get another FST.
 This makes no sense. if you pass willPack=true, then I think finish() should 
 just return a packed fst.

--
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: Welcome Sami Siren to the PMC

2012-12-12 Thread Robert Muir

Welcome Sami!

On Wed, Dec 12, 2012 at 3:17 PM, Mark Miller markrmil...@gmail.com wrote:
 I'm please to announce that Sami Siren has accepted the PMC's
 invitation to join.

 Welcome Sami!

 - Mark

 -
 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-4617) remove FST.pack() method


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

Commit Tag Bot commented on LUCENE-4617:


[trunk commit] Robert Muir
http://svn.apache.org/viewvc?view=revisionrevision=1420955

LUCENE-4617: willPackFST - doPackFST


 remove FST.pack() method
 

 Key: LUCENE-4617
 URL: https://issues.apache.org/jira/browse/LUCENE-4617
 Project: Lucene - Core
  Issue Type: Sub-task
  Components: core/FSTs
Reporter: Robert Muir
 Attachments: LUCENE-4617.patch, LUCENE-4617.patch


 Current method to make a packed FST:
 1. Create an FST Builder with willPack=true, telling it you are later going 
 to pack() it.
 2. Create your fst with finish() as normal.
 3. Take that fst, and call pack() on it to get another FST.
 This makes no sense. if you pass willPack=true, then I think finish() should 
 just return a packed fst.

--
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-4617) remove FST.pack() method