date:20130124


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

Dmytro Yurchenko updated SOLR-4346:
---

Attachment: chrome24_radial_graph.png
chrome24_graph.png
firefox18_radial_graph.png
firefox18_graph.png

 Solr Admin UI: Cloud graphs are not shown correctly in Google Chrome
 

 Key: SOLR-4346
 URL: https://issues.apache.org/jira/browse/SOLR-4346
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
 Environment: Ubuntu Linux 12.04, Chrome 24.0.1312.56, Firefox 18.1
Reporter: Dmytro Yurchenko
 Attachments: chrome24_graph.png, chrome24_radial_graph.png, 
 firefox18_graph.png, firefox18_radial_graph.png


 I installed solr cluster using version 4.1.0 and configuration we have for 
 4.0.0 and instantly saw the difference: in the cloud admin page both graphs 
 are not display correctly in Google Chrome.
 The common graph is not displayed at all and the radial graph doesn't show 
 all vertices and edges. (See screenshots attached).
 There are no errors in Javascript console though.
 Both graphs work perfectly well in Firefox 18. And the work in Chrome when we 
 use solr 4.0.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] [Created] (SOLR-4346) Solr Admin UI: Cloud graphs are not shown correctly in Google Chrome

Dmytro Yurchenko created SOLR-4346:
--

 Summary: Solr Admin UI: Cloud graphs are not shown correctly in 
Google Chrome
 Key: SOLR-4346
 URL: https://issues.apache.org/jira/browse/SOLR-4346
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
 Environment: Ubuntu Linux 12.04, Chrome 24.0.1312.56, Firefox 18.1
Reporter: Dmytro Yurchenko
 Attachments: chrome24_graph.png, chrome24_radial_graph.png, 
firefox18_graph.png, firefox18_radial_graph.png

I installed solr cluster using version 4.1.0 and configuration we have for 
4.0.0 and instantly saw the difference: in the cloud admin page both graphs are 
not display correctly in Google Chrome.

The common graph is not displayed at all and the radial graph doesn't show all 
vertices and edges. (See screenshots attached).

There are no errors in Javascript console though.

Both graphs work perfectly well in Firefox 18. And the work in Chrome when we 
use solr 4.0.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-4346) Solr Admin UI: Cloud graphs are not shown correctly in Google Chrome

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

Dmytro Yurchenko updated SOLR-4346:
---

Description:
I installed solr cluster using version 4.1.0 and configuration we have for
4.0.0 and instantly saw the difference: in the cloud admin page both graphs are
not displayed correctly in Google Chrome.

The common graph is not displayed at all and the radial graph doesn't show all
vertices and edges. (See screenshots attached).

There are no errors in Javascript console though.

Both graphs work perfectly well in Firefox 18. And the work in Chrome when we
use solr 4.0.0.

was:
I installed solr cluster using version 4.1.0 and configuration we have for
4.0.0 and instantly saw the difference: in the cloud admin page both graphs are
not display correctly in Google Chrome.

The common graph is not displayed at all and the radial graph doesn't show all
vertices and edges. (See screenshots attached).

There are no errors in Javascript console though.

Both graphs work perfectly well in Firefox 18. And the work in Chrome when we
use solr 4.0.0.

Solr Admin UI: Cloud graphs are not shown correctly in Google Chrome

Key: SOLR-4346
URL: https://issues.apache.org/jira/browse/SOLR-4346
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.1
Environment: Ubuntu Linux 12.04, Chrome 24.0.1312.56, Firefox 18.1
Reporter: Dmytro Yurchenko
Attachments: chrome24_graph.png, chrome24_radial_graph.png,
firefox18_graph.png, firefox18_radial_graph.png

I installed solr cluster using version 4.1.0 and configuration we have for
4.0.0 and instantly saw the difference: in the cloud admin page both graphs
are not displayed correctly in Google Chrome.
The common graph is not displayed at all and the radial graph doesn't show
all vertices and edges. (See screenshots attached).
There are no errors in Javascript console though.
Both graphs work perfectly well in Firefox 18. And the work in Chrome when we
use solr 4.0.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] [Commented] (SOLR-4345) Solr Admin UI dosent work in IE 10


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

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

Hey Kurt, thanks for reporting this - we already had an Issue for not working 
on IE9 (SOLR-3876) which was successfully fixed .. i'll see if i can get an 
Win8 VMware to check that

 Solr Admin UI dosent work in IE 10
 --

 Key: SOLR-4345
 URL: https://issues.apache.org/jira/browse/SOLR-4345
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
 Environment: Windows 8, IE 10
Reporter: Kurt Pedersen
 Attachments: solr-ie10.png


 The main Windows only shows Loading on IE 10. Working fine in Chrome.

--
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-4258) Incremental Field Updates through Stacked Segments

2013-01-24 Thread Sivan Yogev (JIRA)


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

Sivan Yogev updated LUCENE-4258:


Attachment: LUCENE-4258.branch.1.patch

New patch over the issue branch. Inversion of updated fields done directly when 
added into a RAMDirectory, and updated segments are created by merging such 
directories. If more than one update to be applied on same document, the later 
update is moved to another updated segment.

Still missing:
1. Implement RAM usage computation for updates,
2. fix TestFieldReplacements.testIndexEquality().

 Incremental Field Updates through Stacked Segments
 --

 Key: LUCENE-4258
 URL: https://issues.apache.org/jira/browse/LUCENE-4258
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/index
Reporter: Sivan Yogev
 Fix For: 4.2, 5.0

 Attachments: IncrementalFieldUpdates.odp, 
 LUCENE-4258-API-changes.patch, LUCENE-4258.branch.1.patch, 
 LUCENE-4258.r1410593.patch, LUCENE-4258.r1412262.patch, 
 LUCENE-4258.r1416438.patch, LUCENE-4258.r1416617.patch, 
 LUCENE-4258.r1422495.patch, LUCENE-4258.r1423010.patch

   Original Estimate: 2,520h
  Remaining Estimate: 2,520h

 Shai and I would like to start working on the proposal to Incremental Field 
 Updates outlined here (http://markmail.org/message/zhrdxxpfk6qvdaex).

--
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-4013) Creating a core should prevent more than one thread from creating a core of the same name at once.


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

Erick Erickson commented on SOLR-4013:
--

I think I've already done this in SOLR-4196 which hasn't been committed yet, I 
need to verify.

 Creating a core should prevent more than one thread from creating a core of 
 the same name at once.
 --

 Key: SOLR-4013
 URL: https://issues.apache.org/jira/browse/SOLR-4013
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.1, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2, 5.0


 This hasn't been an issue so far since cores are created at startup. But in 
 the lots of cores case (see SOLR-1293) the probability that more than one 
 thread will attempt to create a core of the same name is vastly greater. We 
 need to block other threads from creating a core if the core is already being 
 created in a different thread.
 Once the core is created, the blocked thread should pick up the newly-created 
 core rather than create it 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] [Created] (SOLR-4347) Insure that newly-created cores via Admin handler are persisted in solr.xml

Erick Erickson created SOLR-4347:


 Summary: Insure that newly-created cores via Admin handler are 
persisted in solr.xml
 Key: SOLR-4347
 URL: https://issues.apache.org/jira/browse/SOLR-4347
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.1, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor


From Andy, commenting on SOLR-4196 

I noticed a bug in Solr-4.1 release that if there are unloaded transient cores 
in solr.xml, and a new core is created via the admin handler, the record of the 
core in solr.xml is removed on persist.

Creating as a separate bug, I don't want to lose it, but I havent verified it 
yet.

Thanks for bringing this up Andy!

--
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-3980) Incorporate lazily-loaded cores into core listings for clients


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

Erick Erickson commented on SOLR-3980:
--

Talking with Stefan, it seems like the right thing to do is make the admin 
STATUS command return all cores, loaded and unloaded.

 Incorporate lazily-loaded cores into core listings for clients
 --

 Key: SOLR-3980
 URL: https://issues.apache.org/jira/browse/SOLR-3980
 Project: Solr
  Issue Type: Improvement
  Components: multicore, web gui
Affects Versions: 4.1
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2


 Part of SOLR-1293 (supporting lots of cores) will require we do something to 
 allow clients (particularly the admin GUI) to get a full list of all possible 
 cores, whether they've been loaded or not.

--
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-3926) solrj should support better way of finding active sorts


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

Erick Erickson updated SOLR-3926:
-

Attachment: SOLR-3926.patch

Changed comments to since 4.2 since I didn't get this done promptly.

Tests pass on trunk, if there are no objections I'll commit this tomorrow 
(Friday).

 solrj should support better way of finding active sorts
 ---

 Key: SOLR-3926
 URL: https://issues.apache.org/jira/browse/SOLR-3926
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 4.0
Reporter: Eirik Lygre
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2

 Attachments: SOLR-3926.patch, SOLR-3926.patch, SOLR-3926.patch, 
 SOLR-3926.patch, SOLR-3926.patch


 The Solrj api uses ortogonal concepts for setting/removing and getting sort 
 information. Setting/removing uses a combination of (name,order), while 
 getters return a String name order:
 {code}
 public SolrQuery setSortField(String field, ORDER order);
 public SolrQuery addSortField(String field, ORDER order);
 public SolrQuery removeSortField(String field, ORDER order);
 public String[] getSortFields();
 public String getSortField();
 {code}
 If you want to use the current sort information to present a list of active 
 sorts, with the possibility to remove then, you need to manually parse the 
 string(s) returned from getSortFields, to recreate the information required 
 by removeSortField(). Not difficult, but not convenient either :-)
 Therefore this suggestion: Add a new method {{public MapString,ORDER 
 getSortFieldMap();}} which returns an ordered map of active sort fields. This 
 will make introspection of the current sort setup much easier.
 {code}
   public MapString, ORDER getSortFieldMap() {
 String[] actualSortFields = getSortFields();
 if (actualSortFields == null || actualSortFields.length == 0)
   return Collections.emptyMap();
 MapString, ORDER sortFieldMap = new LinkedHashMapString, ORDER();
 for (String sortField : actualSortFields) {
   String[] fieldSpec = sortField.trim().split( );
   sortFieldMap.put(fieldSpec[0], ORDER.valueOf(fieldSpec[1]));
 }
 return Collections.unmodifiableMap(sortFieldMap);
   }
 {code}
 For what it's worth, this is possible client code:
 {code}
 System.out.println(Active sorts);
 MapString, ORDER fieldMap = getSortFieldMap(query);
 for (String field : fieldMap.keySet()) {
System.out.println(-  + field + ; dir= + fieldMap.get(field));
 }
 {code}

--
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-4316) Admin UI - SolrCloud - extend core options to collections

2013-01-24 Thread Shawn Heisey (JIRA)


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

Shawn Heisey commented on SOLR-4316:


If this is significant work, perhaps we can start with the Query interface on 
this issue and open new issues for other functionality.


 Admin UI - SolrCloud - extend core options to collections
 -

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


 There are a number of sections available when you are looking at a core in 
 the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser, 
 Plugins / Stats, and Dataimport are the ones that I can see.
 A list of collections should be available, with as many of those options that 
 can apply to a collection,  If options specific to collections/SolrCloud can 
 be implemented, those should be there too.

--
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-4316) Admin UI - SolrCloud - extend core options to collections

2013-01-24 Thread Shawn Heisey (JIRA)


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

Shawn Heisey commented on SOLR-4316:


Clarification on why I filed this issue:

If SolrCloud is enabled and you have a distributed index, you can currently 
open up the admin interface and send queries to one core.  You can't send them 
to an entire collection.  From what I was told when helping someone on IRC, it 
sounds like Solr 4.0.0 used the collection name as the core name, so perhaps 
4.0.0 could do this, but 4.1 has collection_shardN_replicaN for the core name.

While I was thinking about this, I looked at the other things you can do on a 
core and figured that most of them might be useful on a collection.  While it 
is a good idea to implement as much functionality as possible, perhaps this one 
issue should be about queries.


 Admin UI - SolrCloud - extend core options to collections
 -

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


 There are a number of sections available when you are looking at a core in 
 the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser, 
 Plugins / Stats, and Dataimport are the ones that I can see.
 A list of collections should be available, with as many of those options that 
 can apply to a collection,  If options specific to collections/SolrCloud can 
 be implemented, those should be there too.

--
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-4345) Solr Admin UI dosent work in IE 10


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

Jan Høydahl updated SOLR-4345:
--

Fix Version/s: 5.0
   4.2

 Solr Admin UI dosent work in IE 10
 --

 Key: SOLR-4345
 URL: https://issues.apache.org/jira/browse/SOLR-4345
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
 Environment: Windows 8, IE 10
Reporter: Kurt Pedersen
  Labels: IE, IE10, InternetExplorer
 Fix For: 4.2, 5.0

 Attachments: solr-ie10.png


 The main Windows only shows Loading on IE 10. Working fine in Chrome.

--
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-4345) Solr Admin UI dosent work in IE 10


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

Jan Høydahl updated SOLR-4345:
--

Labels: IE IE10 InternetExplorer  (was: )

 Solr Admin UI dosent work in IE 10
 --

 Key: SOLR-4345
 URL: https://issues.apache.org/jira/browse/SOLR-4345
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
 Environment: Windows 8, IE 10
Reporter: Kurt Pedersen
  Labels: IE, IE10, InternetExplorer
 Attachments: solr-ie10.png


 The main Windows only shows Loading on IE 10. Working fine in Chrome.

--
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-4343) Solrcloud 4.1 inconsistent # of results in replicas

2013-01-24 Thread Joseph Dale (JIRA)


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

Joseph Dale commented on SOLR-4343:
---

I just ran the process. There is nothing in the logs but a few OOMs on the 
replica.
Master core info:

lastModified:2 minutes ago
version:110290
numDocs:93835
maxDoc:93857 

Non Master: 

lastModified:3 minutes ago
version: 44711
numDocs: 91994
maxDoc: 92009
deletedDocs: 15 

From solrconfig.xml:
 autoSoftCommit 
   maxTime1000/maxTime
   maxDocs1/maxDocs
   openSearcherfalse/openSearcher
 /autoSoftCommit
 
 autoCommit
maxTime15000/maxTime
maxDocs1000/maxDocs
openSearcherfalse/openSearcher
 /autoCommit


 Solrcloud 4.1 inconsistent # of results in replicas 
 

 Key: SOLR-4343
 URL: https://issues.apache.org/jira/browse/SOLR-4343
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Ubuntu12.04 / Java 1.7.11 / Tomcat7 / Zookeeper 3.4.5
Reporter: Joseph Dale
Priority: Critical

 I have a one shard collection, with one replica.
 I did a dataImport from my oracle DB.
 In the master, I have 93835 docs, in the non master 92627.
 I have tried http://machinename:8080/solr/collection/update/commit=true on 
 the master, but the index does not replicate the replica.
 Also, the node list different generations of the core.
 I have left it alone for 2 hours and they never sync. Both nodes think that 
 they are current, only on really is. I can reproduce this 100% of the time.
 -Joey

--
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-4343) Solrcloud 4.1 inconsistent # of results in replicas

2013-01-24 Thread Joseph Dale (JIRA)


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

Joseph Dale edited comment on SOLR-4343 at 1/24/13 1:15 PM:


