date:20140720

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/10735/
Java: 32bit/jdk1.8.0_11 -client -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 52040 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:467: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:406: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:87: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:179: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* 
./solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/TestJdbcDataSourceConvertType.java

Total time: 110 minutes 31 seconds
Build step 'Invoke Ant' marked build as failure
[description-setter] Description set: Java: 32bit/jdk1.8.0_11 -client 
-XX:+UseConcMarkSweepGC
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.8.0) - Build # 1687 - Failure!

2014-07-20 Thread ASF subversion and git services (JIRA)

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1687/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 59025 lines...]
BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/build.xml:467: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/build.xml:406: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/extra-targets.xml:87: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/extra-targets.xml:179: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* 
./solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/TestJdbcDataSourceConvertType.java

Total time: 184 minutes 35 seconds
Build step 'Invoke Ant' marked build as failure
[description-setter] Description set: Java: 64bit/jdk1.8.0 
-XX:+UseCompressedOops -XX:+UseParallelGC
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory

2014-07-20 Thread Upayavira (JIRA)


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

Upayavira commented on SOLR-3619:
-

As someone who teaches people how to use Solr, I think the contents of this 
ticket is very useful and necessary.

As someone who likes automation, I find it a little scary. Changing the 
directory structure as substantially as is proposed in a minor release to me 
kinda gives the wrong message.

My preference would be to accept that version numbers are cheap, this is 
incompatible, so release it soon in 5.0. Folks will then expect some back 
incompatibility, so all is good.

 Rename 'example' dir to 'server' and pull examples into an 'examples' 
 directory
 ---

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

 Attachments: SOLR-3619.patch, server-name-layout.png






--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[JENKINS] Lucene-Solr-NightlyTests-4.x - Build # 581 - Still Failing

2014-07-20 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-4.x/581/

All tests passed

Build Log:
[...truncated 60277 lines...]
BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/build.xml:474:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/build.xml:406:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/extra-targets.xml:87:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/extra-targets.xml:179:
 The following files are missing svn:eol-style (or binary svn:mime-type):
* 
./solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/TestJdbcDataSourceConvertType.java

Total time: 291 minutes 29 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Sending artifact delta relative to Lucene-Solr-NightlyTests-4.x #577
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 464 bytes
Compression is 0.0%
Took 19 ms
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Commented] (LUCENE-5815) Add TermAutomatonQuery, for proximity matching that generalizes MultiPhraseQuery/SpanNearQuery

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

ASF subversion and git services commented on LUCENE-5815:
-

Commit 1612076 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1612076 ]

LUCENE-5815: add TermAutomatonQuery

Add TermAutomatonQuery, for proximity matching that generalizes
MultiPhraseQuery/SpanNearQuery
--

Key: LUCENE-5815
URL: https://issues.apache.org/jira/browse/LUCENE-5815
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 4.10

Attachments: LUCENE-5815.patch, LUCENE-5815.patch

I created a new query, called TermAutomatonQuery, that's a proximity
query to generalize MultiPhraseQuery/SpanNearQuery: it lets you
construct an arbitrary automaton whose transitions are whole terms, and
then find all documents that the automaton matches. This is different
from a normal automaton whose transitions are usually
bytes/characters within a term/s.
So, if the automaton has just 1 transition, it's just an expensive
TermQuery. If you have two transitions in sequence, it's a phrase
query of two terms. You can express synonyms by using transitions
that overlap one another but the automaton doesn't have to be a
sausage (as MultiPhraseQuery requires) i.e. it respects posLength
(at query time).
It also allows any transitions, to match any term, so you can do
sloppy matching and span-like queries, e.g. find lucene and python
with up to 3 other terms in between.
I also added a class to convert a TokenStream directly to the
automaton for this query, preserving posLength. (Of course, the index
can't store posLength, so the matching won't be fully correct if any
indexed tokens has posLength != 1). But if you do query-time-only
synonyms then the matching should finally be correct.
I haven't tested performance but I suspect it's quite slowish ... its
cost is O(sum-totalTF) of all terms used in the automaton. There
are some optimizations we could do, e.g. detecting that some terms in
the automaton can be upgraded to MUST (right now they are all
effectively SHOULD).
I'm not sure how it should assign scores (punted on that for now), but
the matching seems to be working.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5815) Add TermAutomatonQuery, for proximity matching that generalizes MultiPhraseQuery/SpanNearQuery

2014-07-20 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on LUCENE-5815:
-

Commit 1612077 from [~mikemccand] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1612077 ]

LUCENE-5815: add TermAutomatonQuery

Add TermAutomatonQuery, for proximity matching that generalizes
MultiPhraseQuery/SpanNearQuery
--

Key: LUCENE-5815
URL: https://issues.apache.org/jira/browse/LUCENE-5815
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 5.0, 4.10

Attachments: LUCENE-5815.patch, LUCENE-5815.patch

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Resolved] (LUCENE-5815) Add TermAutomatonQuery, for proximity matching that generalizes MultiPhraseQuery/SpanNearQuery

2014-07-20 Thread Michael McCandless (JIRA)

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

Michael McCandless resolved LUCENE-5815.

Resolution: Fixed
Fix Version/s: 5.0

Add TermAutomatonQuery, for proximity matching that generalizes
MultiPhraseQuery/SpanNearQuery
--

Key: LUCENE-5815
URL: https://issues.apache.org/jira/browse/LUCENE-5815
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 5.0, 4.10

Attachments: LUCENE-5815.patch, LUCENE-5815.patch

--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
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.8.0_20-ea-b23) - Build # 10736 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/10736/
Java: 32bit/jdk1.8.0_20-ea-b23 -server -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 52001 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:467: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:406: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:87: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:179: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* 
./solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/TestJdbcDataSourceConvertType.java

Total time: 100 minutes 28 seconds
Build step 'Invoke Ant' marked build as failure
[description-setter] Description set: Java: 32bit/jdk1.8.0_20-ea-b23 -server 
-XX:+UseParallelGC
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Updated] (LUCENE-5801) Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader

2014-07-20 Thread ASF subversion and git services (JIRA)


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

Shai Erera updated LUCENE-5801:
---

Attachment: LUCENE-5801.patch

Patch fixes the problem. We need to take the source FacetsConfig in 
OrdinalMappingAtomicReader and then of course only wrap the BinaryDV fields 
that were indexed with facets. I also improved the test to make sure we only 
touch facet fields by OrdinalMappingAtomicReader.

 Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 -

 Key: LUCENE-5801
 URL: https://issues.apache.org/jira/browse/LUCENE-5801
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 4.7
Reporter: Nicola Buso
Assignee: Shai Erera
 Fix For: 5.0, 4.10

 Attachments: LUCENE-5801.patch, LUCENE-5801.patch, LUCENE-5801.patch, 
 LUCENE-5801_1.patch, LUCENE-5801_2.patch


 from lucene  4.6.1 the class:
 org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 was removed; resurrect it because used merging indexes related to merged 
 taxonomies.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5801) Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader


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

ASF subversion and git services commented on LUCENE-5801:
-

Commit 1612079 from [~shaie] in branch 'dev/trunk'
[ https://svn.apache.org/r1612079 ]

LUCENE-5801: OrdinalMappingAtomicReader should not wrap non-facet 
BinaryDocValues fields

 Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 -

 Key: LUCENE-5801
 URL: https://issues.apache.org/jira/browse/LUCENE-5801
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 4.7
Reporter: Nicola Buso
Assignee: Shai Erera
 Fix For: 5.0, 4.10

 Attachments: LUCENE-5801.patch, LUCENE-5801.patch, LUCENE-5801.patch, 
 LUCENE-5801_1.patch, LUCENE-5801_2.patch


 from lucene  4.6.1 the class:
 org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 was removed; resurrect it because used merging indexes related to merged 
 taxonomies.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5819) Add block tree postings format that supports term ords