I just ran the process. There is nothing in the logs but a few OOMs on the 
replica.
Master core info:

lastModified:2 minutes ago
version:110290
numDocs:93835
maxDoc:93857 

Non Master: 

lastModified:3 minutes ago
version: 44711
numDocs: 91994
maxDoc: 92009
deletedDocs: 15 

From solrconfig.xml:
 autoSoftCommit 
   maxTime1000/maxTime
   maxDocs1/maxDocs
   openSearcherfalse/openSearcher
 /autoSoftCommit
 
 autoCommit
maxTime15000/maxTime
maxDocs1000/maxDocs
openSearcherfalse/openSearcher
 /autoCommit

From clusterstate.json:
 geo-us:{
shards:{shard1:{replicas:{
  192.168.50.2:8080_solr_geo-us:{
shard:shard1,
roles:null,
state:active,
core:geo-us,
collection:geo-us,
node_name:192.168.50.2:8080_solr,
base_url:http://192.168.50.2:8080/solr;,
leader:true},
  192.168.50.3:8080_solr_geo-us:{
shard:shard1,
roles:null,
state:active,
core:geo-us,
collection:geo-us,
node_name:192.168.50.3:8080_solr,
base_url:http://192.168.50.3:8080/solr,
router:implicit}}

  was (Author: joey.dale):
I just ran the process. There is nothing in the logs but a few OOMs on the 
replica.
Master core info:

lastModified:2 minutes ago
version:110290
numDocs:93835
maxDoc:93857 

Non Master: 

lastModified:3 minutes ago
version: 44711
numDocs: 91994
maxDoc: 92009
deletedDocs: 15 

From solrconfig.xml:
 autoSoftCommit 
   maxTime1000/maxTime
   maxDocs1/maxDocs
   openSearcherfalse/openSearcher
 /autoSoftCommit
 
 autoCommit
maxTime15000/maxTime
maxDocs1000/maxDocs
openSearcherfalse/openSearcher
 /autoCommit

  
 Solrcloud 4.1 inconsistent # of results in replicas 
 

 Key: SOLR-4343
 URL: https://issues.apache.org/jira/browse/SOLR-4343
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Ubuntu12.04 / Java 1.7.11 / Tomcat7 / Zookeeper 3.4.5
Reporter: Joseph Dale
Priority: Critical

 I have a one shard collection, with one replica.
 I did a dataImport from my oracle DB.
 In the master, I have 93835 docs, in the non master 92627.
 I have tried http://machinename:8080/solr/collection/update/commit=true on 
 the master, but the index does not replicate the replica.
 Also, the node list different generations of the core.
 I have left it alone for 2 hours and they never sync. Both nodes think that 
 they are current, only on really is. I can reproduce this 100% of the time.
 -Joey

--
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-3967) Mapping error: langid.enforceSchema option checks source field instead of target field


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

Jan Høydahl commented on SOLR-3967:
---

The patch moves the enforce logic to the getMappedField() method.

I also fixed an issue where langid would fallback to original field instead of 
aborting in case mapped field does not exist. Will commit shortly if no 
objections.

 Mapping error: langid.enforceSchema option checks source field instead of 
 target field
 --

 Key: SOLR-3967
 URL: https://issues.apache.org/jira/browse/SOLR-3967
 Project: Solr
  Issue Type: Bug
  Components: contrib - LangId
Affects Versions: 4.0
Reporter: Mateusz Matela
Assignee: Jan Høydahl
 Fix For: 4.2, 5.0

 Attachments: SOLR-3967.patch


 I use LangDetect update processor with a document that has body field. 
 LangDetect should map this field to body_pl, body_en or body_nolang. My 
 schema defines fields with language suffixes, but not body field. When the 
 processor runs, I get error:
 {quote}Unsuccessful field name mapping to body_nolang, field does not exist, 
 skipping mapping.{quote}
 I looked up source code and it seems there's an error in 
 {{org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.process(SolrInputDocument)}}:
 {noformat}
   String mappedOutputField = getMappedField(fieldName, fieldLang);
   if(enforceSchema  schema.getFieldOrNull(fieldName) == null) {
 log.warn(Unsuccessful field name mapping to {}, field does not 
 exist, skipping mapping., mappedOutputField, fieldName);
 mappedOutputField = fieldName;
   }
 {noformat}
 I think it should check for {{schema.getFieldOrNull(mappedOutputField)}} 
 instead.

--
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-4715) Add OrdinalPolicy.ALL_BUT_DIMENSION

Shai Erera created LUCENE-4715:
--

 Summary: Add OrdinalPolicy.ALL_BUT_DIMENSION
 Key: LUCENE-4715
 URL: https://issues.apache.org/jira/browse/LUCENE-4715
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera


With the move of OrdinalPolicy to CategoryListParams, NonTopLevelOrdinalPolicy 
was nuked. It might be good to restore it, as another enum value of 
OrdinalPolicy.

It's the same like ALL_PARENTS, only doesn't add the dimension ordinal, which 
could save space as well as computation time. It's good for when you don't care 
about the count of Date/, but only about its children counts.

--
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-4715) Add OrdinalPolicy.ALL_BUT_DIMENSION

2013-01-24 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-4715:


+1

This is very compelling because you also do not need to do the rollup in the 
end, so you get the gains of NO_PARENTS without the cost (end rollup), so even 
for indices w/ many unique ords there's no penalty.

I also suspect this is common ... ie most faceted search UIs I've seen do not 
include the dim facet count, just the values under that dim.

 Add OrdinalPolicy.ALL_BUT_DIMENSION
 ---

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

 With the move of OrdinalPolicy to CategoryListParams, 
 NonTopLevelOrdinalPolicy was nuked. It might be good to restore it, as 
 another enum value of OrdinalPolicy.
 It's the same like ALL_PARENTS, only doesn't add the dimension ordinal, which 
 could save space as well as computation time. It's good for when you don't 
 care about the count of Date/, but only about its children counts.

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

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

[jira] [Assigned] (SOLR-3711) Velocity: Break or truncate long strings in facet output


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

Jan Høydahl reassigned SOLR-3711:
-

Assignee: (was: Jan Høydahl)

 Velocity: Break or truncate long strings in facet output
 

 Key: SOLR-3711
 URL: https://issues.apache.org/jira/browse/SOLR-3711
 Project: Solr
  Issue Type: Bug
  Components: Response Writers
Reporter: Jan Høydahl
  Labels: /browse
 Fix For: 5.0


 In Solritas /browse GUI, if facets contain very long strings (such as 
 content-type tend to do), currently the too long text runs over the main 
 column and it is not pretty.
 Perhaps inserting a Soft Hyphen shy; 
 (http://en.wikipedia.org/wiki/Soft_hyphen) at position N in very long terms 
 is a solution?

--
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-3613) Namespace Solr's JAVA OPTIONS


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

Jan Høydahl updated SOLR-3613:
--

Assignee: (was: Jan Høydahl)

 Namespace Solr's JAVA OPTIONS
 -

 Key: SOLR-3613
 URL: https://issues.apache.org/jira/browse/SOLR-3613
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.0-ALPHA
Reporter: Jan Høydahl
 Fix For: 4.2, 5.0


 Solr being a web-app, should play nicely in a setting where users deploy it 
 on a shared appServer.
 To this regard Solr's JAVA_OPTS should be properly name spaced, both to avoid 
 name clashes and for clarity when reading your appserver startup script. We 
 currently do that with most: {{solr.solr.home, solr.data.dir, 
 solr.abortOnConfigurationError, solr.directoryFactory, 
 solr.clustering.enabled, solr.velocity.enabled etc}}, but for some opts we 
 fail to do so.
 Before release of 4.0 we should make sure to clean this up.

--
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-4348) Make the lock type configurable by system property by default.

Mark Miller created SOLR-4348:
-

 Summary: Make the lock type configurable by system property by 
default.
 Key: SOLR-4348
 URL: https://issues.apache.org/jira/browse/SOLR-4348
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.1
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.2, 5.0


You can set most common options by system property on start these days - we 
should make lock type work this way by default as well.

--
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-4348) Make the lock type configurable by system property by default.


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

Commit Tag Bot commented on SOLR-4348:
--

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

SOLR-4348: Make the lock type configurable by system property by default.


 Make the lock type configurable by system property by default.
 --

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


 You can set most common options by system property on start these days - we 
 should make lock type work this way by default as well.

--
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-4348) Make the lock type configurable by system property by default.


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

Mark Miller resolved SOLR-4348.
---

Resolution: Fixed

 Make the lock type configurable by system property by default.
 --

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


 You can set most common options by system property on start these days - we 
 should make lock type work this way by default as well.

--
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-4715) Add OrdinalPolicy.ALL_BUT_DIMENSION

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

Shai Erera commented on LUCENE-4715:

bq. so you get the gains of NO_PARENTS without the cost (end rollup)

I'd like to clarify the difference between the 3 OrdinalPolicies, through
example. Say that you add the facet Date/2010/March/11, then the ordinals that
will be encoded are of:

* ALL_PARENTS: Date, Date/2010, Date/2010/March, Date/2010/March/11 (4 ordinals)
* NO_PARENTS: Date/2010/March/11 (1 ordinal)
* ALL_BUT_DIMENSION: Date/2010, Date/2010/March, Date/2010/March/11 (3 ordinals)

The aggregation of ALL_PARENTS and ALL_BUT_DIM is the same, but you don't get
the count of Date/ with the latter policy.
The aggregation of NO_PARENTS is the same as ALL_PARENTS, only you need to do
the rollup in the end.

Maybe we should have just ALL and ALL_BUT_DIM? Given the results of NO_PARENTS
(not that significant gains), and the complexity involved (i.e. currently only
CountingFC supports it) ...

But I just wanted to clarify the differences, because the ALL_BUT_DIM is not
that much different than ALL, except that you'll encode and decode the same
ordinal for many documents, so that has got to buy us something ...

Add OrdinalPolicy.ALL_BUT_DIMENSION
---

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

With the move of OrdinalPolicy to CategoryListParams,
NonTopLevelOrdinalPolicy was nuked. It might be good to restore it, as
another enum value of OrdinalPolicy.
It's the same like ALL_PARENTS, only doesn't add the dimension ordinal, which
could save space as well as computation time. It's good for when you don't
care about the count of Date/, but only about its children counts.

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

[jira] [Commented] (SOLR-4348) Make the lock type configurable by system property by default.


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

Commit Tag Bot commented on SOLR-4348:
--

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

SOLR-4348: Make the lock type configurable by system property by default.


 Make the lock type configurable by system property by default.
 --

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


 You can set most common options by system property on start these days - we 
 should make lock type work this way by default as well.

--
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-4321) SolrCloud collection CREATE will put multiple master shards on a single node (and no shards on some)


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

Commit Tag Bot commented on SOLR-4321:
--

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

SOLR-4321: Collections API will sometimes use a node more than once, even when 
more unused nodes are available.


 SolrCloud collection CREATE will put multiple master shards on a single node 
 (and no shards on some)
 

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

 Attachments: SOLR-4321.patch, SOLR-4321.patch, SOLR-4321.patch


 This is best described by a photo of my SolrCloud admin: 
 http://i.imgur.com/hW4xnxy.png
 I have a 4 node cluster, with shard count of 2 and replication factor of 2.
 After running something like,
   
 http://localhost:8983/solr/admin/collections?action=CREATEname=15724numShards=2replicationFactor=2
 The shards seem to be completely randomly placed, which is fine, but some 
 nodes receive more of the share than others (some even receiving none).
 For example, 15724 has given node backfill-1d 2 parts, 
 15724_shard1_replica2 and 15724_shard2_replica1 but has given backfill-2d 
 nothing at all.
 This creates unnecessary load on some nodes, no? Is this something I am 
 supposed to handle myself (I looked, but don't see how).

--
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-4321) SolrCloud collection CREATE will put multiple master shards on a single node (and no shards on some)


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

Mark Miller resolved SOLR-4321.
---

Resolution: Fixed

Thanks guys!

 SolrCloud collection CREATE will put multiple master shards on a single node 
 (and no shards on some)
 

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

 Attachments: SOLR-4321.patch, SOLR-4321.patch, SOLR-4321.patch


 This is best described by a photo of my SolrCloud admin: 
 http://i.imgur.com/hW4xnxy.png
 I have a 4 node cluster, with shard count of 2 and replication factor of 2.
 After running something like,
   
 http://localhost:8983/solr/admin/collections?action=CREATEname=15724numShards=2replicationFactor=2
 The shards seem to be completely randomly placed, which is fine, but some 
 nodes receive more of the share than others (some even receiving none).
 For example, 15724 has given node backfill-1d 2 parts, 
 15724_shard1_replica2 and 15724_shard2_replica1 but has given backfill-2d 
 nothing at all.
 This creates unnecessary load on some nodes, no? Is this something I am 
 supposed to handle myself (I looked, but don't see how).

--
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-4691) Facet tests should randomly pick IntEncoder and other stuff

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

Shai Erera updated LUCENE-4691:
---

Attachment: LUCENE-4691.patch

Patch adds FacetTestCase and now all facet tests extend it. Unfortunately, not
all encoders support partitions at the moment, so for now tests that rely on
partitions do not draw CLP at random. However the res of the tests, were it
made sense, do.

Facet tests should randomly pick IntEncoder and other stuff
---

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

Facets have many encoders already, but only one of them is tested by all
facet tests (the default). While {{EncodingTest}} covers all encoders, I
already fixed it because it didn't catch a bug where one encoder didn't reset
the given {{BytesRef}}. It will be useful if tests could choose a
randomCategoryListParams(), or randomFacetIndexingParams() etc., to swap in
random encoders.
Also, I wrote an AssertingCategoryListIterator which asserts all kind of
things (e.g. that if setNextReader returns false, getOrdinals isn't called).
Would be good to use it by all tests.
To do that, I think that it would be best if all facet tests extend a
FacetTestCase with such utility methods.

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

[jira] [Commented] (SOLR-4321) SolrCloud collection CREATE will put multiple master shards on a single node (and no shards on some)


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

Commit Tag Bot commented on SOLR-4321:
--

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

SOLR-4321: Collections API will sometimes use a node more than once, even when 
more unused nodes are available.


 SolrCloud collection CREATE will put multiple master shards on a single node 
 (and no shards on some)
 

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

 Attachments: SOLR-4321.patch, SOLR-4321.patch, SOLR-4321.patch


 This is best described by a photo of my SolrCloud admin: 
 http://i.imgur.com/hW4xnxy.png
 I have a 4 node cluster, with shard count of 2 and replication factor of 2.
 After running something like,
   
 http://localhost:8983/solr/admin/collections?action=CREATEname=15724numShards=2replicationFactor=2
 The shards seem to be completely randomly placed, which is fine, but some 
 nodes receive more of the share than others (some even receiving none).
 For example, 15724 has given node backfill-1d 2 parts, 
 15724_shard1_replica2 and 15724_shard2_replica1 but has given backfill-2d 
 nothing at all.
 This creates unnecessary load on some nodes, no? Is this something I am 
 supposed to handle myself (I looked, but don't see how).

--
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-4038) On OOM, SolrCloud indexing blocks if shard is marked as DOWN


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

Mark Miller updated SOLR-4038:
--

Summary: On OOM, SolrCloud indexing blocks if shard is marked as DOWN  
(was: SolrCloud indexing blocks if shard is marked as DOWN)

 On OOM, SolrCloud indexing blocks if shard is marked as DOWN
 

 Key: SOLR-4038
 URL: https://issues.apache.org/jira/browse/SOLR-4038
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0
Reporter: Markus Jelsma
Assignee: Mark Miller
 Fix For: 4.2, 5.0


 See: 
 http://lucene.472066.n3.nabble.com/SolrCloud-indexing-blocks-if-node-is-recovering-td4017827.html
 While indexing (without CloudSolrServer at that time) one node dies with an 
 OOME perhaps  because of the linked issue SOLR-4032. The OOME stack traces 
 are varied but here are some ZK-related logs between the OOME stack traces:
 {code}
 2012-11-02 14:14:37,126 INFO [solr.update.UpdateLog] - [RecoveryThread] - : 
 Dropping buffered updates FSUpdateLog{state=BUFFERING, tlog=null}
 2012-11-02 14:14:37,127 ERROR [solr.cloud.RecoveryStrategy] - 
 [RecoveryThread] - : Recovery failed - trying again... (2) core=shard_e
 2012-11-02 14:14:37,127 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
 - : Wait 8.0 seconds before trying to recover again (3)
 2012-11-02 14:14:45,328 INFO [solr.cloud.ZkController] - [RecoveryThread] - : 
 numShards not found on descriptor - reading it from system property
 2012-11-02 14:14:45,363 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
 - : Starting Replication Recovery. core=shard_e
 2012-11-02 14:14:45,363 INFO [solrj.impl.HttpClientUtil] - [RecoveryThread] - 
 : Creating new http client, 
 config:maxConnections=128maxConnectionsPerHost=32followRedirects=false
 2012-11-02 14:14:45,775 INFO [common.cloud.ZkStateReader] - 
 [main-EventThread] - : A cluster state change has occurred - updating... (10)
 2012-11-02 14:14:50,987 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
 - : Begin buffering updates. core=shard_e
 2012-11-02 14:14:50,987 INFO [solr.update.UpdateLog] - [RecoveryThread] - : 
 Starting to buffer updates. FSUpdateLog{state=ACTIVE, tlog=null}
 2012-11-02 14:14:50,987 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
 - : Attempting to replicate from http://rot05.solrserver:8080/solr/shard_e/. 
 core=shard_e
 2012-11-02 14:14:50,987 INFO [solrj.impl.HttpClientUtil] - [RecoveryThread] - 
 : Creating new http client, 
 config:maxConnections=128maxConnectionsPerHost=32followRedirects=false
 2012-11-02 14:15:03,303 INFO [solr.core.CachingDirectoryFactory] - 
 [RecoveryThread] - : Releasing directory:/opt/solr/cores/shard_f/data/index
 2012-11-02 14:15:03,303 INFO [solr.handler.SnapPuller] - [RecoveryThread] - : 
 removing temporary index download directory files 
 NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/opt/solr/cores/shard_f/data/index.20121102141424591
  lockFactory=org.apache.lucene.store.SimpleFSLockFactory@1520a48c; 
 maxCacheMB=48.0 maxMergeSizeMB=4.0)
 2012-11-02 14:15:09,421 INFO [apache.zookeeper.ClientCnxn] - 
 [main-SendThread(rot1.zkserver:2181)] - : Client session timed out, have not 
 heard from server in 11873ms for sessionid 0x13abc504486000f, closing socket 
 connection and attempting reconnect
 2012-11-02 14:15:09,422 ERROR [solr.core.SolrCore] - [http-8080-exec-1] - : 
 org.apache.solr.common.SolrException: Ping query caused exception: Java heap 
 space
 .
 .
 2012-11-02 14:15:09,867 INFO [common.cloud.ConnectionManager] - 
 [main-EventThread] - : Watcher 
 org.apache.solr.common.cloud.ConnectionManager@305e7020 
 name:ZooKeeperConnection Watcher:rot1.zkserver:2181,rot2.zkserver:2181 got 
 event WatchedEvent state:Disconnected type:None path:null path:null type:None
 2012-11-02 14:15:09,867 INFO [common.cloud.ConnectionManager] - 
 [main-EventThread] - : zkClient has disconnected
 2012-11-02 14:15:09,869 ERROR [solr.cloud.RecoveryStrategy] - 
 [RecoveryThread] - : Error while trying to 
 recover:java.lang.OutOfMemoryError: Java heap space
 .
 .
 2012-11-02 14:15:10,159 INFO [solr.update.UpdateLog] - [RecoveryThread] - : 
 Dropping buffered updates FSUpdateLog{state=BUFFERING, tlog=null}
 2012-11-02 14:15:10,159 ERROR [solr.cloud.RecoveryStrategy] - 
 [RecoveryThread] - : Recovery failed - trying again... (3) core=shard_e
 2012-11-02 14:15:10,159 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
 - : Wait 16.0 seconds before trying to recover again (4)
 2012-11-02 14:15:09,878 INFO [solr.core.CachingDirectoryFactory] - 
 [RecoveryThread] - : Releasing 
 directory:/opt/solr/cores/shard_f/data/index.20121102141424591
 2012-11-02 14:15:10,192 INFO [solr.core.CachingDirectoryFactory] - 
 [RecoveryThread] - : Releasing

[jira] [Resolved] (SOLR-4038) On OOM, SolrCloud indexing blocks if shard is marked as DOWN


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

Mark Miller resolved SOLR-4038.
---

Resolution: Won't Fix

 On OOM, SolrCloud indexing blocks if shard is marked as DOWN
 

 Key: SOLR-4038
 URL: https://issues.apache.org/jira/browse/SOLR-4038
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0
Reporter: Markus Jelsma
Assignee: Mark Miller
 Fix For: 4.2, 5.0


 See: 
 http://lucene.472066.n3.nabble.com/SolrCloud-indexing-blocks-if-node-is-recovering-td4017827.html
 While indexing (without CloudSolrServer at that time) one node dies with an 
 OOME perhaps  because of the linked issue SOLR-4032. The OOME stack traces 
 are varied but here are some ZK-related logs between the OOME stack traces:
 {code}
 2012-11-02 14:14:37,126 INFO [solr.update.UpdateLog] - [RecoveryThread] - : 
 Dropping buffered updates FSUpdateLog{state=BUFFERING, tlog=null}
 2012-11-02 14:14:37,127 ERROR [solr.cloud.RecoveryStrategy] - 
 [RecoveryThread] - : Recovery failed - trying again... (2) core=shard_e
 2012-11-02 14:14:37,127 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
 - : Wait 8.0 seconds before trying to recover again (3)
 2012-11-02 14:14:45,328 INFO [solr.cloud.ZkController] - [RecoveryThread] - : 
 numShards not found on descriptor - reading it from system property
 2012-11-02 14:14:45,363 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
 - : Starting Replication Recovery. core=shard_e
 2012-11-02 14:14:45,363 INFO [solrj.impl.HttpClientUtil] - [RecoveryThread] - 
 : Creating new http client, 
 config:maxConnections=128maxConnectionsPerHost=32followRedirects=false
 2012-11-02 14:14:45,775 INFO [common.cloud.ZkStateReader] - 
 [main-EventThread] - : A cluster state change has occurred - updating... (10)
 2012-11-02 14:14:50,987 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
 - : Begin buffering updates. core=shard_e
 2012-11-02 14:14:50,987 INFO [solr.update.UpdateLog] - [RecoveryThread] - : 
 Starting to buffer updates. FSUpdateLog{state=ACTIVE, tlog=null}
 2012-11-02 14:14:50,987 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
 - : Attempting to replicate from http://rot05.solrserver:8080/solr/shard_e/. 
 core=shard_e
 2012-11-02 14:14:50,987 INFO [solrj.impl.HttpClientUtil] - [RecoveryThread] - 
 : Creating new http client, 
 config:maxConnections=128maxConnectionsPerHost=32followRedirects=false
 2012-11-02 14:15:03,303 INFO [solr.core.CachingDirectoryFactory] - 
 [RecoveryThread] - : Releasing directory:/opt/solr/cores/shard_f/data/index
 2012-11-02 14:15:03,303 INFO [solr.handler.SnapPuller] - [RecoveryThread] - : 
 removing temporary index download directory files 
 NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/opt/solr/cores/shard_f/data/index.20121102141424591
  lockFactory=org.apache.lucene.store.SimpleFSLockFactory@1520a48c; 
 maxCacheMB=48.0 maxMergeSizeMB=4.0)
 2012-11-02 14:15:09,421 INFO [apache.zookeeper.ClientCnxn] - 
 [main-SendThread(rot1.zkserver:2181)] - : Client session timed out, have not 
 heard from server in 11873ms for sessionid 0x13abc504486000f, closing socket 
 connection and attempting reconnect
 2012-11-02 14:15:09,422 ERROR [solr.core.SolrCore] - [http-8080-exec-1] - : 
 org.apache.solr.common.SolrException: Ping query caused exception: Java heap 
 space
 .
 .
 2012-11-02 14:15:09,867 INFO [common.cloud.ConnectionManager] - 
 [main-EventThread] - : Watcher 
 org.apache.solr.common.cloud.ConnectionManager@305e7020 
 name:ZooKeeperConnection Watcher:rot1.zkserver:2181,rot2.zkserver:2181 got 
 event WatchedEvent state:Disconnected type:None path:null path:null type:None
 2012-11-02 14:15:09,867 INFO [common.cloud.ConnectionManager] - 
 [main-EventThread] - : zkClient has disconnected
 2012-11-02 14:15:09,869 ERROR [solr.cloud.RecoveryStrategy] - 
 [RecoveryThread] - : Error while trying to 
 recover:java.lang.OutOfMemoryError: Java heap space
 .
 .
 2012-11-02 14:15:10,159 INFO [solr.update.UpdateLog] - [RecoveryThread] - : 
 Dropping buffered updates FSUpdateLog{state=BUFFERING, tlog=null}
 2012-11-02 14:15:10,159 ERROR [solr.cloud.RecoveryStrategy] - 
 [RecoveryThread] - : Recovery failed - trying again... (3) core=shard_e
 2012-11-02 14:15:10,159 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] 
 - : Wait 16.0 seconds before trying to recover again (4)
 2012-11-02 14:15:09,878 INFO [solr.core.CachingDirectoryFactory] - 
 [RecoveryThread] - : Releasing 
 directory:/opt/solr/cores/shard_f/data/index.20121102141424591
 2012-11-02 14:15:10,192 INFO [solr.core.CachingDirectoryFactory] - 
 [RecoveryThread] - : Releasing directory:/opt/solr/cores/shard_f_f/data/index
 2012-11-02 14:15:10,192 ERROR [solr.handler.ReplicationHandler] -

[jira] [Updated] (SOLR-4345) Solr Admin UI dosent work in IE 10


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

Stefan Matheis (steffkes) updated SOLR-4345:


Attachment: SOLR-4345.patch

IE10 seems to bring erm .. new Features oO, pretty sure that this piece of 
software will require additional changes in the codebase, but at least this one 
ensures that the UI itself continues working.

For the Reference: [IE was throwing an error because of the missing 
{{document.namespaces}}-object|https://github.com/gwatts/jquery.sparkline/pull/19]

 Solr Admin UI dosent work in IE 10
 --

 Key: SOLR-4345
 URL: https://issues.apache.org/jira/browse/SOLR-4345
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
 Environment: Windows 8, IE 10
Reporter: Kurt Pedersen
  Labels: IE, IE10, InternetExplorer
 Fix For: 4.2, 5.0

 Attachments: SOLR-4345.patch, solr-ie10.png


 The main Windows only shows Loading on IE 10. Working fine in Chrome.

--
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-4691) Facet tests should randomly pick IntEncoder and other stuff

2013-01-24 Thread Michael McCandless (JIRA)

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

Michael McCandless commented on LUCENE-4691:

Facet tests should randomly pick IntEncoder and other stuff
---

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

[jira] [Assigned] (SOLR-4345) Solr Admin UI dosent work in IE 10


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

Stefan Matheis (steffkes) reassigned SOLR-4345:
---

Assignee: Stefan Matheis (steffkes)

 Solr Admin UI dosent work in IE 10
 --

 Key: SOLR-4345
 URL: https://issues.apache.org/jira/browse/SOLR-4345
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
 Environment: Windows 8, IE 10
Reporter: Kurt Pedersen
Assignee: Stefan Matheis (steffkes)
  Labels: IE, IE10, InternetExplorer
 Fix For: 4.2, 5.0

 Attachments: SOLR-4345.patch, solr-ie10.png


 The main Windows only shows Loading on IE 10. Working fine in Chrome.

--
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-4349) Admin UI - Query Interface does not work in IE


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

Stefan Matheis (steffkes) updated SOLR-4349:


Attachment: IE10-Query-Interface.png

 Admin UI - Query Interface does not work in IE
 --

 Key: SOLR-4349
 URL: https://issues.apache.org/jira/browse/SOLR-4349
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
 Attachments: IE10-Query-Interface.png


 While fiddeling with SOLR-4345, i realized that the Query-Interface does not 
 really work in IE (at least IE10, i guess that's also valid for IE9 and maybe 
 others)
 The Interface itself (including the Form on the left side, including various 
 options) is there, but if you submit the Form, the result is always empty (as 
 in 0 Documents returned) because of the used url:
 bq. http://host:port/solr/collection1/select?

--
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-4349) Admin UI - Query Interface does not work in IE

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

 Summary: Admin UI - Query Interface does not work in IE
 Key: SOLR-4349
 URL: https://issues.apache.org/jira/browse/SOLR-4349
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
 Attachments: IE10-Query-Interface.png

While fiddeling with SOLR-4345, i realized that the Query-Interface does not 
really work in IE (at least IE10, i guess that's also valid for IE9 and maybe 
others)

The Interface itself (including the Form on the left side, including various 
options) is there, but if you submit the Form, the result is always empty (as 
in 0 Documents returned) because of the used url:

bq. http://host:port/solr/collection1/select?

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

Proposal to move/hide the general@lucene list

2013-01-24 Thread Smiley, David W.

The gene...@lucene.apache.org list is often misused for help on Lucene or Solr 
that belong on their respective lists.

I'm okay with the list being discontinued.  If people are not okay with that, 
then I propose modifying the page where people currently discover the list so 
that they aren't likely to use it instead of the proper list.
http://lucene.apache.org/core/discussion.html#general-discussion-generallucenehttp://lucene.apache.org/core/discussion.html
Perhaps a simply adding the text NOT for users seeking help with Lucene 
message in red.  I can see how users, in a hurry, can look at the existing 
description (without having red the java-user list prior) and think that the 
general list is the right place.

~ David

[jira] [Commented] (LUCENE-4690) Optimize NumericUtils.*ToPrefixCoded(), add versions that don't hash

2013-01-24 Thread Robert Muir (JIRA)


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

Robert Muir commented on LUCENE-4690:
-