2014-07-20 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on LUCENE-5819:
-

Commit 1612080 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1612080 ]

LUCENE-5819: add terms dict and postings format that implement term ordinals

 Add block tree postings format that supports term ords
 --

 Key: LUCENE-5819
 URL: https://issues.apache.org/jira/browse/LUCENE-5819
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/other
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 5.0, 4.10

 Attachments: LUCENE-5819.patch, LUCENE-5819.patch


 BlockTree is our default terms dictionary today, but it doesn't
 support term ords, which is an optional API in the postings format to
 retrieve the ordinal for the currently seek'd term, and also later
 seek by that ordinal e.g. to lookup the term.
 This can possibly be useful for e.g. faceting, and maybe at some point
 we can share the postings terms dict with the one used by sorted/set
 DV for cases when app wants to invert and facet on a given field.
 The older (3.x) block terms dict can easily support ords, and we have
 a Lucene41OrdsPF in test-framework, but it's not as fast / compact as
 block-tree, and doesn't (can't easily) implement an optimized
 intersect, but it could be for fields we'd want to facet on, these
 tradeoffs don't matter.  It's nice to have options...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5801) Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader

2014-07-20 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on LUCENE-5801:
-

Commit 1612081 from [~shaie] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1612081 ]

LUCENE-5801: OrdinalMappingAtomicReader should not wrap non-facet 
BinaryDocValues fields

 Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 -

 Key: LUCENE-5801
 URL: https://issues.apache.org/jira/browse/LUCENE-5801
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 4.7
Reporter: Nicola Buso
Assignee: Shai Erera
 Fix For: 5.0, 4.10

 Attachments: LUCENE-5801.patch, LUCENE-5801.patch, LUCENE-5801.patch, 
 LUCENE-5801_1.patch, LUCENE-5801_2.patch


 from lucene  4.6.1 the class:
 org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 was removed; resurrect it because used merging indexes related to merged 
 taxonomies.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5801) Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader


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

Shai Erera commented on LUCENE-5801:


Committed this fix. Please report if you still encounter problems.

 Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 -

 Key: LUCENE-5801
 URL: https://issues.apache.org/jira/browse/LUCENE-5801
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 4.7
Reporter: Nicola Buso
Assignee: Shai Erera
 Fix For: 5.0, 4.10

 Attachments: LUCENE-5801.patch, LUCENE-5801.patch, LUCENE-5801.patch, 
 LUCENE-5801_1.patch, LUCENE-5801_2.patch


 from lucene  4.6.1 the class:
 org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 was removed; resurrect it because used merging indexes related to merged 
 taxonomies.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5837) Only check docsWithField when necessary in numeric comparators

2014-07-20 Thread Adrien Grand (JIRA)


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

Adrien Grand commented on LUCENE-5837:
--

bq. It is a specialization, because instead of a branch for null, you have a 
branch checking class of the numericdocvalues. and if this one fails, the whole 
thing gets deoptimized and hotspot goes crazy.

Doesn't it happen already if you have two fields that have different 
compression?

 Only check docsWithField when necessary in numeric comparators
 --

 Key: LUCENE-5837
 URL: https://issues.apache.org/jira/browse/LUCENE-5837
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 5.0, 4.10

 Attachments: LUCENE-5837.patch, LUCENE-5837.patch


 Our numeric comparators have branches to deal with missing values. However 
 there are some cases when checking docs that have a field is not useful:
  - if all docs have a value
  - if no docs have a value
  - if the missing value is 0



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory

2014-07-20 Thread Timothy Potter (JIRA)


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

Timothy Potter commented on SOLR-3619:
--

bq. I don't think so. Having this 'collection1' is just odd. You want to rename 
it right away.

+1 ... Let's not forget how weird collection1 makes starting up Solr in cloud 
mode the first time with the -Dbootstrap_confdir=./solr/collection1/conf 
-Dcollection.configName=myconf stuff (plus you never use those flags again 
when adding new collections to a cluster). I think having to create a 
collection when getting started with the proposed server directory is quite 
natural, just like you have to do when starting out with a database like mysql.

 Rename 'example' dir to 'server' and pull examples into an 'examples' 
 directory
 ---

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

 Attachments: SOLR-3619.patch, server-name-layout.png






--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5801) Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader

2014-07-20 Thread Littlestar (JIRA)


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

Littlestar commented on LUCENE-5801:


the fixs works failed.
because default $facets not in facetFields.
so merge with wrong result.

the following works ok.
public OrdinalMappingAtomicReader(AtomicReader in, int[] ordinalMap, 
FacetsConfig srcConfig) {
super(in);
this.ordinalMap = ordinalMap;
facetsConfig = new InnerFacetsConfig();
facetFields = new HashSet();
+if (srcConfig.getDimConfigs().size() == 0) {
+facetFields.add(FacetsConfig.DEFAULT_DIM_CONFIG.indexFieldName);
+}
for (DimConfig dc : srcConfig.getDimConfigs().values()) {
  facetFields.add(dc.indexFieldName);
}
  }

 Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 -

 Key: LUCENE-5801
 URL: https://issues.apache.org/jira/browse/LUCENE-5801
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 4.7
Reporter: Nicola Buso
Assignee: Shai Erera
 Fix For: 5.0, 4.10

 Attachments: LUCENE-5801.patch, LUCENE-5801.patch, LUCENE-5801.patch, 
 LUCENE-5801_1.patch, LUCENE-5801_2.patch


 from lucene  4.6.1 the class:
 org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 was removed; resurrect it because used merging indexes related to merged 
 taxonomies.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6260) Rename DirectUpdateHandler2


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

Yonik Seeley commented on SOLR-6260:


 bq. I don't know really what direct means here.