Seems good to me to have non-hashing versions (these versions exist for 
unicodeutil for terms already for similar purposes)

 Optimize NumericUtils.*ToPrefixCoded(), add versions that don't hash
 

 Key: LUCENE-4690
 URL: https://issues.apache.org/jira/browse/LUCENE-4690
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
Priority: Minor
 Attachments: LUCENE-4690.patch


 As far as I can tell nothing actually uses the hash codes generated by these 
 methods (not even any tests).  If someone did want to generate a hash, it 
 would be just as fast to do it on the BytesRef after the fact (or even faster 
 from the input number itself).
 edit: Uwe pointed out they were used in one place.  Other places still don't 
 need 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] [Commented] (SOLR-4343) Solrcloud 4.1 inconsistent # of results in replicas

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

Mark Miller commented on SOLR-4343:
---

bq. but a few OOMs on the replica.

OOM's will pretty much screw you. Best thing to do is to pass the command line
arg when starting the vm that lets you run an arbitrary command on OOM - then
in that cmd you kill the process, log the problem - then if the process is not
supervised, start it again.

Try giving it more RAM.

Solrcloud 4.1 inconsistent # of results in replicas

Key: SOLR-4343
URL: https://issues.apache.org/jira/browse/SOLR-4343
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.1
Environment: Ubuntu12.04 / Java 1.7.11 / Tomcat7 / Zookeeper 3.4.5
Reporter: Joseph Dale
Priority: Critical

I have a one shard collection, with one replica.
I did a dataImport from my oracle DB.
In the master, I have 93835 docs, in the non master 92627.
I have tried http://machinename:8080/solr/collection/update/commit=true on
the master, but the index does not replicate the replica.
Also, the node list different generations of the core.
I have left it alone for 2 hours and they never sync. Both nodes think that
they are current, only on really is. I can reproduce this 100% of the time.
-Joey

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

[jira] [Created] (LUCENE-4716) Add OR support to DrillDown

Shai Erera created LUCENE-4716:
--

 Summary: Add OR support to DrillDown
 Key: LUCENE-4716
 URL: https://issues.apache.org/jira/browse/LUCENE-4716
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera


DrillDown provides helper methods to wrap a baseQuery with drill-down 
categories. All the categories are AND'ed, and it has been asked on the user 
list for OR support. While users can construct their own BooleanQuery, it would 
be useful if DrillDown helped them doing that. I think that a simple Occur 
additional parameter to DrillDown.query will help to some extent.

--
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-4349) Admin UI - Query Interface does not work in IE


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

Stefan Matheis (steffkes) updated SOLR-4349:


Attachment: SOLR-4349.patch

I have no clue why, but {{form.elements}} seems to be {{undefined}} so, we use 
the semantic option (which uses {{form.getElementsByTagName('*')}} under the 
hood, this is slightly slower, but does in fact the same job)

 Admin UI - Query Interface does not work in IE
 --

 Key: SOLR-4349
 URL: https://issues.apache.org/jira/browse/SOLR-4349
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
 Attachments: IE10-Query-Interface.png, SOLR-4349.patch


 While fiddeling with SOLR-4345, i realized that the Query-Interface does not 
 really work in IE (at least IE10, i guess that's also valid for IE9 and maybe 
 others)
 The Interface itself (including the Form on the left side, including various 
 options) is there, but if you submit the Form, the result is always empty (as 
 in 0 Documents returned) because of the used url:
 bq. http://host:port/solr/collection1/select?

--
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: Proposal to move/hide the general@lucene list

2013-01-24 Thread Otis Gospodnetic

+1 for getting rid of it.  Doesn't seem to serve any purpose.

Otis
--
Solr  ElasticSearch Support
http://sematext.com/





On Thu, Jan 24, 2013 at 11:19 AM, Smiley, David W. dsmi...@mitre.orgwrote:

  The gene...@lucene.apache.org list is often misused for help on Lucene
 or Solr that belong on their respective lists.

  I'm okay with the list being discontinued.  If people are not okay with
 that, then I propose modifying the page where people currently discover the
 list so that they aren't likely to use it instead of the proper list.

 http://lucene.apache.org/core/discussion.html#general-discussion-generallucenehttp://lucene.apache.org/core/discussion.html
 Perhaps a simply adding the text NOT for users seeking help with Lucene
 message in red.  I can see how users, in a hurry, can look at the existing
 description (without having red the java-user list prior) and think that
 the general list is the right place.

  ~ David

[jira] [Updated] (LUCENE-4708) Make LZ4 hash tables reusable

2013-01-24 Thread Adrien Grand (JIRA)


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

Adrien Grand updated LUCENE-4708:
-

Attachment: LUCENE-4708.patch

Patch. I plan to commit soon.

 Make LZ4 hash tables reusable
 -

 Key: LUCENE-4708
 URL: https://issues.apache.org/jira/browse/LUCENE-4708
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Attachments: LUCENE-4708.patch


 Currently LZ4 compressors instantiate their own hash table for every byte 
 sequence they need to compress. These can be large (256KB for LZ4 HC) so we 
 should try to reuse them across calls.

--
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: Post-sort filtering

2013-01-24 Thread Erick Erickson

this has some problems. First, your facet, group, num hits, etc.
counts will be off for that user. Second, you can't sort without
having all of the documents, so unless you're willing to have your
counts be off, you really have to pay the price of post-filtering
everything.

If you can live with the counts being off, consider just having the
application do a couple of round-trips. Get the docs (oversample, say
just get the IDs for the top 100 docs) _without_ any kind of ACL
filtering. Then send those docs back to the server with the ACL
filtering. If you don't get enough to fill up a response, get the next
page of 100, etc.

Finally, the user's list is a better place for this kind of question,
this list is for discussing developing the code...

Best
Erick

On Wed, Jan 23, 2013 at 9:05 AM, Steve Molloy smol...@opentext.com wrote:
 Hi,

 I'm looking for a way to apply filtering that unfortunately implies high
 cost because it needs to access external resources (for security). I looked
 at (and tried) the PostFilter technique, which offers some advantages, but
 still imply a lot of matches in a lot of cases. What I'd like to be able to
 do is to filter out ids until I have enough to fill the response, then stop
 filtering (and accept everything). The idea being that total count is not as
 important, major thing being results should not contain documents requester
 should not see. So, post filter almost does the trick, except it comes
 before sorting, so first X documents are not the same that the post filter
 is getting.

 Is there a way to filter out documents after they have been scored and
 sorted?

 Thanks,
 Steve



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

RE: Post-sort filtering

2013-01-24 Thread Steve Molloy

I was actually looking for an extension point to plug in, which I wasn't able 
to find looking at the code. And yes, I'm willing to have counts being off, the 
important thing being that results don't contain the wrong document. I'd like 
to avoid oversampling and requesting back because of the bandwidth and overall 
resource usage this implies. I'm currently trying out a PostSortFilter 
approach that I'll share if it seems interesting enough.

Steve Molloy
Software Architect  |  Information Discovery  Analytics RD
Website:
www.opentext.com



This email message is confidential, may be privileged, and is intended for the 
exclusive use of the addressee. Any other person is strictly prohibited from 
disclosing or reproducing it. If the addressee cannot be reached or is unknown 
to you, please inform the sender by return email and delete this email message 
and all copies immediately.


-Original Message-
From: Erick Erickson [mailto:erickerick...@gmail.com] 
Sent: January-24-13 1:11 PM
To: dev@lucene.apache.org
Subject: Re: Post-sort filtering

this has some problems. First, your facet, group, num hits, etc.
counts will be off for that user. Second, you can't sort without having all of 
the documents, so unless you're willing to have your counts be off, you really 
have to pay the price of post-filtering everything.

If you can live with the counts being off, consider just having the application 
do a couple of round-trips. Get the docs (oversample, say just get the IDs for 
the top 100 docs) _without_ any kind of ACL filtering. Then send those docs 
back to the server with the ACL filtering. If you don't get enough to fill up a 
response, get the next page of 100, etc.

Finally, the user's list is a better place for this kind of question, this list 
is for discussing developing the code...

Best
Erick

On Wed, Jan 23, 2013 at 9:05 AM, Steve Molloy smol...@opentext.com wrote:
 Hi,

 I'm looking for a way to apply filtering that unfortunately 
 implies high cost because it needs to access external resources (for 
 security). I looked at (and tried) the PostFilter technique, which 
 offers some advantages, but still imply a lot of matches in a lot of 
 cases. What I'd like to be able to do is to filter out ids until I 
 have enough to fill the response, then stop filtering (and accept 
 everything). The idea being that total count is not as important, 
 major thing being results should not contain documents requester 
 should not see. So, post filter almost does the trick, except it comes 
 before sorting, so first X documents are not the same that the post filter is 
 getting.

 Is there a way to filter out documents after they have been scored and 
 sorted?

 Thanks,
 Steve



-
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] [Created] (LUCENE-4717) Lucene40's DocValues (sometimes?) have a bogus extra ordinal

2013-01-24 Thread Robert Muir (JIRA)

Robert Muir created LUCENE-4717:
---

 Summary: Lucene40's DocValues (sometimes?) have a bogus extra 
ordinal
 Key: LUCENE-4717
 URL: https://issues.apache.org/jira/browse/LUCENE-4717
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 4.1, 4.0
Reporter: Robert Muir
 Fix For: 4.2


I committed the following commented out check in CheckIndex:
{noformat}
  if (seenOrds.cardinality() != sortedValues.getValueCount()) {
// TODO: find the bug here and figure out a workaround (we can 
implement in LUCENE-4547's back compat layer maybe)
// basically ord 0 is unused by any docs: so the sortedbytes ords are 
all off-by-one
// does it always happen? e.g. maybe only if there are missing values? 
or a bug in its merge optimizations?
// throw new RuntimeException(dv for field:  + fieldName +  has 
holes in its ords, valueCount= + sortedValues.getValueCount() +  but only 
used:  + seenOrds.cardinality());
  }
{noformat}

I'd really like to have this check in CheckIndex, and so it would be great to 
understand the conditions when the bug happens, and if we can correct it 
on-the-fly in Lucene40DocValuesReader in LUCENE-4547 branch... otherwise we 
will have to conditionalize the check based on when the segment was written (it 
will ultimately be corrected on merge, just annoying)


--
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-4345) Solr Admin UI dosent work in IE 10


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

Stefan Matheis (steffkes) resolved SOLR-4345.
-

Resolution: Fixed

 Solr Admin UI dosent work in IE 10
 --

 Key: SOLR-4345
 URL: https://issues.apache.org/jira/browse/SOLR-4345
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
 Environment: Windows 8, IE 10
Reporter: Kurt Pedersen
Assignee: Stefan Matheis (steffkes)
  Labels: IE, IE10, InternetExplorer
 Fix For: 4.2, 5.0

 Attachments: SOLR-4345.patch, solr-ie10.png


 The main Windows only shows Loading on IE 10. Working fine in Chrome.

--
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-4349) Admin UI - Query Interface does not work in IE


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

Stefan Matheis (steffkes) updated SOLR-4349:


Labels: IE IE10 InternetExplorer  (was: )

 Admin UI - Query Interface does not work in IE
 --

 Key: SOLR-4349
 URL: https://issues.apache.org/jira/browse/SOLR-4349
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
  Labels: IE, IE10, InternetExplorer
 Attachments: IE10-Query-Interface.png, SOLR-4349.patch


 While fiddeling with SOLR-4345, i realized that the Query-Interface does not 
 really work in IE (at least IE10, i guess that's also valid for IE9 and maybe 
 others)
 The Interface itself (including the Form on the left side, including various 
 options) is there, but if you submit the Form, the result is always empty (as 
 in 0 Documents returned) because of the used url:
 bq. http://host:port/solr/collection1/select?

--
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-4345) Solr Admin UI dosent work in IE 10


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

Commit Tag Bot commented on SOLR-4345:
--

[trunk commit] Stefan Matheis
http://svn.apache.org/viewvc?view=revisionrevision=1438136

SOLR-4345 : Solr Admin UI dosent work in IE 10


 Solr Admin UI dosent work in IE 10
 --

 Key: SOLR-4345
 URL: https://issues.apache.org/jira/browse/SOLR-4345
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
 Environment: Windows 8, IE 10
Reporter: Kurt Pedersen
Assignee: Stefan Matheis (steffkes)
  Labels: IE, IE10, InternetExplorer
 Fix For: 4.2, 5.0

 Attachments: SOLR-4345.patch, solr-ie10.png


 The main Windows only shows Loading on IE 10. Working fine in Chrome.

--
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-4349) Admin UI - Query Interface does not work in IE


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

Stefan Matheis (steffkes) resolved SOLR-4349.
-

   Resolution: Fixed
Fix Version/s: 5.0
   4.2

 Admin UI - Query Interface does not work in IE
 --

 Key: SOLR-4349
 URL: https://issues.apache.org/jira/browse/SOLR-4349
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
  Labels: IE, IE10, InternetExplorer
 Fix For: 4.2, 5.0

 Attachments: IE10-Query-Interface.png, SOLR-4349.patch


 While fiddeling with SOLR-4345, i realized that the Query-Interface does not 
 really work in IE (at least IE10, i guess that's also valid for IE9 and maybe 
 others)
 The Interface itself (including the Form on the left side, including various 
 options) is there, but if you submit the Form, the result is always empty (as 
 in 0 Documents returned) because of the used url:
 bq. http://host:port/solr/collection1/select?

--
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-4345) Solr Admin UI dosent work in IE 10


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

Commit Tag Bot commented on SOLR-4345:
--

[branch_4x commit] Stefan Matheis
http://svn.apache.org/viewvc?view=revisionrevision=1438137

SOLR-4345 : Solr Admin UI dosent work in IE 10 (merge r1438136)


 Solr Admin UI dosent work in IE 10
 --

 Key: SOLR-4345
 URL: https://issues.apache.org/jira/browse/SOLR-4345
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
 Environment: Windows 8, IE 10
Reporter: Kurt Pedersen
Assignee: Stefan Matheis (steffkes)
  Labels: IE, IE10, InternetExplorer
 Fix For: 4.2, 5.0

 Attachments: SOLR-4345.patch, solr-ie10.png


 The main Windows only shows Loading on IE 10. Working fine in Chrome.

--
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-4349) Admin UI - Query Interface does not work in IE


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

Commit Tag Bot commented on SOLR-4349:
--

[branch_4x commit] Stefan Matheis
http://svn.apache.org/viewvc?view=revisionrevision=1438140

SOLR-4349 : Admin UI - Query Interface does not work in IE (merge r1438139)


 Admin UI - Query Interface does not work in IE
 --

 Key: SOLR-4349
 URL: https://issues.apache.org/jira/browse/SOLR-4349
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
  Labels: IE, IE10, InternetExplorer
 Fix For: 4.2, 5.0

 Attachments: IE10-Query-Interface.png, SOLR-4349.patch


 While fiddeling with SOLR-4345, i realized that the Query-Interface does not 
 really work in IE (at least IE10, i guess that's also valid for IE9 and maybe 
 others)
 The Interface itself (including the Form on the left side, including various 
 options) is there, but if you submit the Form, the result is always empty (as 
 in 0 Documents returned) because of the used url:
 bq. http://host:port/solr/collection1/select?

--
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-4349) Admin UI - Query Interface does not work in IE


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

Commit Tag Bot commented on SOLR-4349:
--

[trunk commit] Stefan Matheis
http://svn.apache.org/viewvc?view=revisionrevision=1438139

SOLR-4349 : Admin UI - Query Interface does not work in IE


 Admin UI - Query Interface does not work in IE
 --

 Key: SOLR-4349
 URL: https://issues.apache.org/jira/browse/SOLR-4349
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
  Labels: IE, IE10, InternetExplorer
 Fix For: 4.2, 5.0

 Attachments: IE10-Query-Interface.png, SOLR-4349.patch


 While fiddeling with SOLR-4345, i realized that the Query-Interface does not 
 really work in IE (at least IE10, i guess that's also valid for IE9 and maybe 
 others)
 The Interface itself (including the Form on the left side, including various 
 options) is there, but if you submit the Form, the result is always empty (as 
 in 0 Documents returned) because of the used url:
 bq. http://host:port/solr/collection1/select?

--
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-4196) Untangle XML-specific nature of Config and Container classes

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

Erick Erickson updated SOLR-4196:
-

Attachment: SOLR-4196.patch

Fixed the test that failed, silly error in writing the test.

This is perilously close to being ready to commit, I'd appreciate it if anyone
who has a chance can take a look. There are a _lot_ of changes, so I expect to
check it in to trunk and let it bake for a bit before merging to 4.x.

What worries me most is that I had to change how solr.xml is handled. If the
new functionality is broken that's one thing, but if old functionality is
broken that's more serious. Any comments about how I handled solr.xml (the
current way we do things) are welcome. I suppose if people are very kind they
could apply the patch (trunk, haven't tried to apply it to 4.x yet) and beast
it.

The test cases work, what I want to do now is spin up a whole bunch of cores on
my machine and just try it just running Solr rather than from the test harness,
merrily swapping cores in and out, updating to non-present cores, then querying
them etc. Shouldn't be too difficult, and if that works I'll be committing to
trunk first.

There are still several JIRAs that need to be completed before this is feature
complete, but I think by far most of the work is contained in this JIRA and
SOLR-1028 (this latter is already committed).

Untangle XML-specific nature of Config and Container classes

Key: SOLR-4196
URL: https://issues.apache.org/jira/browse/SOLR-4196
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
Fix For: 4.2, 5.0

Attachments: SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch,
SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch,
SOLR-4196.patch

sub-task for SOLR-4083. If we're going to try to obsolete solr.xml, we need
to pull all of the specific XML processing out of Config and Container.
Currently, we refer to xpaths all over the place. This JIRA is about
providing a thunking layer to isolate the XML-esque nature of solr.xml and
allow a simple properties file to be used instead which will lead,
eventually, to solr.xml going away.

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

[jira] [Created] (SOLR-4350) Deleting the data directory on master and reindexing causes slaves to out of sync

2013-01-24 Thread Senthuran Sivananthan (JIRA)

Senthuran Sivananthan created SOLR-4350:
---

 Summary: Deleting the data directory on master and reindexing 
causes slaves to out of sync
 Key: SOLR-4350
 URL: https://issues.apache.org/jira/browse/SOLR-4350
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 4.1
 Environment: Windows
Reporter: Senthuran Sivananthan
Priority: Minor


This issue occurs only when the data directory is deleted manually on the 
master instance.

Here are the steps that I used to replicate the issue:

Master - Shutdown
Master - Delete Data Directory
Slave - Replication triggers, but no connection to master, replicaiton fails
Master - Start Up
Master - Index all docs
Master - Shutdown
Master - Start Up

Expected: Slave - Replication triggers, connected to master, new index 
replications, master  slave in sync

Actual:  Slave - Replication triggers, connected to master, error seen in the 
logs: SEVERE: No files to download for index generation: 2

  * Nothing will replicate even if master generation  slave generation

Workaround:

  * Must trigger another commit on master after the restart
* Replicates even if master generation  slave generation (and gets the 
generations in sync)

* Replicates when master generation  slave generation

--
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-4350) Deleting the data directory on master and reindexing causes slaves to be out of sync (if replication doesn't take place before a master instance restart)

2013-01-24 Thread Senthuran Sivananthan (JIRA)


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

Senthuran Sivananthan updated SOLR-4350:


Summary: Deleting the data directory on master and reindexing causes slaves 
to be out of sync (if replication doesn't take place before a master instance 
restart)  (was: Deleting the data directory on master and reindexing causes 
slaves to out of sync)

 Deleting the data directory on master and reindexing causes slaves to be out 
 of sync (if replication doesn't take place before a master instance restart)
 -

 Key: SOLR-4350
 URL: https://issues.apache.org/jira/browse/SOLR-4350
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 4.1
 Environment: Windows
Reporter: Senthuran Sivananthan
Priority: Minor
  Labels: replication

 This issue occurs only when the data directory is deleted manually on the 
 master instance.
 Here are the steps that I used to replicate the issue:
 Master - Shutdown
 Master - Delete Data Directory
 Slave - Replication triggers, but no connection to master, replicaiton fails
 Master - Start Up
 Master - Index all docs
 Master - Shutdown
 Master - Start Up
 Expected: Slave - Replication triggers, connected to master, new index 
 replications, master  slave in sync
 Actual:  Slave - Replication triggers, connected to master, error seen in the 
 logs: SEVERE: No files to download for index generation: 2
   * Nothing will replicate even if master generation  slave generation
 Workaround:
   * Must trigger another commit on master after the restart
   * Replicates even if master generation  slave generation (and gets the 
 generations in sync)
   * Replicates when master generation  slave generation

--
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-4350) Deleting the data directory on master and reindexing causes slaves to be out of sync (if replication doesn't take place before a master instance restart)

2013-01-24 Thread Senthuran Sivananthan (JIRA)


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

Senthuran Sivananthan updated SOLR-4350:


Description: 
This issue occurs only when the data directory is deleted manually on the 
master instance.

Here are the steps that I used to replicate the issue:

Master - Shutdown
Master - Delete Data Directory
Slave - Replication triggers, but no connection to master, replicaiton fails
Master - Start Up
Master - Index all docs
Master - Shutdown
Master - Start Up

Expected: Slave - Replication triggers, connected to master, new index 
replications, master  slave in sync

Actual:  Slave - Replication triggers, connected to master, error seen in the 
logs: SEVERE: No files to download for index generation: 2

  * Nothing will replicate even if master generation  slave generation

Workaround:

  * Must trigger another commit on master after the restart
* Replicates even if master generation  slave generation (and gets the 
generations in sync)
* Replicates when master generation  slave generation

  was:
This issue occurs only when the data directory is deleted manually on the 
master instance.

Here are the steps that I used to replicate the issue:

Master - Shutdown
Master - Delete Data Directory
Slave - Replication triggers, but no connection to master, replicaiton fails
Master - Start Up
Master - Index all docs
Master - Shutdown
Master - Start Up

Expected: Slave - Replication triggers, connected to master, new index 
replications, master  slave in sync

Actual:  Slave - Replication triggers, connected to master, error seen in the 
logs: SEVERE: No files to download for index generation: 2

  * Nothing will replicate even if master generation  slave generation

Workaround:

  * Must trigger another commit on master after the restart
* Replicates even if master generation  slave generation (and gets the 
generations in sync)

* Replicates when master generation  slave generation


 Deleting the data directory on master and reindexing causes slaves to be out 
 of sync (if replication doesn't take place before a master instance restart)
 -

 Key: SOLR-4350
 URL: https://issues.apache.org/jira/browse/SOLR-4350
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 4.1
 Environment: Windows
Reporter: Senthuran Sivananthan
Priority: Minor
  Labels: replication

 This issue occurs only when the data directory is deleted manually on the 
 master instance.
 Here are the steps that I used to replicate the issue:
 Master - Shutdown
 Master - Delete Data Directory
 Slave - Replication triggers, but no connection to master, replicaiton fails
 Master - Start Up
 Master - Index all docs
 Master - Shutdown
 Master - Start Up
 Expected: Slave - Replication triggers, connected to master, new index 
 replications, master  slave in sync
 Actual:  Slave - Replication triggers, connected to master, error seen in the 
 logs: SEVERE: No files to download for index generation: 2
   * Nothing will replicate even if master generation  slave generation
 Workaround:
   * Must trigger another commit on master after the restart
   * Replicates even if master generation  slave generation (and gets the 
 generations in sync)
   * Replicates when master generation  slave generation

--
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-4351) JSON QParser integration

2013-01-24 Thread Yonik Seeley (JIRA)

Yonik Seeley created SOLR-4351:
--

 Summary: JSON QParser integration
 Key: SOLR-4351
 URL: https://issues.apache.org/jira/browse/SOLR-4351
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley


Our QParser framework currently gets parameters from localParams.  JSON 
integration would allow specifying parameters to the parsers in JSON.

--
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-4691) Facet tests should randomly pick IntEncoder and other stuff


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

Commit Tag Bot commented on LUCENE-4691:


[trunk commit] Shai Erera
http://svn.apache.org/viewvc?view=revisionrevision=1438188

LUCENE-4691: Facet tests should randomly pick IntEncoder and other stuff


 Facet tests should randomly pick IntEncoder and other stuff
 ---

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


 Facets have many encoders already, but only one of them is tested by all 
 facet tests (the default). While {{EncodingTest}} covers all encoders, I 
 already fixed it because it didn't catch a bug where one encoder didn't reset 
 the given {{BytesRef}}. It will be useful if tests could choose a 
 randomCategoryListParams(), or randomFacetIndexingParams() etc., to swap in 
 random encoders.
 Also, I wrote an AssertingCategoryListIterator which asserts all kind of 
 things (e.g. that if setNextReader returns false, getOrdinals isn't called). 
 Would be good to use it by all tests.
 To do that, I think that it would be best if all facet tests extend a 
 FacetTestCase with such utility methods.

--
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-4351) JSON QParser integration

2013-01-24 Thread Yonik Seeley (JIRA)


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

Yonik Seeley updated SOLR-4351:
---

Attachment: SOLR-4351.patch

Here's a quick prototype.
QParser was changed to take Object instead of String.  ObjectSolrParams is a 
new SolrParams implementation that can deal with objects rather than just 
strings, and JSON is used to populate that.

Lots of stuff just works since it simply builds on our QParser framework and 
all of the existing QParser implementations.

Examples of what currently works:
{code}
{'term':{'id':'11'}}
{'field':{'text':'Now Cow'}}
{'prefix':{'text':'brow'}}
{'frange':{'v':'mul(foo_i,2)', 'l':20,'u':24}}}
{'join':{'from':'qqq_s', 'to':'www_s', 'v':'id:10'}}
{'join':{'from':'qqq_s', 'to':'www_s', 'v':{'term':{'id':'10'
{'lucene':'text:Cow -id:1'}
{code}

 JSON QParser integration
 

 Key: SOLR-4351
 URL: https://issues.apache.org/jira/browse/SOLR-4351
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
 Attachments: SOLR-4351.patch


 Our QParser framework currently gets parameters from localParams.  JSON 
 integration would allow specifying parameters to the parsers in JSON.

--
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-4717) Lucene40's DocValues (sometimes?) have a bogus extra ordinal

2013-01-24 Thread Robert Muir (JIRA)


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

Robert Muir commented on LUCENE-4717:
-

I committed a fix to detect and correct this to the branch I'm happy with: 
http://svn.apache.org/viewvc?view=revisionrevision=1438195

We can resolve it when LUCENE-4547 lands.

 Lucene40's DocValues (sometimes?) have a bogus extra ordinal
 

 Key: LUCENE-4717
 URL: https://issues.apache.org/jira/browse/LUCENE-4717
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 4.0, 4.1
Reporter: Robert Muir
 Fix For: 4.2


 I committed the following commented out check in CheckIndex:
 {noformat}
   if (seenOrds.cardinality() != sortedValues.getValueCount()) {
 // TODO: find the bug here and figure out a workaround (we can 
 implement in LUCENE-4547's back compat layer maybe)
 // basically ord 0 is unused by any docs: so the sortedbytes ords are 
 all off-by-one
 // does it always happen? e.g. maybe only if there are missing 
 values? or a bug in its merge optimizations?
 // throw new RuntimeException(dv for field:  + fieldName +  has 
 holes in its ords, valueCount= + sortedValues.getValueCount() +  but only 
 used:  + seenOrds.cardinality());
   }
 {noformat}
 I'd really like to have this check in CheckIndex, and so it would be great to 
 understand the conditions when the bug happens, and if we can correct it 
 on-the-fly in Lucene40DocValuesReader in LUCENE-4547 branch... otherwise we 
 will have to conditionalize the check based on when the segment was written 
 (it will ultimately be corrected on merge, just annoying)

--
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-4691) Facet tests should randomly pick IntEncoder and other stuff

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

Shai Erera resolved LUCENE-4691.

Resolution: Fixed
Fix Version/s: 5.0
4.2

Committed to trunk and 4x.

Facet tests should randomly pick IntEncoder and other stuff
---

Key: LUCENE-4691
URL: https://issues.apache.org/jira/browse/LUCENE-4691
Project: Lucene - Core
Issue Type: Test
Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera
Fix For: 4.2, 5.0

Attachments: LUCENE-4691.patch

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

[jira] [Commented] (LUCENE-4691) Facet tests should randomly pick IntEncoder and other stuff


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

Commit Tag Bot commented on LUCENE-4691:


[branch_4x commit] Shai Erera
http://svn.apache.org/viewvc?view=revisionrevision=1438199

LUCENE-4691: Facet tests should randomly pick IntEncoder and other stuff


 Facet tests should randomly pick IntEncoder and other stuff
 ---

 Key: LUCENE-4691
 URL: https://issues.apache.org/jira/browse/LUCENE-4691
 Project: Lucene - Core
  Issue Type: Test
  Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera
 Fix For: 4.2, 5.0

 Attachments: LUCENE-4691.patch


 Facets have many encoders already, but only one of them is tested by all 
 facet tests (the default). While {{EncodingTest}} covers all encoders, I 
 already fixed it because it didn't catch a bug where one encoder didn't reset 
 the given {{BytesRef}}. It will be useful if tests could choose a 
 randomCategoryListParams(), or randomFacetIndexingParams() etc., to swap in 
 random encoders.
 Also, I wrote an AssertingCategoryListIterator which asserts all kind of 
 things (e.g. that if setNextReader returns false, getOrdinals isn't called). 
 Would be good to use it by all tests.
 To do that, I think that it would be best if all facet tests extend a 
 FacetTestCase with such utility methods.

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

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

Build failed in Jenkins: the 4547 machine gun #3

See http://fortyounce.servebeer.com/job/the%204547%20machine%20gun/3/

--
[...truncated 969 lines...]
[junit4:junit4] Completed on J2 in 0.08s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestRollingBuffer
[junit4:junit4] Completed on J1 in 0.05s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.util.junitcompat.TestSystemPropertiesInvariantRule
[junit4:junit4] Completed on J2 in 0.09s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestWildcard
[junit4:junit4] Completed on J1 in 0.22s, 8 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced2
[junit4:junit4] Completed on J3 in 0.34s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestSizeBoundedForceMerge
[junit4:junit4] Completed on J2 in 0.09s, 11 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestIdentityHashSet
[junit4:junit4] Completed on J1 in 0.07s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestAutomatonQuery
[junit4:junit4] Completed on J3 in 0.12s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.search.TestComplexExplanationsOfNonMatches
[junit4:junit4] Completed on J2 in 0.12s, 22 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestCheckIndex
[junit4:junit4] Completed on J1 in 0.08s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestDocCount
[junit4:junit4] Completed on J3 in 0.12s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq
[junit4:junit4] Completed on J2 in 0.09s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestUniqueTermCount
[junit4:junit4] Completed on J1 in 0.09s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestPerSegmentDeletes
[junit4:junit4] Completed on J3 in 0.03s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestBinaryTerms
[junit4:junit4] Completed on J2 in 0.04s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestParallelReaderEmptyIndex
[junit4:junit4] Completed on J1 in 0.02s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.document.TestDocument
[junit4:junit4] Completed on J3 in 0.08s, 11 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestIndexWriterConfig
[junit4:junit4] Completed on J2 in 0.02s, 9 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.util.junitcompat.TestBeforeAfterOverrides
[junit4:junit4] Completed on J1 in 0.02s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestSetOnce
[junit4:junit4] Completed on J3 in 0.02s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestFilteredSearch
[junit4:junit4] Completed on J2 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestDocValuesScoring
[junit4:junit4] Completed on J1 in 0.10s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.util.junitcompat.TestSetupTeardownChaining
[junit4:junit4] Completed on J3 in 0.01s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestCachingWrapperFilter
[junit4:junit4] Completed on J2 in 0.03s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestTermScorer
[junit4:junit4] Completed on J1 in 0.02s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.Test2BPostings
[junit4:junit4] IGNOR/A 0.02s J3 | Test2BPostings.test
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] Completed on J3 in 0.03s, 1 test, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestFieldValueFilter
[junit4:junit4] Completed on J2 in 0.08s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestDateFilter
[junit4:junit4] Completed on J1 in 0.01s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestMultiTermQueryRewrites
[junit4:junit4] Completed on J3 in 0.02s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestSegmentTermEnum
[junit4:junit4] Completed on J2 in 0.07s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced
[junit4:junit4] Completed on J1 in 0.03s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestBooleanScorer
[junit4:junit4] Completed on J3 in 0.12s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestRecyclingByteBlockAllocator
[junit4:junit4] Completed on J2 in 0.02s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.store.TestDirectory
[junit4:junit4] IGNOR/A 0.00s J1 | TestDirectory.testThreadSafety
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] Completed on J1 in 0.02s, 8 tests, 1 skipped
[junit4:junit4]