It's right in the class javadoc comment:
{code}
/**
 * codeDirectUpdateHandler2/code implements an UpdateHandler where 
documents are added
 * directly to the main Lucene index as opposed to adding to a separate smaller 
index.
{code}

In general, renames like this can cause more pain than the meager benefits they 
provide.
This would break compatibility for users schemas who are trying to upgrade.

Regarding renaming public APIs in general:
https://issues.apache.org/jira/browse/SOLR-3830?focusedCommentId=13454299page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13454299

Along the lines of collective knowledge, that includes a whole ton of mail 
archives, blogs, books, etc, that refer to this class (or it's shortened name 
DUH2... which actually works to type into the class finder in intellij).


 Rename DirectUpdateHandler2
 ---

 Key: SOLR-6260
 URL: https://issues.apache.org/jira/browse/SOLR-6260
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Attachments: SOLR-6260.patch, SOLR-6260.patch


 DirectUpdateHandler was removed, I think in Solr 4. DirectUpdateHandler2 
 should be renamed, at least remove that 2. I don't know really what 
 direct means here. Maybe it could be renamed to DefaultUpdateHandler, or 
 UpdateHandlerDefaultImpl, or other good suggestions



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5837) Only check docsWithField when necessary in numeric comparators

2014-07-20 Thread Robert Muir (JIRA)


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

Robert Muir commented on LUCENE-5837:
-

I didn't see it happening with the currently assembly generated.

I'm ok with the issue if we see a performance increase, just not seeing it.

 Only check docsWithField when necessary in numeric comparators
 --

 Key: LUCENE-5837
 URL: https://issues.apache.org/jira/browse/LUCENE-5837
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 5.0, 4.10

 Attachments: LUCENE-5837.patch, LUCENE-5837.patch


 Our numeric comparators have branches to deal with missing values. However 
 there are some cases when checking docs that have a field is not useful:
  - if all docs have a value
  - if no docs have a value
  - if the missing value is 0



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Comment Edited] (LUCENE-5801) Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader

2014-07-20 Thread Littlestar (JIRA)


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

Littlestar edited comment on LUCENE-5801 at 7/20/14 2:30 PM:
-

the fixs works failed(no exception throws, but result in wrong facet data).

default $facets not in facetFields.
so merge with wrong result.

the following works ok.
public OrdinalMappingAtomicReader(AtomicReader in, int[] ordinalMap, 
FacetsConfig srcConfig) {
super(in);
this.ordinalMap = ordinalMap;
facetsConfig = new InnerFacetsConfig();
facetFields = new HashSet();
+if (srcConfig.getDimConfigs().size() == 0) {
+facetFields.add(FacetsConfig.DEFAULT_DIM_CONFIG.indexFieldName);
+}
for (DimConfig dc : srcConfig.getDimConfigs().values()) {
  facetFields.add(dc.indexFieldName);
}
  }


was (Author: cnstar9988):
the fixs works failed.
because default $facets not in facetFields.
so merge with wrong result.

the following works ok.
public OrdinalMappingAtomicReader(AtomicReader in, int[] ordinalMap, 
FacetsConfig srcConfig) {
super(in);
this.ordinalMap = ordinalMap;
facetsConfig = new InnerFacetsConfig();
facetFields = new HashSet();
+if (srcConfig.getDimConfigs().size() == 0) {
+facetFields.add(FacetsConfig.DEFAULT_DIM_CONFIG.indexFieldName);
+}
for (DimConfig dc : srcConfig.getDimConfigs().values()) {
  facetFields.add(dc.indexFieldName);
}
  }

 Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 -

 Key: LUCENE-5801
 URL: https://issues.apache.org/jira/browse/LUCENE-5801
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 4.7
Reporter: Nicola Buso
Assignee: Shai Erera
 Fix For: 5.0, 4.10

 Attachments: LUCENE-5801.patch, LUCENE-5801.patch, LUCENE-5801.patch, 
 LUCENE-5801_1.patch, LUCENE-5801_2.patch


 from lucene  4.6.1 the class:
 org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 was removed; resurrect it because used merging indexes related to merged 
 taxonomies.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6260) Rename DirectUpdateHandler2


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

Mark Miller commented on SOLR-6260:
---

At some point you have to start cleaning up ugly baggage though. 5x seems a 
great place to clean this one up.

 Rename DirectUpdateHandler2
 ---

 Key: SOLR-6260
 URL: https://issues.apache.org/jira/browse/SOLR-6260
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Attachments: SOLR-6260.patch, SOLR-6260.patch


 DirectUpdateHandler was removed, I think in Solr 4. DirectUpdateHandler2 
 should be renamed, at least remove that 2. I don't know really what 
 direct means here. Maybe it could be renamed to DefaultUpdateHandler, or 
 UpdateHandlerDefaultImpl, or other good suggestions



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5801) Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader


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

Shai Erera commented on LUCENE-5801:


Actually, this isn't the correct fix. I modified the test to index two 
dimensions, one under custom indexFieldName {{$tags}} and one under the 
default. So facetsConfig.getDimConfigs() returns only the {{$tags}} facets. If 
I add the DEFAULT_INDEX_FIELD_NAME (always) then it solves the problem, but 
then if the app never uses that field name for faceting, but adds it as another 
BDV, we try to map ordinals ... I think it's not very likely that this happens 
though, so I'm willing to go with that fix.

I'm working on a patch with improved test.

 Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 -

 Key: LUCENE-5801
 URL: https://issues.apache.org/jira/browse/LUCENE-5801
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 4.7
Reporter: Nicola Buso
Assignee: Shai Erera
 Fix For: 5.0, 4.10

 Attachments: LUCENE-5801.patch, LUCENE-5801.patch, LUCENE-5801.patch, 
 LUCENE-5801_1.patch, LUCENE-5801_2.patch


 from lucene  4.6.1 the class:
 org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 was removed; resurrect it because used merging indexes related to merged 
 taxonomies.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6260) Rename DirectUpdateHandler2

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

Mark Miller commented on SOLR-6260:
---

bq. the meager benefits

I think if you look at this very narrowly, perhaps it seems meager. But it's
this kind of issue that makes the code unattractive to deal with. Facilitating
the clean up for users that want to fix it will encourage those users to
contribute more. Cleaning up these fairly ugly code warts (I've particularly
been annoyed by this DirectUpdateHandler2) will also help and encourage newer
contributors.

We need to encourage and facilitate cleaning up the crap that we have always
said can't be cleaned up. If we have to compromise on some of it, fine, make it
only in 5x like we did with 4x. But let's not settle for crap because of back
compat. Back compat will sink our ship. It's important to consider, but we
can't let it strangle us. Major releases need to allow freedom to fix at a
minimum.

Rename DirectUpdateHandler2
---

Key: SOLR-6260
URL: https://issues.apache.org/jira/browse/SOLR-6260
Project: Solr
Issue Type: Improvement
Affects Versions: 5.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
Attachments: SOLR-6260.patch, SOLR-6260.patch

DirectUpdateHandler was removed, I think in Solr 4. DirectUpdateHandler2
should be renamed, at least remove that 2. I don't know really what
direct means here. Maybe it could be renamed to DefaultUpdateHandler, or
UpdateHandlerDefaultImpl, or other good suggestions

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (LUCENE-5801) Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader


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

Shai Erera updated LUCENE-5801:
---

Attachment: LUCENE-5801.patch

Patch fixes the problem, but I still want to review the test, make sure it 
covers this index merge end-to-end.

 Resurrect org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 -

 Key: LUCENE-5801
 URL: https://issues.apache.org/jira/browse/LUCENE-5801
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 4.7
Reporter: Nicola Buso
Assignee: Shai Erera
 Fix For: 5.0, 4.10

 Attachments: LUCENE-5801.patch, LUCENE-5801.patch, LUCENE-5801.patch, 
 LUCENE-5801.patch, LUCENE-5801_1.patch, LUCENE-5801_2.patch


 from lucene  4.6.1 the class:
 org.apache.lucene.facet.util.OrdinalMappingAtomicReader
 was removed; resurrect it because used merging indexes related to merged 
 taxonomies.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory

2014-07-20 Thread Jack Krupansky (JIRA)

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

Jack Krupansky commented on SOLR-3619:
--

bq. a database like MySQL

But Solr isn't a database! (Nor is Elasticsearch.)

I think part of the issue here is that there are two distinct use cases: single
core and multi-core, or single collection and multiple collection. Solr is
perfectly usable in single-core/collection mode - the user need not concern
themselves with naming a collection. In that case, the fact that there is this
extra level of abstraction called a collection and it is named collection1
is a bit of an annoyance and distraction, so the less annoying the better.
Forcing the user to come up with a name and perform an extract step of naming
that default collection adds no significant value for the
single-core-collection use case, or the onboarding or introduction of new users
to Solr as a simple but powerful search platform.

Sure, once the user has decided that they indeed have the multi-core/collection
use case, THEN they will want to name their cores/collections with real
names. Sure, by all means make support for this use case as clean and
convenient as possible.

Why not simply give the user a choice, up front, and let them decide for
themselves what use case they want? Whether that is a separate download or a
separate startup command or a separate start directory seems like more of a
detail than an architectural choice for de-supporting one useful use case.

I would say leave the current example where it is, as it is, and have a
separate, clean download for multi-collection server mode. I'm sure people
deploying SolrCloud clusters in the cloud would appreciate the latter, without
any burden of example and tutorial fluff.

And maybe the use case distinction is simply SolrCloud vs. traditional Solr.
And then for the new (5.0) SolrCloud server mode, we can have a little script
for quick demo mode that is more like the current example/collection1 setup -
or a separate example/introduction/tutorial download from the raw server
download.

In short, don't sacrifice the current simplicity, but do pursue the 5.0 server
mode.

Maybe if progress were made on the 5.0 Solr server, some of these details
would just fall out or at least be more obvious and non-controversial.

As it is, this is feeling a lot more like rearranging deck chairs on the
Titanic than helping Solr to leapfrog to a whole new level in either
server-ness or ease-of-use-ness.

BTW, has any thought been given to including a packaging of the 5.0 Solr server
as a Windows service? That might also help to clarify some of this packaging
stuff.

Rename 'example' dir to 'server' and pull examples into an 'examples'
directory
---

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

Attachments: SOLR-3619.patch, server-name-layout.png

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory


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

Mark Miller commented on SOLR-3619:
---

Single core must die. And so must this bad core name.

Solr and ES are databases. We just happen to have a lot better search.

When you have a system that allows multiple collections, you make it easy to 
create one and have the user do it upfront so they know how. You never pretend 
that there is this universal collection unless you want to delete it and go 
into multi collection mode.

That's just silly. This has all been done before, it's not rocket science :)

 Rename 'example' dir to 'server' and pull examples into an 'examples' 
 directory
 ---

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

 Attachments: SOLR-3619.patch, server-name-layout.png






--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory


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

Mark Miller commented on SOLR-3619:
---

bq. I do not disagree with a single thing you say there... Step by step UX, not 
generalizing create a collection bit

Like I said, this issue is not about removing the default collection1. That 
really has no bearing on this issue.

 Rename 'example' dir to 'server' and pull examples into an 'examples' 
 directory
 ---

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

 Attachments: SOLR-3619.patch, server-name-layout.png






--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory


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

Mark Miller commented on SOLR-3619:
---

{quote}
My preference would be to accept that version numbers are cheap, this is 
incompatible, so release it soon in 5.0. Folks will then expect some back 
incompatibility, so all is good.
{quote}

Solr should be developed by doing what is right. Once we have that, you can 
decide where that needs to happen - the next 4x release, the 5x release, with a 
back compat layer, whatever. Coming at it back compat oh my first is why we 
never move. Let's decide how things should be and focus on our energy on making 
it happen, not why it cannot happen.

 Rename 'example' dir to 'server' and pull examples into an 'examples' 
 directory
 ---

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

 Attachments: SOLR-3619.patch, server-name-layout.png






--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Closed] (LUCENE-5837) Only check docsWithField when necessary in numeric comparators

2014-07-20 Thread Adrien Grand (JIRA)


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

Adrien Grand closed LUCENE-5837.


Resolution: Won't Fix

Fair enough

 Only check docsWithField when necessary in numeric comparators
 --

 Key: LUCENE-5837
 URL: https://issues.apache.org/jira/browse/LUCENE-5837
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 5.0, 4.10

 Attachments: LUCENE-5837.patch, LUCENE-5837.patch


 Our numeric comparators have branches to deal with missing values. However 
 there are some cases when checking docs that have a field is not useful:
  - if all docs have a value
  - if no docs have a value
  - if the missing value is 0



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.8.0_11) - Build # 4108 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/4108/
Java: 32bit/jdk1.8.0_11 -server -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 51938 lines...]
BUILD FAILED
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:467: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:406: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\extra-targets.xml:87: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\extra-targets.xml:179: 
The following files are missing svn:eol-style (or binary svn:mime-type):
* 
./solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/TestJdbcDataSourceConvertType.java

Total time: 180 minutes 27 seconds
Build step 'Invoke Ant' marked build as failure
[description-setter] Description set: Java: 32bit/jdk1.8.0_11 -server 
-XX:+UseG1GC
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
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 (64bit/jdk1.7.0_65) - Build # 10737 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/10737/
Java: 64bit/jdk1.7.0_65 -XX:-UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 59799 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:467: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:406: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:87: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:179: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* 
./solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/TestJdbcDataSourceConvertType.java

Total time: 105 minutes 36 seconds
Build step 'Invoke Ant' marked build as failure
[description-setter] Description set: Java: 64bit/jdk1.7.0_65 
-XX:-UseCompressedOops -XX:+UseParallelGC
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Commented] (SOLR-6260) Rename DirectUpdateHandler2


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

Yonik Seeley commented on SOLR-6260:


bq. We need to encourage and facilitate cleaning up the crap

I agree.  But I disagree that a simple rename will accomplish that.

 Rename DirectUpdateHandler2
 ---

 Key: SOLR-6260
 URL: https://issues.apache.org/jira/browse/SOLR-6260
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Attachments: SOLR-6260.patch, SOLR-6260.patch


 DirectUpdateHandler was removed, I think in Solr 4. DirectUpdateHandler2 
 should be renamed, at least remove that 2. I don't know really what 
 direct means here. Maybe it could be renamed to DefaultUpdateHandler, or 
 UpdateHandlerDefaultImpl, or other good suggestions



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6260) Rename DirectUpdateHandler2


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

Yonik Seeley commented on SOLR-6260:


In fact I'd love to see DUH2 / SolrCoreState  and related code refactored and 
cleaned up.  But back compat is not holding us back... the difficulty there is 
correctness I think.  This has to do with the type of code it is.  For example, 
refactoring  changing a faceting/search method is easy - it's deterministic 
without a lot of threading/concurrency concerns and we have random tests for 
correctness.

 Rename DirectUpdateHandler2
 ---

 Key: SOLR-6260
 URL: https://issues.apache.org/jira/browse/SOLR-6260
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Attachments: SOLR-6260.patch, SOLR-6260.patch


 DirectUpdateHandler was removed, I think in Solr 4. DirectUpdateHandler2 
 should be renamed, at least remove that 2. I don't know really what 
 direct means here. Maybe it could be renamed to DefaultUpdateHandler, or 
 UpdateHandlerDefaultImpl, or other good suggestions



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6260) Rename DirectUpdateHandler2


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

Mark Miller commented on SOLR-6260:
---

It's just a part of it. And the pushback against it is the thousand pin pricks 
that have kept so many ugly things around for so long.

When we change big things, the repercussions are never that bad.

When we let newer users that see ugly things change them, we don't discourage 
them and give the impression that it's hard to change ugly stuff and don't even 
bother trying because we will slowly beat you back on each issue.

There is a level of back compat that we support at http that I support 100%. 
Beyond that, we have always been fairly loose really. I've broken an insane 
amount of back compat stuff myself - to get major new features to work or fix 
broken design. A lot of that *in* 3x or 4x, not over a major version. Now we 
have all those advances, and the screams of pain along the way where not heard.

I think, until we are in a better spot code wise, we should favor improvement 
over back compat beyond the http layer. Even in 4x. But good god, for 5x, let 
the flood gates open. It's way too easy to error on stifling the project. We 
need to error way the other way IMO. Until a lot of the baggage is dealt with 
and SolrCloud is first class and in shape, we need to error way the other way. 
If we want to compete as a search engine over the next decade, we need to take 
off the leg weights.

DirectUpdateHandler2 should die. We all know it. Let's let it go.

 Rename DirectUpdateHandler2
 ---

 Key: SOLR-6260
 URL: https://issues.apache.org/jira/browse/SOLR-6260
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Attachments: SOLR-6260.patch, SOLR-6260.patch


 DirectUpdateHandler was removed, I think in Solr 4. DirectUpdateHandler2 
 should be renamed, at least remove that 2. I don't know really what 
 direct means here. Maybe it could be renamed to DefaultUpdateHandler, or 
 UpdateHandlerDefaultImpl, or other good suggestions



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6260) Rename DirectUpdateHandler2

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

Yonik Seeley commented on SOLR-6260:

bq. I've broken an insane amount of back compat stuff myself - to get major new
features to work or fix broken design.

Exactly... back compat is only one factor of many in these decisions.

Looking at this patch specifically, on it's own merits, it doesn't seem worth
it to me.
As far as encouraging new users to make changes, I'd rather encourage them to
make more meaningful changes. If someone wants to refactor DUH2 (or implement
a new one and remove the old one), have at it! I won't stand in the way
because of back compat. Maybe correctness concerns, but not back compat.

Rename DirectUpdateHandler2
---

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6260) Rename DirectUpdateHandler2

2014-07-20 Thread JIRA


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

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

bq. It's right in the class javadoc comment:
I see, I missed that. 
Sorry for my ignorance, but does this comment make sense now? Is it possible in 
Solr to add documents to a different index (other than having a separate core) 
or is this comment outdated?

I agree with Mark, cleaning ugly code should be encouraged, and a class called 
“DirectUpdateHandler2” is an ugly name. I someone new to Solr sees this they 
would ask “Why is it called like this? Why is this ‘2’? Is there another number 
‘1’? does it accomplish the same?”, and responding “It’s for historic reasons” 
is a bad response I think. 

bq. Looking at this patch specifically, on it's own merits, it doesn't seem 
worth it to me.

What does that mean? I can clean the patch if needed. As I said, I did  mostly 
a search and replace, maybe there is more to be done. 

bq. As far as encouraging new users to make changes, I'd rather encourage them 
to make more meaningful changes

I find this change as a step forward, that’s why I suggested it. 


 Rename DirectUpdateHandler2
 ---

 Key: SOLR-6260
 URL: https://issues.apache.org/jira/browse/SOLR-6260
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Attachments: SOLR-6260.patch, SOLR-6260.patch


 DirectUpdateHandler was removed, I think in Solr 4. DirectUpdateHandler2 
 should be renamed, at least remove that 2. I don't know really what 
 direct means here. Maybe it could be renamed to DefaultUpdateHandler, or 
 UpdateHandlerDefaultImpl, or other good suggestions



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6260) Rename DirectUpdateHandler2

2014-07-20 Thread ASF subversion and git services (JIRA)


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

Yonik Seeley commented on SOLR-6260:


bq.  Looking at this patch specifically, on it's own merits, it doesn't seem 
worth it to me.
bq. What does that mean?

It means that the disadvantages of this specific rename outweigh the 
advantages.  I was trying to separate this specific rename from lumping it in 
with a broader fallacy of if we can't change this, then we can't make bigger 
changes.

Of course I fear this thread will again demonstrate Sayre's law ;-)

 Rename DirectUpdateHandler2
 ---

 Key: SOLR-6260
 URL: https://issues.apache.org/jira/browse/SOLR-6260
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Attachments: SOLR-6260.patch, SOLR-6260.patch


 DirectUpdateHandler was removed, I think in Solr 4. DirectUpdateHandler2 
 should be renamed, at least remove that 2. I don't know really what 
 direct means here. Maybe it could be renamed to DefaultUpdateHandler, or 
 UpdateHandlerDefaultImpl, or other good suggestions



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6121) cursorMark should accept sort without the uniqueKey

2014-07-20 Thread JIRA


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

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

+1 I think this is a good idea

 cursorMark should accept sort without the uniqueKey
 ---

 Key: SOLR-6121
 URL: https://issues.apache.org/jira/browse/SOLR-6121
 Project: Solr
  Issue Type: Improvement
Reporter: David Smiley
Priority: Minor

 If you are using the cursorMark (deep paging) feature, you shouldn't *have* 
 to add the uniqueKey to the sort parameter.  If the user doesn't do it, the 
 user obviously doesn't care about the uniqueKey order relative to whatever 
 other sort parameters they may or may not have provided.  So if sort doesn't 
 have it, then Solr should simply tack it on at the end instead of providing 
 an error and potentially confusing the user.  This would be more user 
 friendly.
 Quoting Hoss from 
 [SOLR-5463|https://issues.apache.org/jira/browse/SOLR-5463?focusedCommentId=14011384page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14011384]:
 {quote}
 The reason the code currently throws an error was because i figured it was 
 better to force the user to choose which tie breaker they wanted (asc vs 
 desc) then to just magically pick one arbitrarily.
 If folks think a magic default is a better i've got no serious objections – 
 just open a new issue.
 {quote}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6258) Add onRollback event listener


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

ASF subversion and git services commented on SOLR-6258:
---

Commit 1612124 from [~ehatcher] in branch 'dev/trunk'
[ https://svn.apache.org/r1612124 ]

SOLR-6258: Added onRollback event handler hook to Data Import Handler

 Add onRollback event listener
 -

 Key: SOLR-6258
 URL: https://issues.apache.org/jira/browse/SOLR-6258
 Project: Solr
  Issue Type: Improvement
  Components: contrib - DataImportHandler
Affects Versions: 4.9
Reporter: Erik Hatcher
Assignee: Erik Hatcher
Priority: Minor
 Fix For: 5.0, 4.10

 Attachments: SOLR-6258.txt


 DataImportHandler has onImportStart and onImportEnd.  An onRollback handler 
 is a useful addition.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6258) Add onRollback event listener

2014-07-20 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-6258:
---

Commit 1612126 from [~ehatcher] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1612126 ]

SOLR-6258: Added onRollback event handler hook to Data Import Handler

 Add onRollback event listener
 -

 Key: SOLR-6258
 URL: https://issues.apache.org/jira/browse/SOLR-6258
 Project: Solr
  Issue Type: Improvement
  Components: contrib - DataImportHandler
Affects Versions: 4.9
Reporter: Erik Hatcher
Assignee: Erik Hatcher
Priority: Minor
 Fix For: 5.0, 4.10

 Attachments: SOLR-6258.txt


 DataImportHandler has onImportStart and onImportEnd.  An onRollback handler 
 is a useful addition.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Resolved] (SOLR-6258) Add onRollback event listener

2014-07-20 Thread Erik Hatcher (JIRA)


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

Erik Hatcher resolved SOLR-6258.


Resolution: Fixed

 Add onRollback event listener
 -

 Key: SOLR-6258
 URL: https://issues.apache.org/jira/browse/SOLR-6258
 Project: Solr
  Issue Type: Improvement
  Components: contrib - DataImportHandler
Affects Versions: 4.9
Reporter: Erik Hatcher
Assignee: Erik Hatcher
Priority: Minor
 Fix For: 5.0, 4.10

 Attachments: SOLR-6258.txt


 DataImportHandler has onImportStart and onImportEnd.  An onRollback handler 
 is a useful addition.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6121) cursorMark should accept sort without the uniqueKey


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

Yonik Seeley commented on SOLR-6121:


bq. If folks think a magic default is a better i've got no serious objections

+1, I don't think there's much to gain from forcing a user to specify a 
tiebreaker.  We don't force them to do it for non cursorMark sorts.

 cursorMark should accept sort without the uniqueKey
 ---

 Key: SOLR-6121
 URL: https://issues.apache.org/jira/browse/SOLR-6121
 Project: Solr
  Issue Type: Improvement
Reporter: David Smiley
Priority: Minor

 If you are using the cursorMark (deep paging) feature, you shouldn't *have* 
 to add the uniqueKey to the sort parameter.  If the user doesn't do it, the 
 user obviously doesn't care about the uniqueKey order relative to whatever 
 other sort parameters they may or may not have provided.  So if sort doesn't 
 have it, then Solr should simply tack it on at the end instead of providing 
 an error and potentially confusing the user.  This would be more user 
 friendly.
 Quoting Hoss from 
 [SOLR-5463|https://issues.apache.org/jira/browse/SOLR-5463?focusedCommentId=14011384page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14011384]:
 {quote}
 The reason the code currently throws an error was because i figured it was 
 better to force the user to choose which tie breaker they wanted (asc vs 
 desc) then to just magically pick one arbitrarily.
 If folks think a magic default is a better i've got no serious objections – 
 just open a new issue.
 {quote}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

Bug in AnalyzingQueryParser Pattern

2014-07-20 Thread Dennis Walter

Hi there,

While reading the source code of AnalyzingQueryParser to understand what it
does, I think I found a bug in the regular expression used to detect
wildcards. It is defined as

  // gobble escaped chars or find a wildcard character
  private final Pattern wildcardPattern = Pattern.compile((\\.)|([?*]+));

The first group will match a literal dot (.), while its intention seems
to be to match a backslash and a single character. So the expression should
instead be (.)|([?*]+)

Best Regards
Dennis

[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.8.0_11) - Build # 10738 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/10738/
Java: 32bit/jdk1.8.0_11 -client -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 52036 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:467: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:406: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:87: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:179: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* 
./solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/TestJdbcDataSourceConvertType.java

Total time: 109 minutes 34 seconds
Build step 'Invoke Ant' marked build as failure
[description-setter] Description set: Java: 32bit/jdk1.8.0_11 -client 
-XX:+UseSerialGC
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
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/ibm-j9-jdk7) - Build # 10858 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/10858/
Java: 64bit/ibm-j9-jdk7 
-Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/lucene/util/fst/FST;}

All tests passed

Build Log:
[...truncated 6330 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/analysis/icu/test/temp/junit4-J1-20140720_193206_666.syserr
   [junit4]  JVM J1: stderr (verbatim) 
   [junit4] +0xd4575
   [junit4] +0x2424e
   [junit4] +0xfcb0
   [junit4] +0x246e6e
   [junit4] +0x2548b1
   [junit4] +0x253890
   [junit4] +0x25409d
   [junit4] +0x255684
   [junit4] +0x238d2d
   [junit4] +0x25720d
   [junit4] +0x26843d
   [junit4] +0x268731
   [junit4] +0x268731
   [junit4] +0x268731
   [junit4] +0x268731
   [junit4] +0x268731
   [junit4] +0x268731
   [junit4] +0x268731
   [junit4] +0x268731
   [junit4] +0x26953e
   [junit4] +0x1b3dbb
   [junit4] +0x1b9784
   [junit4] +0xdc41d
   [junit4] +0xdd9f5
   [junit4] +0x245d5
   [junit4] +0xdf733
   [junit4] +0xe077c
   [junit4] +0x245d5
   [junit4] Unhandled exception
   [junit4] Type=Segmentation error vmState=0x00057cff
   [junit4] J9Generic_Signal_Number=0004 Signal_Number=000b 
Error_Value= Signal_Code=0001
   [junit4] Handler1=7F77C5BD2AA0 Handler2=7F77C551F050 
InaccessibleAddress=0038
   [junit4] RDI=7F778E1D88D8 RSI= RAX=7F778E1D8A68 
RBX=7F77ACCC8A20
   [junit4] RCX=7F778D0E6E88 RDX= R8=7F77467C12B8 
R9=7F77467C1280
   [junit4] R10=0001 R11=7F77C7031D42 R12=7F77467C1280 
R13=7F778E1D8938
   [junit4] R14=7F77467C12F0 R15=
   [junit4] RIP=7F77BF339E6E GS= FS= RSP=7F77ACCC7F60
   [junit4] EFlags=00210287 CS=0033 RBP=7F778E1D8938 
ERR=0004
   [junit4] TRAPNO=000E OLDMASK=0004 
CR2=0038
   [junit4] xmm0  (f: 0.00, d: 0.00e+00)
   [junit4] xmm1 00ff (f: 4294967296.00, d: 5.432309e-312)
   [junit4] xmm2 6974752f6176616a (f: 1635148160.00, d: 9.787124e+199)
   [junit4] xmm3 7f77467c1da0 (f: 1182539136.00, d: 6.924343e-310)
   [junit4] xmm4 7f77467c1e20 (f: 1182539264.00, d: 6.924343e-310)
   [junit4] xmm5 7f77467c1ea0 (f: 1182539392.00, d: 6.924343e-310)
   [junit4] xmm6 7f77467c1f20 (f: 1182539520.00, d: 6.924343e-310)
   [junit4] xmm7 7f77467c1fa0 (f: 1182539648.00, d: 6.924343e-310)
   [junit4] xmm8 7f77467c2020 (f: 1182539776.00, d: 6.924343e-310)
   [junit4] xmm9 7f77467c2060 (f: 1182539904.00, d: 6.924343e-310)
   [junit4] xmm10 00ff (f: 4294967296.00, d: 7.291122e-304)
   [junit4] xmm11  (f: 0.00, d: 0.00e+00)
   [junit4] xmm12 3d7071468681eed2 (f: 2256662272.00, d: 9.346469e-13)
   [junit4] xmm13  (f: 0.00, d: 0.00e+00)
   [junit4] xmm14 bc6caae268ecd179 (f: 1760350592.00, d: -1.243255e-17)
   [junit4] xmm15 402791272ee9db80 (f: 787078016.00, d: 1.178350e+01)
   [junit4] 
Module=/opt/ibm/java-x86_64-71/jre/lib/amd64/compressedrefs/libj9jit27.so
   [junit4] Module_base_address=7F77BF0F3000
   [junit4] 
   [junit4] 
Method_being_compiled=org/apache/lucene/util/AttributeFactory$StaticImplementationAttributeFactory.createAttributeInstance(Ljava/lang/Class;)Lorg/apache/lucene/util/AttributeImpl;
   [junit4] Target=2_70_20140410_195893 (Linux 3.13.0-32-generic)
   [junit4] CPU=amd64 (8 logical CPUs) (0x1f2822000 RAM)
   [junit4] --- Stack Backtrace ---
   [junit4] (0x7F77BF339E6E [libj9jit27.so+0x246e6e])
   [junit4] (0x7F77BF3478B1 [libj9jit27.so+0x2548b1])
   [junit4] (0x7F77BF346890 [libj9jit27.so+0x253890])
   [junit4] (0x7F77BF34709D [libj9jit27.so+0x25409d])
   [junit4] (0x7F77BF348684 [libj9jit27.so+0x255684])
   [junit4] (0x7F77BF32BD2D [libj9jit27.so+0x238d2d])
   [junit4] (0x7F77BF34A20D [libj9jit27.so+0x25720d])
   [junit4] (0x7F77BF35B43D [libj9jit27.so+0x26843d])
   [junit4] (0x7F77BF35B731 [libj9jit27.so+0x268731])
   [junit4] (0x7F77BF35B731 [libj9jit27.so+0x268731])
   [junit4] (0x7F77BF35B731 [libj9jit27.so+0x268731])
   [junit4] (0x7F77BF35B731 [libj9jit27.so+0x268731])
   [junit4] (0x7F77BF35B731 [libj9jit27.so+0x268731])
   [junit4] (0x7F77BF35B731 [libj9jit27.so+0x268731])
   [junit4] (0x7F77BF35B731 [libj9jit27.so+0x268731])
   [junit4] (0x7F77BF35B731 [libj9jit27.so+0x268731])
   [junit4] (0x7F77BF35C53E [libj9jit27.so+0x26953e])
   [junit4] (0x7F77BF2A6DBB [libj9jit27.so+0x1b3dbb])
   [junit4] (0x7F77BF2AC784 [libj9jit27.so+0x1b9784])
   [junit4] (0x7F77BF1CF41D [libj9jit27.so+0xdc41d])
   [junit4] (0x7F77BF1D09F5 [libj9jit27.so+0xdd9f5])
   [junit4] (0x7F77C551F5D5 [libj9prt27.so+0x245d5])
   [junit4] (0x7F77BF1D2733 [libj9jit27.so+0xdf733])
   [junit4] (0x7F77BF1D377C

[jira] [Created] (SOLR-6261) Run checkIfIamLeader in a separate thread

2014-07-20 Thread Ramkumar Aiyengar (JIRA)

Ramkumar Aiyengar created SOLR-6261:
---

 Summary: Run checkIfIamLeader in a separate thread
 Key: SOLR-6261
 URL: https://issues.apache.org/jira/browse/SOLR-6261
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 4.9
Reporter: Ramkumar Aiyengar
Priority: Minor


Currently checking for leadership (due to the leader's ephemeral node going 
away) happens in ZK's event thread. If there are many cores and all of them are 
due leadership, then they would have to serially go through the two-way sync 
and leadership takeover.

For tens of cores, this could mean 30-40s without leadership before the last in 
the list even gets to start the leadership process. If the leadership process 
happens in a separate thread, then the cores could all take over in parallel.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[GitHub] lucene-solr pull request: Run checkIfIamLeader in a separate threa...

2014-07-20 Thread andyetitmoves

GitHub user andyetitmoves opened a pull request:

https://github.com/apache/lucene-solr/pull/66

Run checkIfIamLeader in a separate thread

Initial patch for 
[SOLR-6261](https://issues.apache.org/jira/browse/SOLR-6261) to run 
`checkIfIAmLeader` in a separate thread, passes all tests.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bloomberg/lucene-solr trunk-parallel-leader

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/66.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #66


commit 6b0c98c6462a05c24dbf111450c14e53a447b6d3
Author: Ramkumar Aiyengar andyetitmo...@gmail.com
Date:   2014-07-20T19:08:58Z

Run checkIfIamLeader in a separate thread




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (SOLR-6261) Run checkIfIamLeader in a separate thread

2014-07-20 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on SOLR-6261:
--

GitHub user andyetitmoves opened a pull request:

https://github.com/apache/lucene-solr/pull/66

Run checkIfIamLeader in a separate thread

Initial patch for 
[SOLR-6261](https://issues.apache.org/jira/browse/SOLR-6261) to run 
`checkIfIAmLeader` in a separate thread, passes all tests.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bloomberg/lucene-solr trunk-parallel-leader

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/66.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #66


commit 6b0c98c6462a05c24dbf111450c14e53a447b6d3
Author: Ramkumar Aiyengar andyetitmo...@gmail.com
Date:   2014-07-20T19:08:58Z

Run checkIfIamLeader in a separate thread




 Run checkIfIamLeader in a separate thread
 -

 Key: SOLR-6261
 URL: https://issues.apache.org/jira/browse/SOLR-6261
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 4.9
Reporter: Ramkumar Aiyengar
Priority: Minor

 Currently checking for leadership (due to the leader's ephemeral node going 
 away) happens in ZK's event thread. If there are many cores and all of them 
 are due leadership, then they would have to serially go through the two-way 
 sync and leadership takeover.
 For tens of cores, this could mean 30-40s without leadership before the last 
 in the list even gets to start the leadership process. If the leadership 
 process happens in a separate thread, then the cores could all take over in 
 parallel.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

Re: Solr checkIfIAmLeader usage from ZK event thread

2014-07-20 Thread Ramkumar R. Aiyengar

Opened SOLR-6261
On 19 Jul 2014 20:21, Mark Miller markrmil...@gmail.com wrote:

 Put up a patch a lets take a look.

 Most anywhere that holds up the zk processing thread for any decent amount
 of time is probably something waiting to be fixed.

 --
 Mark Miller
 about.me/markrmiller

 On July 15, 2014 at 10:09:56 AM, Ramkumar R. Aiyengar (
 andyetitmo...@gmail.com) wrote:
  Currently when a replica is watching the current leader's ephemeral node
  and the leader disappears, it runs the leadership check along with its
 two
  way peer sync, ZK update etc. on the ZK event thread where the watch was
  fired.
 
  What this means is that for instances with lots of cores, you would be
  serializing leadership elections and the last in the list could take a
 long
  time to have a replacement elected (during which you will have no
 leader).
 
  I did a quick change to make the checkIfIAmLeader call async, but Solr
  cloud tests being what they are (thanks Shalin for cleaning them up btw
 :)
  ), I wanted to check if I am doing something stupid. If not, I will
 raise a
  JIRA.
 
  One contention could be if you might end up with two elections for the
 same
  shard, but I can't see how that might happen..
 


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

[jira] [Updated] (LUCENE-5838) hunspell buggy with over 64k affixes

2014-07-20 Thread Robert Muir (JIRA)


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

Robert Muir updated LUCENE-5838:


Attachment: LUCENE-5838.patch

patch with a minimal test.

 hunspell buggy with over 64k affixes
 

 Key: LUCENE-5838
 URL: https://issues.apache.org/jira/browse/LUCENE-5838
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5838.patch


 currently we build TreeMapString,ListCharacter in ram, to sort before 
 adding to the FST (which encodes the list as IntsRef). 
 char overflows here if there are more than 64k affixes (e.g. basque).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (LUCENE-5838) hunspell buggy with over 64k affixes

2014-07-20 Thread Robert Muir (JIRA)

Robert Muir created LUCENE-5838:
---

 Summary: hunspell buggy with over 64k affixes
 Key: LUCENE-5838
 URL: https://issues.apache.org/jira/browse/LUCENE-5838
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-5838.patch

currently we build TreeMapString,ListCharacter in ram, to sort before 
adding to the FST (which encodes the list as IntsRef). 

char overflows here if there are more than 64k affixes (e.g. basque).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (SOLR-6216) Better faceting for multiple intervals on DV fields

2014-07-20 Thread Erick Erickson (JIRA)


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

Erick Erickson updated SOLR-6216:
-

Attachment: SOLR-6216.patch

Trivial changes, took out a couple of unused parameters to methods in 
IntervalFacets.

 Better faceting for multiple intervals on DV fields
 ---

 Key: SOLR-6216
 URL: https://issues.apache.org/jira/browse/SOLR-6216
 Project: Solr
  Issue Type: Improvement
Reporter: Tomás Fernández Löbbe
Assignee: Erick Erickson
 Attachments: SOLR-6216.patch, SOLR-6216.patch, SOLR-6216.patch, 
 SOLR-6216.patch, SOLR-6216.patch, SOLR-6216.patch, SOLR-6216.patch, 
 SOLR-6216.patch, SOLR-6216.patch, SOLR-6216.patch


 There are two ways to have faceting on values ranges in Solr right now: 
 “Range Faceting” and “Query Faceting” (doing range queries). They both end up 
 doing something similar:
 {code:java}
 searcher.numDocs(rangeQ , docs)
 {code}
 The good thing about this implementation is that it can benefit from caching. 
 The bad thing is that it may be slow with cold caches, and that there will be 
 a query for each of the ranges.
 A different implementation would be one that works similar to regular field 
 faceting, using doc values and validating ranges for each value of the 
 matching documents. This implementation would sometimes be faster than Range 
 Faceting / Query Faceting, specially on cases where caches are not very 
 effective, like on a high update rate, or where ranges change frequently.
 Functionally, the result should be exactly the same as the one obtained by 
 doing a facet query for every interval



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6216) Better faceting for multiple intervals on DV fields

2014-07-20 Thread Erick Erickson (JIRA)


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

Erick Erickson commented on SOLR-6216:
--

Tomás:

Took another look today, looks really good. I did happen to notice a couple of 
unused parameters, so I attached a patch takes them out.

Unless there are objections, I'll commit this next Tuesday or Wednesday.

Thanks!
Erick

 Better faceting for multiple intervals on DV fields
 ---

 Key: SOLR-6216
 URL: https://issues.apache.org/jira/browse/SOLR-6216
 Project: Solr
  Issue Type: Improvement
Reporter: Tomás Fernández Löbbe
Assignee: Erick Erickson
 Attachments: SOLR-6216.patch, SOLR-6216.patch, SOLR-6216.patch, 
 SOLR-6216.patch, SOLR-6216.patch, SOLR-6216.patch, SOLR-6216.patch, 
 SOLR-6216.patch, SOLR-6216.patch, SOLR-6216.patch


 There are two ways to have faceting on values ranges in Solr right now: 
 “Range Faceting” and “Query Faceting” (doing range queries). They both end up 
 doing something similar:
 {code:java}
 searcher.numDocs(rangeQ , docs)
 {code}
 The good thing about this implementation is that it can benefit from caching. 
 The bad thing is that it may be slow with cold caches, and that there will be 
 a query for each of the ranges.
 A different implementation would be one that works similar to regular field 
 faceting, using doc values and validating ranges for each value of the 
 matching documents. This implementation would sometimes be faster than Range 
 Faceting / Query Faceting, specially on cases where caches are not very 
 effective, like on a high update rate, or where ranges change frequently.
 Functionally, the result should be exactly the same as the one obtained by 
 doing a facet query for every interval



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

Suggestion to use ListType instead of Type array

2014-07-20 Thread Fuxiang Chen

Dear Developers,

We are a team of researchers from the Hong Kong University of Science and
Technology (HKUST). Currently, we are studying how crowdsourcing can help
developers to build a higher quality software.

One of the subjects that we used is Lucene. From our experiment, we
identified an area in a particular file PhraseQuery.java that can be
converted to a ListType. Using ListType is more preferred as it is much
more flexible and easier to maintain.

The following identified method is able to convert to a ListType:
1) public int[] getPositions()
The above method used a primitive int array, and can be converted to a
ListInteger instead.

Our references from the Stack Overflow community pointed out that
ListType is preferred over a Type array.
The Stack Overflow references to this are at 
http://stackoverflow.com/questions/8689246; and 
http://stackoverflow.com/questions/716597;.

By converting the Type array to a ListType, this will make the code more
flexible and easier to maintain.

We hope that you can consider this and let us know about any thoughts. This
will be a tremendous help to us in our continuing research to building a
better software and to help the open-source community as a whole.

Please do not hesitate to contact me @ fche...@cse.ust.hk if there are any
queries.

Thanks a lot and have a great week ahead!


-- 
Warmest Regards,
Fuxiang

[jira] [Commented] (SOLR-6260) Rename DirectUpdateHandler2

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

Mark Miller commented on SOLR-6260:
---

I've wanted to fix this since 2008. When can it be fixed, never? In 2028?

There is a history and a pattern of pushing back on stuff like this. All it
does is discourage new contributors and hobble willing contributors.

If we changed, would anything crazy or bad happen? No. If we leave it, it's
just a pattern of screwing the project from a high level under the guise of
small improvements not being worth it.

IMO, this is push back for push backs sake. Forget committing this so that
Tomas can move on and improve the next little thing. Let's tie him up and red
tape and squeeze the life out of him so that he doesn't do anything crazy, like
get a little enthusiasm and momentum on improving our crap load of ugly
technical debt.

Rename DirectUpdateHandler2
---

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6260) Rename DirectUpdateHandler2

2014-07-20 Thread Alan Woodward (JIRA)


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

Alan Woodward commented on SOLR-6260:
-

+1 to the rename.  If we're concerned with it breaking schemas, then maybe keep 
DirectUpdateHandler2 in 4x as an empty class that extends SolrUpdateHandler?  
And then nuke it in trunk.

 Rename DirectUpdateHandler2
 ---

 Key: SOLR-6260
 URL: https://issues.apache.org/jira/browse/SOLR-6260
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Attachments: SOLR-6260.patch, SOLR-6260.patch


 DirectUpdateHandler was removed, I think in Solr 4. DirectUpdateHandler2 
 should be renamed, at least remove that 2. I don't know really what 
 direct means here. Maybe it could be renamed to DefaultUpdateHandler, or 
 UpdateHandlerDefaultImpl, or other good suggestions



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6260) Rename DirectUpdateHandler2

2014-07-20 Thread Jack Krupansky (JIRA)


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

Jack Krupansky commented on SOLR-6260:
--

Could we at least remove it from the example solrconfig in 5.0? Change the name 
as you see fit, and make it the default for the updateHandler class 
attribute? I mean, it always was kind of a wart to have to specify that kind 
of internal detail externally like that.



 Rename DirectUpdateHandler2
 ---

 Key: SOLR-6260
 URL: https://issues.apache.org/jira/browse/SOLR-6260
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Attachments: SOLR-6260.patch, SOLR-6260.patch


 DirectUpdateHandler was removed, I think in Solr 4. DirectUpdateHandler2 
 should be renamed, at least remove that 2. I don't know really what 
 direct means here. Maybe it could be renamed to DefaultUpdateHandler, or 
 UpdateHandlerDefaultImpl, or other good suggestions



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6260) Rename DirectUpdateHandler2


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

Mark Miller commented on SOLR-6260:
---

bq.  I mean, it always was kind of a wart to have to specify that kind of 
internal detail externally like that.

I don't even really consider changing the updatehandler support. Support expert 
thing thats subject to break in all kinds of ways at any time (as it has over 
the others).

I'm def +1 on taking it out of the config. I like the idea of exposing it for 
people to cry crazy stuff, but we must be free to treat this stuff as internal. 

 Rename DirectUpdateHandler2
 ---

 Key: SOLR-6260
 URL: https://issues.apache.org/jira/browse/SOLR-6260
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Attachments: SOLR-6260.patch, SOLR-6260.patch


 DirectUpdateHandler was removed, I think in Solr 4. DirectUpdateHandler2 
 should be renamed, at least remove that 2. I don't know really what 
 direct means here. Maybe it could be renamed to DefaultUpdateHandler, or 
 UpdateHandlerDefaultImpl, or other good suggestions



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Comment Edited] (SOLR-6260) Rename DirectUpdateHandler2