Jenkins build is back to normal : the 4547 machine gun #4

See http://fortyounce.servebeer.com/job/the%204547%20machine%20gun/4/


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

[jira] [Updated] (LUCENE-4716) Add OR support to DrillDown


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

Shai Erera updated LUCENE-4716:
---

Attachment: LUCENE-4716.patch

Patch adds Occur to DrillDown.query, and matching test for Occur.SHOULD. All 
tests pass.

 Add OR support to DrillDown
 ---

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


 DrillDown provides helper methods to wrap a baseQuery with drill-down 
 categories. All the categories are AND'ed, and it has been asked on the user 
 list for OR support. While users can construct their own BooleanQuery, it 
 would be useful if DrillDown helped them doing that. I think that a simple 
 Occur additional parameter to DrillDown.query will help to some extent.

--
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-4352) Velocity-base pagination should support/preserve sorting

2013-01-24 Thread Eric Spiegelberg (JIRA)

Eric Spiegelberg created SOLR-4352:
--

 Summary: Velocity-base pagination should support/preserve sorting
 Key: SOLR-4352
 URL: https://issues.apache.org/jira/browse/SOLR-4352
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Eric Spiegelberg


When performing /browse, the Velocity generated UI does not support sorting in 
the generated pagination links.

The link_to_previous_page and link_to_next_page macros found within 
[apache-solr-4.0.0]/example/solr/collection1/conf/velocity/VM_global_library.vm 
should be modified to maintain/preserve an existing sort parameter.

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

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

Re: Build failed in Jenkins: the 4547 machine gun #3

2013-01-24 Thread Michael McCandless

I committed a fix ...

Mike McCandless

http://blog.mikemccandless.com


On Thu, Jan 24, 2013 at 4:31 PM, Charlie Cron hudsonsevilt...@gmail.comwrote:

 See http://fortyounce.servebeer.com/job/the%204547%20machine%20gun/3/

 --
 [...truncated 969 lines...]
 [junit4:junit4] Completed on J2 in 0.08s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestRollingBuffer
 [junit4:junit4] Completed on J1 in 0.05s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite:
 org.apache.lucene.util.junitcompat.TestSystemPropertiesInvariantRule
 [junit4:junit4] Completed on J2 in 0.09s, 5 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestWildcard
 [junit4:junit4] Completed on J1 in 0.22s, 8 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced2
 [junit4:junit4] Completed on J3 in 0.34s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestSizeBoundedForceMerge
 [junit4:junit4] Completed on J2 in 0.09s, 11 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestIdentityHashSet
 [junit4:junit4] Completed on J1 in 0.07s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestAutomatonQuery
 [junit4:junit4] Completed on J3 in 0.12s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite:
 org.apache.lucene.search.TestComplexExplanationsOfNonMatches
 [junit4:junit4] Completed on J2 in 0.12s, 22 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestCheckIndex
 [junit4:junit4] Completed on J1 in 0.08s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestDocCount
 [junit4:junit4] Completed on J3 in 0.12s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq
 [junit4:junit4] Completed on J2 in 0.09s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestUniqueTermCount
 [junit4:junit4] Completed on J1 in 0.09s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestPerSegmentDeletes
 [junit4:junit4] Completed on J3 in 0.03s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestBinaryTerms
 [junit4:junit4] Completed on J2 in 0.04s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestParallelReaderEmptyIndex
 [junit4:junit4] Completed on J1 in 0.02s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.document.TestDocument
 [junit4:junit4] Completed on J3 in 0.08s, 11 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestIndexWriterConfig
 [junit4:junit4] Completed on J2 in 0.02s, 9 tests
 [junit4:junit4]
 [junit4:junit4] Suite:
 org.apache.lucene.util.junitcompat.TestBeforeAfterOverrides
 [junit4:junit4] Completed on J1 in 0.02s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestSetOnce
 [junit4:junit4] Completed on J3 in 0.02s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestFilteredSearch
 [junit4:junit4] Completed on J2 in 0.02s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestDocValuesScoring
 [junit4:junit4] Completed on J1 in 0.10s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite:
 org.apache.lucene.util.junitcompat.TestSetupTeardownChaining
 [junit4:junit4] Completed on J3 in 0.01s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestCachingWrapperFilter
 [junit4:junit4] Completed on J2 in 0.03s, 5 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestTermScorer
 [junit4:junit4] Completed on J1 in 0.02s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.Test2BPostings
 [junit4:junit4] IGNOR/A 0.02s J3 | Test2BPostings.test
 [junit4:junit4] Assumption #1: 'nightly' test group is disabled
 (@Nightly)
 [junit4:junit4] Completed on J3 in 0.03s, 1 test, 1 skipped
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestFieldValueFilter
 [junit4:junit4] Completed on J2 in 0.08s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestDateFilter
 [junit4:junit4] Completed on J1 in 0.01s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestMultiTermQueryRewrites
 [junit4:junit4] Completed on J3 in 0.02s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestSegmentTermEnum
 [junit4:junit4] Completed on J2 in 0.07s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced
 [junit4:junit4] Completed on J1 in 0.03s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestBooleanScorer
 [junit4:junit4] Completed on J3 in 0.12s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite:
 org.apache.lucene.util.TestRecyclingByteBlockAllocator
 [junit4:junit4] Completed on J2 in 0.02s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite:

Build failed in Jenkins: the 4547 machine gun #36

See http://fortyounce.servebeer.com/job/the%204547%20machine%20gun/36/

--
[...truncated 962 lines...]
[junit4:junit4] Suite: 
org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper
[junit4:junit4] Completed on J2 in 0.10s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.automaton.TestSpecialOperations
[junit4:junit4] Completed on J0 in 0.08s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestDocCount
[junit4:junit4] Completed on J1 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestBooleanOr
[junit4:junit4] Completed on J3 in 0.55s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq
[junit4:junit4] Completed on J2 in 0.09s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.TestSearchForDuplicates
[junit4:junit4] Completed on J0 in 0.04s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestPerSegmentDeletes
[junit4:junit4] Completed on J1 in 0.03s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestSmallFloat
[junit4:junit4] Completed on J3 in 0.04s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestBinaryTerms
[junit4:junit4] Completed on J2 in 0.03s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestParallelReaderEmptyIndex
[junit4:junit4] Completed on J0 in 0.05s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestIndexWriterConfig
[junit4:junit4] Completed on J1 in 0.03s, 9 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestTopDocsCollector
[junit4:junit4] Completed on J3 in 0.10s, 8 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.util.junitcompat.TestBeforeAfterOverrides
[junit4:junit4] Completed on J2 in 0.02s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestFilteredSearch
[junit4:junit4] Completed on J0 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestDocIdSet
[junit4:junit4] Completed on J3 in 0.02s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.util.junitcompat.TestSetupTeardownChaining
[junit4:junit4] Completed on J1 in 0.02s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestTermScorer
[junit4:junit4] Completed on J2 in 0.07s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.util.junitcompat.TestSameRandomnessLocalePassedOrNot
[junit4:junit4] Completed on J0 in 0.05s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.Test2BPostings
[junit4:junit4] IGNOR/A 0.00s J3 | Test2BPostings.test
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] Completed on J3 in 0.01s, 1 test, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestFieldValueFilter
[junit4:junit4] Completed on J1 in 0.12s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.store.TestFileSwitchDirectory
[junit4:junit4] Completed on J2 in 0.03s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestBooleanScorer
[junit4:junit4] Completed on J0 in 0.05s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestConstantScoreQuery
[junit4:junit4] Completed on J3 in 0.02s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestPhrasePrefixQuery
[junit4:junit4] Completed on J1 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestRecyclingByteBlockAllocator
[junit4:junit4] Completed on J2 in 0.03s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestJUnitRuleOrder
[junit4:junit4] Completed on J0 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestCharsRef
[junit4:junit4] Completed on J3 in 0.03s, 8 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestCodecReported
[junit4:junit4] Completed on J1 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.TestSearch
[junit4:junit4] Completed on J2 in 0.23s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestParallelTermEnum
[junit4:junit4] Completed on J0 in 0.12s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestElevationComparator
[junit4:junit4] Completed on J3 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestExplanations
[junit4:junit4] Completed on J1 in 0.06s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestFieldCacheTermsFilter
[junit4:junit4] Completed on J2 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestMatchAllDocsQuery
[junit4:junit4] Completed on J0 in 0.07s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestNot
[junit4:junit4]

Jenkins build is back to normal : the 4547 machine gun #37

See http://fortyounce.servebeer.com/job/the%204547%20machine%20gun/37/


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

[jira] [Commented] (LUCENE-4690) Optimize NumericUtils.*ToPrefixCoded(), add versions that don't hash


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

Commit Tag Bot commented on LUCENE-4690:


[trunk commit] Yonik Seeley
http://svn.apache.org/viewvc?view=revisionrevision=1438242

LUCENE-4690: Performance improvements and non-hashing versions of 
NumericUtils.*ToPrefixCoded


 Optimize NumericUtils.*ToPrefixCoded(), add versions that don't hash
 

 Key: LUCENE-4690
 URL: https://issues.apache.org/jira/browse/LUCENE-4690
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
Priority: Minor
 Attachments: LUCENE-4690.patch


 As far as I can tell nothing actually uses the hash codes generated by these 
 methods (not even any tests).  If someone did want to generate a hash, it 
 would be just as fast to do it on the BytesRef after the fact (or even faster 
 from the input number itself).
 edit: Uwe pointed out they were used in one place.  Other places still don't 
 need 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] [Commented] (LUCENE-4690) Optimize NumericUtils.*ToPrefixCoded(), add versions that don't hash


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

Commit Tag Bot commented on LUCENE-4690:


[branch_4x commit] Yonik Seeley
http://svn.apache.org/viewvc?view=revisionrevision=1438253

LUCENE-4690: Performance improvements a non-hashing versions of 
NumericUtils.*ToPrefixCoded


 Optimize NumericUtils.*ToPrefixCoded(), add versions that don't hash
 

 Key: LUCENE-4690
 URL: https://issues.apache.org/jira/browse/LUCENE-4690
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
Priority: Minor
 Attachments: LUCENE-4690.patch


 As far as I can tell nothing actually uses the hash codes generated by these 
 methods (not even any tests).  If someone did want to generate a hash, it 
 would be just as fast to do it on the BytesRef after the fact (or even faster 
 from the input number itself).
 edit: Uwe pointed out they were used in one place.  Other places still don't 
 need 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] [Commented] (LUCENE-4690) Optimize NumericUtils.*ToPrefixCoded(), add versions that don't hash

2013-01-24 Thread Uwe Schindler (JIRA)


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

Uwe Schindler commented on LUCENE-4690:
---

Thanks, Yonik!

 Optimize NumericUtils.*ToPrefixCoded(), add versions that don't hash
 

 Key: LUCENE-4690
 URL: https://issues.apache.org/jira/browse/LUCENE-4690
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
Priority: Minor
 Attachments: LUCENE-4690.patch


 As far as I can tell nothing actually uses the hash codes generated by these 
 methods (not even any tests).  If someone did want to generate a hash, it 
 would be just as fast to do it on the BytesRef after the fact (or even faster 
 from the input number itself).
 edit: Uwe pointed out they were used in one place.  Other places still don't 
 need 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] [Resolved] (LUCENE-4690) Optimize NumericUtils.*ToPrefixCoded(), add versions that don't hash

2013-01-24 Thread Yonik Seeley (JIRA)


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

Yonik Seeley resolved LUCENE-4690.
--

   Resolution: Fixed
Fix Version/s: 5.0
   4.2

 Optimize NumericUtils.*ToPrefixCoded(), add versions that don't hash
 

 Key: LUCENE-4690
 URL: https://issues.apache.org/jira/browse/LUCENE-4690
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: LUCENE-4690.patch


 As far as I can tell nothing actually uses the hash codes generated by these 
 methods (not even any tests).  If someone did want to generate a hash, it 
 would be just as fast to do it on the BytesRef after the fact (or even faster 
 from the input number itself).
 edit: Uwe pointed out they were used in one place.  Other places still don't 
 need 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

Build failed in Jenkins: the 4547 machine gun #53

See http://fortyounce.servebeer.com/job/the%204547%20machine%20gun/53/

--
[...truncated 969 lines...]
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.search.spans.TestSpanExplanationsOfNonMatches
[junit4:junit4] Completed on J3 in 0.10s, 31 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper
[junit4:junit4] Completed on J1 in 0.10s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.search.TestComplexExplanationsOfNonMatches
[junit4:junit4] Completed on J2 in 0.07s, 22 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestDocCount
[junit4:junit4] Completed on J3 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq
[junit4:junit4] Completed on J1 in 0.10s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestBooleanOr
[junit4:junit4] Completed on J0 in 0.74s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.TestSearchForDuplicates
[junit4:junit4] Completed on J2 in 0.14s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestBinaryTerms
[junit4:junit4] Completed on J3 in 0.04s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestParallelReaderEmptyIndex
[junit4:junit4] Completed on J1 in 0.08s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestIndexFileDeleter
[junit4:junit4] Completed on J0 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestIndexWriterConfig
[junit4:junit4] Completed on J2 in 0.03s, 9 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.util.junitcompat.TestBeforeAfterOverrides
[junit4:junit4] Completed on J3 in 0.02s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestSetOnce
[junit4:junit4] Completed on J1 in 0.03s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestNoDeletionPolicy
[junit4:junit4] Completed on J0 in 0.20s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestDocValuesScoring
[junit4:junit4] Completed on J2 in 0.08s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestDocIdSet
[junit4:junit4] Completed on J3 in 0.07s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestTermScorer
[junit4:junit4] Completed on J1 in 0.07s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.Test2BPostings
[junit4:junit4] IGNOR/A 0.01s J0 | Test2BPostings.test
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] Completed on J0 in 0.02s, 1 test, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestFilterAtomicReader
[junit4:junit4] Completed on J2 in 0.03s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestFieldValueFilter
[junit4:junit4] Completed on J3 in 0.07s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.store.TestFileSwitchDirectory
[junit4:junit4] Completed on J1 in 0.03s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestMultiTermQueryRewrites
[junit4:junit4] Completed on J0 in 0.08s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced
[junit4:junit4] Completed on J2 in 0.09s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestBooleanScorer
[junit4:junit4] Completed on J3 in 0.08s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestConstantScoreQuery
[junit4:junit4] Completed on J1 in 0.08s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestPositionIncrement
[junit4:junit4] Completed on J0 in 0.02s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.store.TestDirectory
[junit4:junit4] IGNOR/A 0.00s J2 | TestDirectory.testThreadSafety
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] Completed on J2 in 0.02s, 8 tests, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestCodecReported
[junit4:junit4] Completed on J3 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.TestSearch
[junit4:junit4] Completed on J1 in 0.22s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestSameTokenSamePosition
[junit4:junit4] Completed on J0 in 0.01s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestFieldCacheTermsFilter
[junit4:junit4] Completed on J2 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestNot
[junit4:junit4] Completed on J3 in 0.06s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestSimilarity
[junit4:junit4] Completed on J1 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite:

Jenkins build is back to normal : the 4547 machine gun #54

See http://fortyounce.servebeer.com/job/the%204547%20machine%20gun/54/


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

[jira] [Created] (SOLR-4353) rename solr/example/contexts/solr.xml to reduce solr.xml confusion

2013-01-24 Thread Hoss Man (JIRA)

Hoss Man created SOLR-4353:
--

 Summary: rename solr/example/contexts/solr.xml to reduce 
solr.xml confusion
 Key: SOLR-4353
 URL: https://issues.apache.org/jira/browse/SOLR-4353
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.2, 5.0


I've occasionally seen people get confused about editing the example solr.xml 
file because in addition to the real solr.xml file for configuring solr, 
they also find the jetty context file which is named solr.xml

Unlike tomcat, where the context descriptor file name determines the webapp 
path, jetty doesn't care what the file name is -- it just globs up all the 
context files and looks at the contextPath properties on the WebAppContext 
objects in those files.


--
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-4353) rename solr/example/contexts/solr.xml to reduce solr.xml confusion

2013-01-24 Thread Hoss Man (JIRA)


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

Hoss Man commented on SOLR-4353:


Posting a patch for this seems kind of silly, the change i'm proposing is 
simply...

{noformat}
hossman@frisbee:~/lucene/dev$ svn mv solr/example/contexts/solr.xml 
solr/example/contexts/solr-jetty-context.xml
A solr/example/contexts/solr-jetty-context.xml
D solr/example/contexts/solr.xml
{noformat}

 rename solr/example/contexts/solr.xml to reduce solr.xml confusion
 

 Key: SOLR-4353
 URL: https://issues.apache.org/jira/browse/SOLR-4353
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.2, 5.0


 I've occasionally seen people get confused about editing the example 
 solr.xml file because in addition to the real solr.xml file for 
 configuring solr, they also find the jetty context file which is named 
 solr.xml
 Unlike tomcat, where the context descriptor file name determines the webapp 
 path, jetty doesn't care what the file name is -- it just globs up all the 
 context files and looks at the contextPath properties on the WebAppContext 
 objects in those files.

--
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-4353) rename solr/example/contexts/solr.xml to reduce solr.xml confusion


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

Mark Miller commented on SOLR-4353:
---

+1, seems fine.

 rename solr/example/contexts/solr.xml to reduce solr.xml confusion
 

 Key: SOLR-4353
 URL: https://issues.apache.org/jira/browse/SOLR-4353
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.2, 5.0


 I've occasionally seen people get confused about editing the example 
 solr.xml file because in addition to the real solr.xml file for 
 configuring solr, they also find the jetty context file which is named 
 solr.xml
 Unlike tomcat, where the context descriptor file name determines the webapp 
 path, jetty doesn't care what the file name is -- it just globs up all the 
 context files and looks at the contextPath properties on the WebAppContext 
 objects in those files.

--
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-4353) rename solr/example/contexts/solr.xml to reduce solr.xml confusion

2013-01-24 Thread Hoss Man (JIRA)


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

Hoss Man resolved SOLR-4353.


Resolution: Fixed

Committed revision 1438283.
Committed revision 1438284.


 rename solr/example/contexts/solr.xml to reduce solr.xml confusion
 

 Key: SOLR-4353
 URL: https://issues.apache.org/jira/browse/SOLR-4353
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.2, 5.0


 I've occasionally seen people get confused about editing the example 
 solr.xml file because in addition to the real solr.xml file for 
 configuring solr, they also find the jetty context file which is named 
 solr.xml
 Unlike tomcat, where the context descriptor file name determines the webapp 
 path, jetty doesn't care what the file name is -- it just globs up all the 
 context files and looks at the contextPath properties on the WebAppContext 
 objects in those files.

--
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-4353) rename solr/example/contexts/solr.xml to reduce solr.xml confusion


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

Commit Tag Bot commented on SOLR-4353:
--

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

SOLR-4353: Renamed example jetty context file to reduce confusion


 rename solr/example/contexts/solr.xml to reduce solr.xml confusion
 

 Key: SOLR-4353
 URL: https://issues.apache.org/jira/browse/SOLR-4353
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.2, 5.0


 I've occasionally seen people get confused about editing the example 
 solr.xml file because in addition to the real solr.xml file for 
 configuring solr, they also find the jetty context file which is named 
 solr.xml
 Unlike tomcat, where the context descriptor file name determines the webapp 
 path, jetty doesn't care what the file name is -- it just globs up all the 
 context files and looks at the contextPath properties on the WebAppContext 
 objects in those files.

--
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-4353) rename solr/example/contexts/solr.xml to reduce solr.xml confusion


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

Commit Tag Bot commented on SOLR-4353:
--

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

SOLR-4353: Renamed example jetty context file to reduce confusion (merge 
r1438283)


 rename solr/example/contexts/solr.xml to reduce solr.xml confusion
 

 Key: SOLR-4353
 URL: https://issues.apache.org/jira/browse/SOLR-4353
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.2, 5.0


 I've occasionally seen people get confused about editing the example 
 solr.xml file because in addition to the real solr.xml file for 
 configuring solr, they also find the jetty context file which is named 
 solr.xml
 Unlike tomcat, where the context descriptor file name determines the webapp 
 path, jetty doesn't care what the file name is -- it just globs up all the 
 context files and looks at the contextPath properties on the WebAppContext 
 objects in those files.

--
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: Fixing query-time multi-word synonym issue

2013-01-24 Thread Otis Gospodnetic

Funny, I expected everyone would jump on this thread considering so many
people hit this multi-word synonym issue...

Mikhail, I looked at the slides and while I understand that use case well,
I don't see where query-time multi-word synonyms come into play. Please
enlighten me :)  Thanks!

Otis
Solr  ElasticSearch Support
http://sematext.com/
On Jan 22, 2013 1:48 PM, Mikhail Khludnev mkhlud...@griddynamics.com
wrote:

 FWIW, multi-word synonyms is a side benefit of query parsing approach
 implemented by my team.
 Here how it looks like
 https://docs.google.com/a/griddynamics.com/presentation/pub?id=1oifLFI0MiA3ZyXZWisHJVRK13P8cki5yCABvABPObKwstart=falseloop=falsedelayms=3000#slide=id.g1006de00_2_34fee
  people frequent typo has been substituted to the correct brand.
 Five previous slides depicts the approach, the main idea is get rid of old
 good Boolean retrieval, and introduce own notion of matching.
 I can share more details if you wish.


 On Tue, Jan 22, 2013 at 7:17 PM, Otis Gospodnetic 
 otis.gospodne...@gmail.com wrote:

 Hello,

 I'm looking for some guidance around solving the infamous index-time vs.
 query-time multi-word synonym problem.  Looking for help with understanding
 the pieces and effort involved, and also being on a lookout for any
 potential man, it will take you forever, you'll have to do major Lucene
 surgery type of warnings.

 I never looked deeply into this problem and my understanding is that
 multi-word synonyms don't work at query-time because QueryParser(?) simply
 breaks queries on spaces and thus makes it impossible for
 SynonymTokenFilter (?) to see the non-broken-up token sequence and do
 synonym expansion.

 I think this is also documented on the Wiki.
 Are there other pieces involved that I didn't mention, but should have?

 The following are 3 different efforts I found:
 https://issues.apache.org/jira/browse/LUCENE-4499
 http://nolanlawson.com/2012/10/31/better-synonym-handling-in-solr/
 http://www.ub.uni-bielefeld.de/~befehl/base/solr/eurovoc.html

 Plus Jack's proposal:
 http://search-lucene.com/m/Zkj0k15dDGP1

 Does any of the above approaches sound like the right one, or at least in
 the right direction, and stands the chance of being accepted?

 Thanks,
 Otis




 --
 Sincerely yours
 Mikhail Khludnev
 Principal Engineer,
 Grid Dynamics

 http://www.griddynamics.com
  mkhlud...@griddynamics.com

Re: Fixing query-time multi-word synonym issue

2013-01-24 Thread Robert Muir

On Thu, Jan 24, 2013 at 8:10 PM, Otis Gospodnetic
otis.gospodne...@gmail.com wrote:
 Funny, I expected everyone would jump on this thread considering so many
 people hit this multi-word synonym issue...


Probably because its not a synonyms problem: its just a bug in a
specific queryparser.

If you dont use that queryparser, you dont care: if you want to fix
that one, well the only correct solution is obvious, fix the
queryparser not to split on whitespace. hacking other things around it
is no option at all :)

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

Re: Build failed in Jenkins: the 4547 machine gun #53

2013-01-24 Thread Robert Muir

In all cases the test failure is because we somehow write 100 wasted bytes:

  assertEquals(in1.getFilePointer(), in1.length());

I'm sure it will drive Adrien crazy :)

2013/1/24 Charlie Cron hudsonsevilt...@gmail.com:
 See http://fortyounce.servebeer.com/job/the%204547%20machine%20gun/53/

 --
 [...truncated 969 lines...]
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.spans.TestSpanExplanationsOfNonMatches
 [junit4:junit4] Completed on J3 in 0.10s, 31 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper
 [junit4:junit4] Completed on J1 in 0.10s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.TestComplexExplanationsOfNonMatches
 [junit4:junit4] Completed on J2 in 0.07s, 22 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestDocCount
 [junit4:junit4] Completed on J3 in 0.02s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq
 [junit4:junit4] Completed on J1 in 0.10s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestBooleanOr
 [junit4:junit4] Completed on J0 in 0.74s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.TestSearchForDuplicates
 [junit4:junit4] Completed on J2 in 0.14s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestBinaryTerms
 [junit4:junit4] Completed on J3 in 0.04s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestParallelReaderEmptyIndex
 [junit4:junit4] Completed on J1 in 0.08s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestIndexFileDeleter
 [junit4:junit4] Completed on J0 in 0.01s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestIndexWriterConfig
 [junit4:junit4] Completed on J2 in 0.03s, 9 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestBeforeAfterOverrides
 [junit4:junit4] Completed on J3 in 0.02s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestSetOnce
 [junit4:junit4] Completed on J1 in 0.03s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestNoDeletionPolicy
 [junit4:junit4] Completed on J0 in 0.20s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestDocValuesScoring
 [junit4:junit4] Completed on J2 in 0.08s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestDocIdSet
 [junit4:junit4] Completed on J3 in 0.07s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestTermScorer
 [junit4:junit4] Completed on J1 in 0.07s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.Test2BPostings
 [junit4:junit4] IGNOR/A 0.01s J0 | Test2BPostings.test
 [junit4:junit4] Assumption #1: 'nightly' test group is disabled 
 (@Nightly)
 [junit4:junit4] Completed on J0 in 0.02s, 1 test, 1 skipped
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestFilterAtomicReader
 [junit4:junit4] Completed on J2 in 0.03s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestFieldValueFilter
 [junit4:junit4] Completed on J3 in 0.07s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.store.TestFileSwitchDirectory
 [junit4:junit4] Completed on J1 in 0.03s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestMultiTermQueryRewrites
 [junit4:junit4] Completed on J0 in 0.08s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced
 [junit4:junit4] Completed on J2 in 0.09s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestBooleanScorer
 [junit4:junit4] Completed on J3 in 0.08s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestConstantScoreQuery
 [junit4:junit4] Completed on J1 in 0.08s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestPositionIncrement
 [junit4:junit4] Completed on J0 in 0.02s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.store.TestDirectory
 [junit4:junit4] IGNOR/A 0.00s J2 | TestDirectory.testThreadSafety
 [junit4:junit4] Assumption #1: 'nightly' test group is disabled 
 (@Nightly)
 [junit4:junit4] Completed on J2 in 0.02s, 8 tests, 1 skipped
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestCodecReported
 [junit4:junit4] Completed on J3 in 0.01s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.TestSearch
 [junit4:junit4] Completed on J1 in 0.22s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestSameTokenSamePosition
 [junit4:junit4] Completed on J0 in 0.01s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestFieldCacheTermsFilter
 [junit4:junit4] Completed on J2 in 0.01s, 1 test
 [junit4:junit4]
 [junit4:junit4]

Re: Build failed in Jenkins: the 4547 machine gun #53

2013-01-24 Thread Robert Muir

I think the bug is when its direct and the last block has the
optimized bitsPerValue=0 case.

On Thu, Jan 24, 2013 at 8:24 PM, Robert Muir rcm...@gmail.com wrote:
 In all cases the test failure is because we somehow write 100 wasted bytes:

   assertEquals(in1.getFilePointer(), in1.length());

 I'm sure it will drive Adrien crazy :)

 2013/1/24 Charlie Cron hudsonsevilt...@gmail.com:
 See http://fortyounce.servebeer.com/job/the%204547%20machine%20gun/53/

 --
 [...truncated 969 lines...]
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.spans.TestSpanExplanationsOfNonMatches
 [junit4:junit4] Completed on J3 in 0.10s, 31 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper
 [junit4:junit4] Completed on J1 in 0.10s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.TestComplexExplanationsOfNonMatches
 [junit4:junit4] Completed on J2 in 0.07s, 22 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestDocCount
 [junit4:junit4] Completed on J3 in 0.02s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq
 [junit4:junit4] Completed on J1 in 0.10s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestBooleanOr
 [junit4:junit4] Completed on J0 in 0.74s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.TestSearchForDuplicates
 [junit4:junit4] Completed on J2 in 0.14s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestBinaryTerms
 [junit4:junit4] Completed on J3 in 0.04s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestParallelReaderEmptyIndex
 [junit4:junit4] Completed on J1 in 0.08s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestIndexFileDeleter
 [junit4:junit4] Completed on J0 in 0.01s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestIndexWriterConfig
 [junit4:junit4] Completed on J2 in 0.03s, 9 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestBeforeAfterOverrides
 [junit4:junit4] Completed on J3 in 0.02s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestSetOnce
 [junit4:junit4] Completed on J1 in 0.03s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestNoDeletionPolicy
 [junit4:junit4] Completed on J0 in 0.20s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestDocValuesScoring
 [junit4:junit4] Completed on J2 in 0.08s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestDocIdSet
 [junit4:junit4] Completed on J3 in 0.07s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestTermScorer
 [junit4:junit4] Completed on J1 in 0.07s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.Test2BPostings
 [junit4:junit4] IGNOR/A 0.01s J0 | Test2BPostings.test
 [junit4:junit4] Assumption #1: 'nightly' test group is disabled 
 (@Nightly)
 [junit4:junit4] Completed on J0 in 0.02s, 1 test, 1 skipped
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestFilterAtomicReader
 [junit4:junit4] Completed on J2 in 0.03s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestFieldValueFilter
 [junit4:junit4] Completed on J3 in 0.07s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.store.TestFileSwitchDirectory
 [junit4:junit4] Completed on J1 in 0.03s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestMultiTermQueryRewrites
 [junit4:junit4] Completed on J0 in 0.08s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced
 [junit4:junit4] Completed on J2 in 0.09s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestBooleanScorer
 [junit4:junit4] Completed on J3 in 0.08s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestConstantScoreQuery
 [junit4:junit4] Completed on J1 in 0.08s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestPositionIncrement
 [junit4:junit4] Completed on J0 in 0.02s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.store.TestDirectory
 [junit4:junit4] IGNOR/A 0.00s J2 | TestDirectory.testThreadSafety
 [junit4:junit4] Assumption #1: 'nightly' test group is disabled 
 (@Nightly)
 [junit4:junit4] Completed on J2 in 0.02s, 8 tests, 1 skipped
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestCodecReported
 [junit4:junit4] Completed on J3 in 0.01s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.TestSearch
 [junit4:junit4] Completed on J1 in 0.22s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestSameTokenSamePosition
 [junit4:junit4] Completed on J0 in 0.01s, 2 tests

[jira] [Updated] (SOLR-4352) Velocity-base pagination should support/preserve sorting

2013-01-24 Thread Eric Spiegelberg (JIRA)


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

Eric Spiegelberg updated SOLR-4352:
---

Attachment: SOLR-4352.patch

A patch providing one way to resole this issue.

 Velocity-base pagination should support/preserve sorting
 

 Key: SOLR-4352
 URL: https://issues.apache.org/jira/browse/SOLR-4352
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Eric Spiegelberg
 Attachments: SOLR-4352.patch


 When performing /browse, the Velocity generated UI does not support sorting 
 in the generated pagination links.
 The link_to_previous_page and link_to_next_page macros found within 
 [apache-solr-4.0.0]/example/solr/collection1/conf/velocity/VM_global_library.vm
  should be modified to maintain/preserve an existing sort parameter.

--
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-3240) add spellcheck 'approximate collation count' mode

2013-01-24 Thread Nalini Kartha (JIRA)


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

Nalini Kartha commented on SOLR-3240:
-

Any timeline on when this would go in? It'd be useful for an extra option we're 
trying to add to the DirectSpellChecker - we want to issue queries for each 
suggestion to check that they would return some hits taking into account the fq 
params of the main query. Since we only care about the suggestion returning at 
least 1 hit, looks like this Collector would improve performance a lot.

 add spellcheck 'approximate collation count' mode
 -

 Key: SOLR-3240
 URL: https://issues.apache.org/jira/browse/SOLR-3240
 Project: Solr
  Issue Type: Improvement
  Components: spellchecker
Reporter: Robert Muir
 Attachments: SOLR-3240.patch, SOLR-3240.patch


 SpellCheck's Collation in Solr is a way to ensure spellcheck/suggestions
 will actually net results (taking into account context like filtering).
 In order to do this (from my understanding), it generates candidate queries,
 executes them, and saves the total hit count: collation.setHits(hits).
 For a large index it seems this might be doing too much work: in particular
 I'm interested in ensuring this feature can work fast enough/well for 
 autosuggesters.
 So I think we should offer an 'approximate' mode that uses an 
 early-terminating
 Collector, collect()ing only N docs (e.g. n=1), and we approximate this result
 count based on docid space. 
 I'm not sure what needs to happen on the solr side (possibly support for 
 custom collectors?),
 but I think this could help and should possibly be the default.

--
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: Fixing query-time multi-word synonym issue

2013-01-24 Thread Jack Krupansky

Otis, this is precisely why nothing will get done any time soon on the 
multi-term synonym issue - there isn't even common agreement that there is a 
problem, let alone common agreement on the specifics of the problem, let 
alone common agreement on a solution.


Even though technically the Solr Query Parser is now separate from the 
Lucene Query Parser, the synonym filter is still strictly Lucene. Addressing 
the multi-term synonym feature requires enhancement to the synonym filter, 
so without common agreement on the nature of the problem (which I already 
outlined), the only path forward is for Solr to provide its own synonym 
filter and leave the existing Lucene synonym filter intact.


That said, I don't expect general community agreement on a path forward for 
multi-term synonyms any time soon.


-- Jack Krupansky

-Original Message- 
From: Robert Muir

Sent: Thursday, January 24, 2013 8:17 PM
To: dev@lucene.apache.org
Subject: Re: Fixing query-time multi-word synonym issue

On Thu, Jan 24, 2013 at 8:10 PM, Otis Gospodnetic
otis.gospodne...@gmail.com wrote:

Funny, I expected everyone would jump on this thread considering so many
people hit this multi-word synonym issue...



Probably because its not a synonyms problem: its just a bug in a
specific queryparser.

If you dont use that queryparser, you dont care: if you want to fix
that one, well the only correct solution is obvious, fix the
queryparser not to split on whitespace. hacking other things around it
is no option at all :)

-
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

Build failed in Jenkins: the 4547 machine gun #130

See http://fortyounce.servebeer.com/job/the%204547%20machine%20gun/130/

--
[...truncated 960 lines...]
[junit4:junit4] Suite: org.apache.lucene.search.TestTermRangeQuery
[junit4:junit4] Completed on J0 in 0.14s, 7 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestRegexpRandom
[junit4:junit4] Completed on J1 in 0.08s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.search.TestSimpleExplanationsOfNonMatches
[junit4:junit4] Completed on J3 in 0.13s, 69 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestFuzzyQuery
[junit4:junit4] Completed on J2 in 0.17s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestRollingBuffer
[junit4:junit4] Completed on J0 in 0.06s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.util.junitcompat.TestSystemPropertiesInvariantRule
[junit4:junit4] Completed on J1 in 0.05s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestWildcard
[junit4:junit4] Completed on J3 in 0.11s, 8 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.search.spans.TestSpanExplanationsOfNonMatches
[junit4:junit4] Completed on J2 in 0.10s, 31 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestWildcardRandom
[junit4:junit4] Completed on J0 in 0.07s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.automaton.TestSpecialOperations
[junit4:junit4] Completed on J3 in 0.08s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestDocCount
[junit4:junit4] Completed on J2 in 0.04s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq
[junit4:junit4] Completed on J0 in 0.09s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.spans.TestNearSpansOrdered
[junit4:junit4] Completed on J1 in 0.43s, 10 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestUniqueTermCount
[junit4:junit4] Completed on J3 in 0.09s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestPerSegmentDeletes
[junit4:junit4] Completed on J2 in 0.08s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.document.TestDocument
[junit4:junit4] Completed on J0 in 0.09s, 11 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestSetOnce
[junit4:junit4] Completed on J1 in 0.04s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.util.junitcompat.TestSameRandomnessLocalePassedOrNot
[junit4:junit4] Completed on J2 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestSubScorerFreqs
[junit4:junit4] Completed on J0 in 0.02s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestFieldValueFilter
[junit4:junit4] Completed on J1 in 0.13s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestCachingWrapperFilter
[junit4:junit4] Completed on J3 in 0.29s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.store.TestFileSwitchDirectory
[junit4:junit4] Completed on J2 in 0.04s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestDateFilter
[junit4:junit4] Completed on J0 in 0.08s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestSeedFromUncaught
[junit4:junit4] Completed on J1 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced
[junit4:junit4] Completed on J3 in 0.03s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestBooleanScorer
[junit4:junit4] Completed on J2 in 0.02s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.store.TestDirectory
[junit4:junit4] IGNOR/A 0.00s J0 | TestDirectory.testThreadSafety
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] Completed on J0 in 0.02s, 8 tests, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestJUnitRuleOrder
[junit4:junit4] Completed on J1 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestCodecReported
[junit4:junit4] Completed on J3 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.TestSearch
[junit4:junit4] Completed on J2 in 0.12s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestReaderClosed
[junit4:junit4] Completed on J0 in 0.01s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestSameTokenSamePosition
[junit4:junit4] Completed on J1 in 0.07s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestExplanations
[junit4:junit4] Completed on J3 in 0.11s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestFieldCacheTermsFilter
[junit4:junit4] Completed on J2 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite:

Jenkins build is back to normal : the 4547 machine gun #131

See http://fortyounce.servebeer.com/job/the%204547%20machine%20gun/131/


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

Re: Fixing query-time multi-word synonym issue

2013-01-24 Thread Varun Thacker

There is one more issue which faces a similar problem, the queryparser
splits on whitespace and when the field being searched against is
multi-word then search doesn't behave correctly.

But ideally these problems should not arise, I want to be a little more
optimistic on this and see if there is a  solution to these problems :)

On Fri, Jan 25, 2013 at 11:18 AM, Jack Krupansky j...@basetechnology.comwrote:

 Otis, this is precisely why nothing will get done any time soon on the
 multi-term synonym issue - there isn't even common agreement that there is
 a problem, let alone common agreement on the specifics of the problem, let
 alone common agreement on a solution.

 Even though technically the Solr Query Parser is now separate from the
 Lucene Query Parser, the synonym filter is still strictly Lucene.
 Addressing the multi-term synonym feature requires enhancement to the
 synonym filter, so without common agreement on the nature of the problem
 (which I already outlined), the only path forward is for Solr to provide
 its own synonym filter and leave the existing Lucene synonym filter
 intact.

 That said, I don't expect general community agreement on a path forward
 for multi-term synonyms any time soon.

 -- Jack Krupansky

 -Original Message- From: Robert Muir
 Sent: Thursday, January 24, 2013 8:17 PM
 To: dev@lucene.apache.org
 Subject: Re: Fixing query-time multi-word synonym issue


 On Thu, Jan 24, 2013 at 8:10 PM, Otis Gospodnetic
 otis.gospodne...@gmail.com wrote:

 Funny, I expected everyone would jump on this thread considering so many
 people hit this multi-word synonym issue...


 Probably because its not a synonyms problem: its just a bug in a
 specific queryparser.

 If you dont use that queryparser, you dont care: if you want to fix
 that one, well the only correct solution is obvious, fix the
 queryparser not to split on whitespace. hacking other things around it
 is no option at all :)

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

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




-- 


Regards,
Varun Thacker
http://www.vthacker.in/

[jira] [Created] (SOLR-4354) Replication should perform full copy if slave's generation higher than master's

2013-01-24 Thread Amit Nithian (JIRA)

Amit Nithian created SOLR-4354:
--

 Summary: Replication should perform full copy if slave's 
generation higher than master's
 Key: SOLR-4354
 URL: https://issues.apache.org/jira/browse/SOLR-4354
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 4.1
Reporter: Amit Nithian
 Fix For: 4.2
 Attachments: SOLR-4354.patch

We have dual masters each incrementally indexing from our MySQL database and 
sit behind a virtual hostname in our load balancer. As such, it's possible that 
the generation numbers between the masters for a given index are not in sync. 
Slaves are configured to replicate from this virtual host (and pin based on 
source/dest IP hash) so we can add and remove masters as necessary (great for 
maintenance). 

For the most part this works but we've seen the following happen:
* Slave has been pulling from master A
* Master A goes down for maint and now will pull from master B (which has a 
lower generation number for some reason than master A).
* Slave now tries to pull from master B (has higher index version than slave 
but lower generation).
* Slave downloads index files, moves them to the index/ directory but these 
files are deleted during the doCommit() phase (looks like older generation data 
is deleted).
* Index remains as-is and no change.

--
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-4354) Replication should perform full copy if slave's generation higher than master's

2013-01-24 Thread Amit Nithian (JIRA)


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

Amit Nithian updated SOLR-4354:
---

Attachment: SOLR-4354.patch

My fix will force a full copy if the slave's generation is greater than the 
master's generation.

 Replication should perform full copy if slave's generation higher than 
 master's
 ---

 Key: SOLR-4354
 URL: https://issues.apache.org/jira/browse/SOLR-4354
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 4.1
Reporter: Amit Nithian
 Fix For: 4.2

 Attachments: SOLR-4354.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 We have dual masters each incrementally indexing from our MySQL database and 
 sit behind a virtual hostname in our load balancer. As such, it's possible 
 that the generation numbers between the masters for a given index are not in 
 sync. Slaves are configured to replicate from this virtual host (and pin 
 based on source/dest IP hash) so we can add and remove masters as necessary 
 (great for maintenance). 
 For the most part this works but we've seen the following happen:
 * Slave has been pulling from master A
 * Master A goes down for maint and now will pull from master B (which has a 
 lower generation number for some reason than master A).
 * Slave now tries to pull from master B (has higher index version than slave 
 but lower generation).
 * Slave downloads index files, moves them to the index/ directory but these 
 files are deleted during the doCommit() phase (looks like older generation 
 data is deleted).
 * Index remains as-is and no change.

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

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

[jira] [Assigned] (SOLR-4352) Velocity-base pagination should support/preserve sorting

2013-01-24 Thread Erik Hatcher (JIRA)


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

Erik Hatcher reassigned SOLR-4352:
--

Assignee: Erik Hatcher

 Velocity-base pagination should support/preserve sorting
 

 Key: SOLR-4352
 URL: https://issues.apache.org/jira/browse/SOLR-4352
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Eric Spiegelberg
Assignee: Erik Hatcher
 Attachments: SOLR-4352.patch


 When performing /browse, the Velocity generated UI does not support sorting 
 in the generated pagination links.
 The link_to_previous_page and link_to_next_page macros found within 
 [apache-solr-4.0.0]/example/solr/collection1/conf/velocity/VM_global_library.vm
  should be modified to maintain/preserve an existing sort parameter.

--
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] [Closed] (SOLR-4346) Solr Admin UI: Cloud graphs are not shown correctly in Google Chrome