date:20150709

Richard Bowen created LUCENE-6669:
-

 Summary: PATCH: the the
 Key: LUCENE-6669
 URL: https://issues.apache.org/jira/browse/LUCENE-6669
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Richard Bowen
Priority: Trivial


s/the the/the/g




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6669) PATCH: the the


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

Richard Bowen updated LUCENE-6669:
--
Attachment: the_the.patch

Patch attached.

 PATCH: the the
 --

 Key: LUCENE-6669
 URL: https://issues.apache.org/jira/browse/LUCENE-6669
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Richard Bowen
Priority: Trivial
 Attachments: the_the.patch


 s/the the/the/g



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6234) Scoring modes for query time join


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

Timothy Potter updated SOLR-6234:
-
Attachment: SOLR-6234.patch

Here's an updated patch for trunk. The JavaDoc on the ScoreJoinQParserPlugin 
wasn't passing precommit, so I need to fix that before committing (removed it 
for now).

This does not have the code from the patch Ryan posted yet ...

[~mkhludnev] You mentioned this solution would address SOLR-6357, but I'm still 
seeing the same error when using scorejoin. Can you elaborate on why you think 
this fixes that problem?

{code}
[~/dev/lw/projects/solr_trunk_co/solr]$ curl 
http://localhost:8983/solr/techproducts/update?commit=true; -d 
'deletequery{!scorejoin from=manu_id_s to=id}ipod/query/delete'
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status500/intint 
name=QTime6/int/lstlst name=errorstr 
name=msgorg.apache.lucene.search.IndexSearcher cannot be cast to 
org.apache.solr.search.SolrIndexSearcher/strstr 
name=tracejava.lang.ClassCastException: 
org.apache.lucene.search.IndexSearcher cannot be cast to 
org.apache.solr.search.SolrIndexSearcher
at 
org.apache.solr.search.JoinQuery.createWeight(JoinQParserPlugin.java:207)
at 
org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:704)
at 
org.apache.lucene.search.BooleanWeight.lt;initgt;(BooleanWeight.java:56)
at 
org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:197)
at 
org.apache.solr.update.DeleteByQueryWrapper.createWeight(DeleteByQueryWrapper.java:72)
at 
org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:704)
at 
org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:687)
at 
org.apache.lucene.search.QueryWrapperFilter.getDocIdSet(QueryWrapperFilter.java:63)
at 
org.apache.lucene.index.BufferedUpdatesStream.applyQueryDeletes(BufferedUpdatesStream.java:690)
at 
org.apache.lucene.index.BufferedUpdatesStream.applyDeletesAndUpdates(BufferedUpdatesStream.java:261)
at 
org.apache.lucene.index.IndexWriter.applyAllDeletesAndUpdates(IndexWriter.java:3148)
at 
org.apache.lucene.index.IndexWriter.maybeApplyDeletes(IndexWriter.java:3134)
at 
org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2808)
at 
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2962)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2929)
{code}

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Timothy Potter
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, 
 otherHandler.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[CI] Lucene 5x Linux 64 Test Only - Build # 55047 - Failure!

2015-07-09 Thread build




  
  BUILD FAILURE
  
  Build URLhttp://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/55047/
  Project:lucene_linux_java8_64_test_only

  Randomization:

JDK8,local,heap[1024m],-server +UseParallelGC -UseCompressedOops +AggressiveOpts


  Date of build:Thu, 09 Jul 2015 13:45:00 +0200
  Build duration:2 hr 5 min





	
CHANGES
	
No Changes

  





  
BUILD ARTIFACTS

  
		
  	  
  	checkout/lucene/build/analysis/kuromoji/test/temp/junit4-J0-20150709_134950_066.events
  	  
		
  	  
  	checkout/lucene/build/analysis/kuromoji/test/temp/junit4-J1-20150709_134950_066.events
  	  
		
  	  
  	checkout/lucene/build/analysis/kuromoji/test/temp/junit4-J2-20150709_134950_068.events
  	  
		
  	  
  	checkout/lucene/build/analysis/kuromoji/test/temp/junit4-J3-20150709_134950_069.events
  	  
		
  	  
  	checkout/lucene/build/analysis/kuromoji/test/temp/junit4-J4-20150709_134950_069.events
  	  
		
  	  
  	checkout/lucene/build/analysis/kuromoji/test/temp/junit4-J5-20150709_134950_069.events
  	  
		
  	  
  	checkout/lucene/build/analysis/kuromoji/test/temp/junit4-J6-20150709_134950_069.events
  	  
		
  	  
  	checkout/lucene/build/analysis/kuromoji/test/temp/junit4-J7-20150709_134950_069.events
  	  

  

  
  








  
FAILED JUNIT TESTS

Name: junit.framework Failed: 1 test(s), Passed: 0 test(s), Skipped: 0 test(s), Total: 1 test(s)
   
 Failed: junit.framework.TestSuite.org.apache.lucene.analysis.ja.TestJapaneseAnalyzer 
   
Name: org.apache.lucene.analysis.ja Failed: 1 test(s), Passed: 94 test(s), Skipped: 1 test(s), Total: 96 test(s)
   
 Failed: org.apache.lucene.analysis.ja.TestJapaneseAnalyzer.test5thCuriousString 
   
  





CONSOLE OUTPUT

	[...truncated 4309 lines...]

	   [junit4] JVM J0: 0.86 .. 8.18 = 7.32s

	   [junit4] JVM J1: 0.86 .. 6.46 = 5.60s

	   [junit4] JVM J2: 0.86 ..  7221.94 =  7221.08s

	   [junit4] JVM J3: 0.86 .. 5.48 = 4.62s

	   [junit4] JVM J4: 0.85 .. 5.20 = 4.35s

	   [junit4] JVM J5: 0.86 .. 4.74 = 3.89s

	   [junit4] JVM J6: 0.86 .. 5.03 = 4.16s

	   [junit4] JVM J7: 0.86 .. 5.25 = 4.39s

	   [junit4] Execution time total: 2 hours 21 seconds

	   [junit4] Tests summary: 17 suites, 104 tests, 1 suite-level error, 1 error, 1 ignored (1 assumption)

	

	BUILD FAILED

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:467: The following error occurred while executing this line:

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:2240: The following error occurred while executing this line:

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/analysis/build.xml:106: The following error occurred while executing this line:

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/analysis/build.xml:38: The following error occurred while executing this line:

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/module-build.xml:58: The following error occurred while executing this line:

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444: The following error occurred while executing this line:

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999: There were test failures: 17 suites, 104 tests, 1 suite-level error, 1 error, 1 ignored (1 assumption)

	

	Total time: 124 minutes 59 seconds

	Build step 'Invoke Ant' marked build as failure

	Archiving artifacts

	Recording test results

	[description-setter] Description set: JDK8,local,heap[1024m],-server +UseParallelGC -UseCompressedOops +AggressiveOpts

	Email was triggered for: Failure - 1st

	Trigger Failure - Any was overridden by another trigger and will not send an email.

	Trigger Failure - Still was overridden by another trigger and will not send an email.

	Sending email for trigger: Failure - 1st








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

[jira] [Commented] (LUCENE-6669) PATCH: the the

2015-07-09 Thread Mike Drob (JIRA)


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

Mike Drob commented on LUCENE-6669:
---

That is significantly more instances of 'the the' than I would have expected!

 PATCH: the the
 --

 Key: LUCENE-6669
 URL: https://issues.apache.org/jira/browse/LUCENE-6669
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Richard Bowen
Priority: Trivial
 Attachments: the_the.patch


 s/the the/the/g



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6668) Optimize SortedSet/SortedNumeric storage for the few unique sets use-case


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

Adrien Grand updated LUCENE-6668:
-
Attachment: LUCENE-6668.patch

Updated patch so that BaseDocValuesFormatTestCase explicitely tests both when 
there are few and many unique sets of values.

 Optimize SortedSet/SortedNumeric storage for the few unique sets use-case
 -

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


 Robert suggested this idea: if there are few unique sets of values, we could 
 build a lookup table and then map each doc to an ord in this table, just like 
 we already do for table compression for numerics.
 I think this is especially compelling given that SortedSet/SortedNumeric are 
 our two only doc values types that use O(maxDoc) memory because of the 
 offsets map. When this new strategy is used, memory usage could be bounded to 
 a constant.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-5756) A utility API to move collections from internal to external

2015-07-09 Thread Noble Paul (JIRA)


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

Noble Paul commented on SOLR-5756:
--

The steps to migrate state from main clusterstate.

# Add support to ZKStateReader to lookup the 
{{/collections/collection-namestate.json}} if a collection is suddenly 
missing from the main {{clusterstate.json}} . If the {{state.json}} is found 
add a listener to that if that requires to be watched
# Add a collection-admin command to migrate the state outside

A user should first upgrade all servers to a new version and then execute the 
command

 A utility API to move collections from internal to external
 ---

 Key: SOLR-5756
 URL: https://issues.apache.org/jira/browse/SOLR-5756
 Project: Solr
  Issue Type: Bug
Reporter: Noble Paul
Assignee: Noble Paul

 SOLR-5473 allows creation of collection with state stored outside of 
 clusterstate.json. We would need an API to  move existing 'internal' 
 collections outside



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6234) Scoring modes for query time join


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

Timothy Potter commented on SOLR-6234:
--

Actually ... hold that thought ... looks like code is still hitting 
JoinQParserPlugin.java for some reason ??? I'll dig.

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Timothy Potter
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, 
 otherHandler.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-7769) bin/post: add -p alias for -port to align with bin/solr's -p

2015-07-09 Thread Erik Hatcher (JIRA)

Erik Hatcher created SOLR-7769:
--

 Summary: bin/post: add -p alias for -port to align with bin/solr's 
-p
 Key: SOLR-7769
 URL: https://issues.apache.org/jira/browse/SOLR-7769
 Project: Solr
  Issue Type: Improvement
  Components: scripts and tools
Affects Versions: 5.0
Reporter: Erik Hatcher
Assignee: Erik Hatcher
Priority: Minor
 Fix For: 5.3


Let's allow {code}bin/post -p  -c collection_name docs/{code}

Currently one must use -port.  bin/solr start uses -p



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7764) Solr indexing hangs if encounters an certain XML parse error


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

Erick Erickson commented on SOLR-7764:
--

Yet another option: Parse the Tika files outside of DIH with SolrJ. It's 
actually not hard at all, here's a sample that has some DB manipulations mixed 
in but those bits could easily be removed.

https://lucidworks.com/blog/indexing-with-solrj/


 Solr indexing hangs if encounters an certain XML parse error
 

 Key: SOLR-7764
 URL: https://issues.apache.org/jira/browse/SOLR-7764
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.7.2
 Environment: Ubuntu 12.04.5 LTS
Reporter: Sorin Gheorghiu
  Labels: indexing
 Attachments: Solr_XML_parse_error_080715.txt


 BlueSpice (http://bluespice.com/) uses Solr to index documents for the 
 'Extended search' feature.
 Solr hangs if during indexing certain error occurs:
 8.7.2015 15:34:26
 ERROR
 SolrCore
 org.apache.solr.common.SolrException: 
 org.apache.tika.exception.TikaException: XML parse error
 8.7.2015 15:34:26
 ERROR
 SolrDispatchFilter
 null:org.apache.solr.common.SolrException: 
 org.apache.tika.exception.TikaException: XML parse error



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6669) PATCH: the the

2015-07-09 Thread Robert Muir (JIRA)


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

Robert Muir commented on LUCENE-6669:
-

Some of the files in the patch should not be changed, like the test documents, 
and third party javascript stuff.

 PATCH: the the
 --

 Key: LUCENE-6669
 URL: https://issues.apache.org/jira/browse/LUCENE-6669
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Richard Bowen
Priority: Trivial
 Attachments: the_the.patch, the_the.patch


 s/the the/the/g



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7764) Solr indexing hangs if encounters an certain XML parse error

2015-07-09 Thread Sorin Gheorghiu (JIRA)


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

Sorin Gheorghiu commented on SOLR-7764:
---

Thank you Tim for your effort. As I said this morning, I don't think this issue 
is related to Tika, because the Tika error occurs as well when these files are 
removed and then Solr won't hung. The issue is still reproduceable and I 
noticed a bunch of solr errors like:

Jul 9, 2015 12:49:00 PM org.apache.catalina.loader.WebappClassLoader 
checkThreadLocalMapForLeaks
SEVERE: The web application [/solr] created a ThreadLocal with key of type 
[org.apache.xmlbeans.impl.store.Locale$1] (value [or
  
g.apache.xmlbeans.impl.store.Locale$1@39515054]) and a value of type 
[java.lang.ref.SoftReference] (value [java.lang.ref.SoftRe  
ference@cb2f97d]) but 
failed to remove it when the web application was stopped. Threads are going to 
be renewed over time to tr  
y and avoid a probable memory leak.
Jul 9, 2015 12:49:00 PM org.apache.catalina.loader.WebappClassLoader 
checkThreadLocalMapForLeaks
SEVERE: The web application [/solr] created a ThreadLocal with key of type 
[org.apache.solr.schema.DateField.ThreadLocalDateFor
  mat] (value 
[org.apache.solr.schema.DateField$ThreadLocalDateFormat@4f81bf75]) and a value 
of type [org.apache.solr.schema.Date
  Field.ISO8601CanonicalDateFormat] (value 
[org.apache.solr.schema.DateField$ISO8601CanonicalDateFormat@6b2ed43a]) but 
failed to   
remove it when the web application was stopped. Threads are going to be 
renewed over time to try and avoid a probable memory le 
 ak.
Jul 9, 2015 12:49:00 PM org.apache.catalina.loader.WebappClassLoader 
checkThreadLocalMapForLeaks
SEVERE: The web application [/solr] created a ThreadLocal with key of type 
[org.apache.xmlbeans.impl.store.CharUtil$1] (value [
  
org.apache.xmlbeans.impl.store.CharUtil$1@4f40c31a]) and a value of type 
[java.lang.ref.SoftReference] (value [java.lang.ref.So  
ftReference@3a19840e]) but 
failed to remove it when the web application was stopped. Threads are going to 
be renewed over time
   to try and avoid a probable memory leak.

I can attach the whole log file by request.


 Solr indexing hangs if encounters an certain XML parse error
 

 Key: SOLR-7764
 URL: https://issues.apache.org/jira/browse/SOLR-7764
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.7.2
 Environment: Ubuntu 12.04.5 LTS
Reporter: Sorin Gheorghiu
  Labels: indexing
 Attachments: Solr_XML_parse_error_080715.txt


 BlueSpice (http://bluespice.com/) uses Solr to index documents for the 
 'Extended search' feature.
 Solr hangs if during indexing certain error occurs:
 8.7.2015 15:34:26
 ERROR
 SolrCore
 org.apache.solr.common.SolrException: 
 org.apache.tika.exception.TikaException: XML parse error
 8.7.2015 15:34:26
 ERROR
 SolrDispatchFilter
 null:org.apache.solr.common.SolrException: 
 org.apache.tika.exception.TikaException: XML parse error



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Is solrconfig.xml a potentially misleading filename?

2015-07-09 Thread Erick Erickson

coreconfig.xml has it's own problems in SolrCloud,
collectionconfig seems better. Except in that case
stand-alone Solr doesn't really use collections...

Siiggghhh.

On Wed, Jul 8, 2015 at 11:47 PM, Shawn Heisey apa...@elyograg.org wrote:
 I had a thought, wondering if the idea is completely insane.

 The config file named solrconfig.xml suggests that it is a config file
 for all of Solr, rather than configuring an individual index (core).

 The radical idea that came out of this realization is to transition to
 something like coreconfig.xml or core.xml instead.  All 5.x versions
 would need to continue working with solrconfig.xml, if config is not
 present in core.properties.

 The name solrconfig.xml would be more appropriate for what is currently
 found in solr.xml, but trying to do that rename would be enormously
 confusing and painful for upgrading users, so I am not suggesting it.

 Thoughts?

 Thanks,
 Shawn


 -
 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] [Updated] (LUCENE-6669) PATCH: the the


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

Richard Bowen updated LUCENE-6669:
--
Attachment: the_the.patch

While we're at it, here's an updated patch with 'a a' as well. :-)

 PATCH: the the
 --

 Key: LUCENE-6669
 URL: https://issues.apache.org/jira/browse/LUCENE-6669
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Richard Bowen
Priority: Trivial
 Attachments: the_the.patch, the_the.patch


 s/the the/the/g



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-7768) Admin GUI to upload configuration files to Zookeeper


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

Erick Erickson resolved SOLR-7768.
--
Resolution: Duplicate

Duplicate of SOLR-4052

 Admin GUI to upload configuration files to Zookeeper
 

 Key: SOLR-7768
 URL: https://issues.apache.org/jira/browse/SOLR-7768
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud, web gui
Reporter: Aniket Khare

 can we have functionality where user can easily upload the configuration 
 files to zookeeper.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Is solrconfig.xml a potentially misleading filename?

2015-07-09 Thread Shawn Heisey

On 7/9/2015 10:55 AM, Erick Erickson wrote:
 coreconfig.xml has it's own problems in SolrCloud,
 collectionconfig seems better. Except in that case
 stand-alone Solr doesn't really use collections...

 Siiggghhh.

I debated with myself on whether I even wanted to bring this up. 
Ultimately I decided it would be interesting to discuss, even if we
don't take any action.

As potential replacements for solrconfig.xml, I find that core.xml or
possibly just config.xml are the most appealing ... but the former might
be confusing in a SolrCloud context.  I'm biased towards cores, because
the Solr indexes that I interact with most often are NOT using
SolrCloud, and might never use it.  I've heard rumblings about SolrCloud
becoming the *only* running mode, but that hasn't happened so far.

I understand how we got where we are today -- in the early days, Solr
only handled one index, so the solrconfig.xml actually did configure all
of Solr.

Thanks,
Shawn


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

[jira] [Commented] (LUCENE-6669) PATCH: the the


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

Adrien Grand commented on LUCENE-6669:
--

I think you uploaded the wrong file?

 PATCH: the the
 --

 Key: LUCENE-6669
 URL: https://issues.apache.org/jira/browse/LUCENE-6669
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Richard Bowen
Priority: Trivial
 Attachments: the_the.patch, the_the.patch, the_the.patch


 s/the the/the/g



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7770) Date field problems using ExtractingRequestHandler and java 9 (b71)


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

Hoss Man commented on SOLR-7770:


Uwe Also added some specific DateUtil tests of this w/o depending on tika to 
produce the date values...

http://svn.apache.org/r1690031
http://svn.apache.org/r1690032

 Date field problems using ExtractingRequestHandler and java 9 (b71)
 ---

 Key: SOLR-7770
 URL: https://issues.apache.org/jira/browse/SOLR-7770
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man

 Tracking bug to note that the (Tika based) ExtractingRequestHandler will not 
 work properly with jdk9 starting with build71.
 This first manifested itself with failures like this from the tests...
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=ExtractingRequestHandlerTest
 -Dtests.method=testArabicPDF -Dtests.seed=232D0A5404C2ADED 
 -Dtests.multiplier=3 -Dtests.slow=true
 -Dtests.locale=en_JM -Dtests.timezone=Etc/GMT-7 -Dtests.asserts=true 
 -Dtests.file.encoding=UTF-8
[junit4] ERROR   0.58s | ExtractingRequestHandlerTest.testArabicPDF 
[junit4] Throwable #1: org.apache.solr.common.SolrException: Invalid 
 Date String:'Tue Mar 09 13:44:49
 GMT+07:00 2010'
 {noformat}
 Workarround noted by Uwe...
 {quote}
 The test passes on JDK 9 b71 with:
 -Dargs=-Djava.locale.providers=JRE,SPI
 This reenabled the old Locale data. I will add this to the build parameters 
 of policeman Jenkins to stop this from
 failing. To me it looks like the locale data somehow is not able to correctly 
 parse weekdays and/or timezones. I
 will check this out tomorrow and report a bug to the OpenJDK people. There is 
 something fishy with CLDR locale data.
 There are already some bugs open, so work is not yet finished (e.g. sometimes 
 it uses wrong timezone shortcuts,...)
 {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6579) Unexpected merge exceptions should be tragic to IndexWriter

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

Michael McCandless updated LUCENE-6579:
---
Attachment: LUCENE-6579.patch

Here's a tentative patch ... it was tricky because calling IW.tragicEvent from
a merge thread quickly lead to deadlock. I had to relax a few locking/blocking
places to work around that ...

I also had to fix some tests to expected that IW is closed after hitting a
merge exc, but I'm sure there's a long tail still there ... this will be
destabilizing at first.

I still need to add a dedicated test that confirms IW is closed after a merge
exc.

Unexpected merge exceptions should be tragic to IndexWriter
---

Key: LUCENE-6579
URL: https://issues.apache.org/jira/browse/LUCENE-6579
Project: Lucene - Core
Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 5.3, Trunk

Attachments: LUCENE-6579.patch

Today our behavior is weird: we will fail the merge (which is running in a
background thread if you are using the default CMS), pause for 1.0 seconds,
and then the next chance we get, kick off the merge again.
I think this is a poor default, e.g. on disk full we will just keep trying
and filling up disk again, wasting IO/CPU.
I think IW should declare this a tragedy instead?

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6669) PATCH: the the


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

Richard Bowen updated LUCENE-6669:
--
Attachment: the_the.patch

Fifth time is the charm ...

 PATCH: the the
 --

 Key: LUCENE-6669
 URL: https://issues.apache.org/jira/browse/LUCENE-6669
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Richard Bowen
Priority: Trivial
 Attachments: the_the.patch, the_the.patch, the_the.patch


 s/the the/the/g



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-7770) Date field problems using ExtractingRequestHandler and java 9 (b71)

Hoss Man created SOLR-7770:
--

 Summary: Date field problems using ExtractingRequestHandler and 
java 9 (b71)
 Key: SOLR-7770
 URL: https://issues.apache.org/jira/browse/SOLR-7770
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man


Tracking bug to note that the (Tika based) ExtractingRequestHandler will not 
work properly with jdk9 starting with build71.

This first manifested itself with failures like this from the tests...

{noformat}
   [junit4]   2 NOTE: reproduce with: ant test  
-Dtestcase=ExtractingRequestHandlerTest
-Dtests.method=testArabicPDF -Dtests.seed=232D0A5404C2ADED -Dtests.multiplier=3 
-Dtests.slow=true
-Dtests.locale=en_JM -Dtests.timezone=Etc/GMT-7 -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.58s | ExtractingRequestHandlerTest.testArabicPDF 
   [junit4] Throwable #1: org.apache.solr.common.SolrException: Invalid 
Date String:'Tue Mar 09 13:44:49
GMT+07:00 2010'
{noformat}

Workarround noted by Uwe...

{quote}
The test passes on JDK 9 b71 with:
-Dargs=-Djava.locale.providers=JRE,SPI

This reenabled the old Locale data. I will add this to the build parameters of 
policeman Jenkins to stop this from
failing. To me it looks like the locale data somehow is not able to correctly 
parse weekdays and/or timezones. I
will check this out tomorrow and report a bug to the OpenJDK people. There is 
something fishy with CLDR locale data.
There are already some bugs open, so work is not yet finished (e.g. sometimes 
it uses wrong timezone shortcuts,...)
{quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7770) Date field problems using ExtractingRequestHandler and java 9 (b71)


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

Hoss Man commented on SOLR-7770:


Full details of an example failure...

http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13200/
Java: 64bit/jdk1.9.0-ea-b71 -XX:-UseCompressedOops -XX:+UseG1GC
r1689849

{noformat}
   [junit4]   2 log4j:WARN See 
http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
   [junit4]   2 NOTE: reproduce with: ant test  
-Dtestcase=ExtractingRequestHandlerTest
-Dtests.method=testArabicPDF -Dtests.seed=232D0A5404C2ADED -Dtests.multiplier=3 
-Dtests.slow=true
-Dtests.locale=en_JM -Dtests.timezone=Etc/GMT-7 -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.58s | ExtractingRequestHandlerTest.testArabicPDF 
   [junit4] Throwable #1: org.apache.solr.common.SolrException: Invalid 
Date String:'Tue Mar 09 13:44:49
GMT+07:00 2010'
   [junit4]at 
__randomizedtesting.SeedInfo.seed([232D0A5404C2ADED:4DEB715B070706B8]:0)
   [junit4]at 
org.apache.solr.schema.TrieDateField.parseMath(TrieDateField.java:150)
   [junit4]at 
org.apache.solr.schema.TrieField.createField(TrieField.java:657)
   [junit4]at 
org.apache.solr.schema.TrieField.createFields(TrieField.java:694)
   [junit4]at 
org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:48)
   [junit4]at 
org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:123)
   [junit4]at 
org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:83)
   [junit4]at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:237)
   [junit4]at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:163)
   [junit4]at
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
   [junit4]at
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
   [junit4]at
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:981)
   [junit4]at
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:706)
   [junit4]at
org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:104)
   [junit4]at
org.apache.solr.handler.extraction.ExtractingDocumentLoader.doAdd(ExtractingDocumentLoader.java:122)
   [junit4]at
org.apache.solr.handler.extraction.ExtractingDocumentLoader.addDoc(ExtractingDocumentLoader.java:127)
   [junit4]at
org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:230)
   [junit4]at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
   [junit4]at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
   [junit4]at 
org.apache.solr.core.SolrCore.execute(SolrCore.java:2058)
   [junit4]at 
org.apache.solr.util.TestHarness.queryAndResponse(TestHarness.java:339)
   [junit4]at
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.loadLocalFromHandler(ExtractingRequestHandlerTest.ja
va:737)
   [junit4]at
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.loadLocal(ExtractingRequestHandlerTest.java:744)
   [junit4]at
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testArabicPDF(ExtractingRequestHandlerTest.java:526)
   [junit4]at java.lang.Thread.run(Thread.java:745)
{noformat}

 Date field problems using ExtractingRequestHandler and java 9 (b71)
 ---

 Key: SOLR-7770
 URL: https://issues.apache.org/jira/browse/SOLR-7770
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man

 Tracking bug to note that the (Tika based) ExtractingRequestHandler will not 
 work properly with jdk9 starting with build71.
 This first manifested itself with failures like this from the tests...
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=ExtractingRequestHandlerTest
 -Dtests.method=testArabicPDF -Dtests.seed=232D0A5404C2ADED 
 -Dtests.multiplier=3 -Dtests.slow=true
 -Dtests.locale=en_JM -Dtests.timezone=Etc/GMT-7 -Dtests.asserts=true 
 -Dtests.file.encoding=UTF-8
[junit4] ERROR   0.58s | ExtractingRequestHandlerTest.testArabicPDF 
[junit4] Throwable #1: org.apache.solr.common.SolrException: Invalid 
 Date String:'Tue Mar 09 13:44:49
 GMT+07:00 2010'
 {noformat}
 Workarround noted by Uwe...
 {quote}
 The test passes on JDK 9 b71 with:

[jira] [Commented] (SOLR-7770) Date field problems using ExtractingRequestHandler and java 9 (b71)


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

Hoss Man commented on SOLR-7770:


Misc comments from uwe on the mailing list regarding this...

{quote}
I debugged the date parsing problems with a new test (TestDateUtil in solrj).

The reason for this failing is the following 2 things, but they are related (if 
not even the same bug):
- https://bugs.openjdk.java.net/browse/JDK-8129881 is triggered: TIKA uses 
Date#toString() which inserts a broken
timezone shortcut into the resulting date. This cannot be parsed anymore! This 
happens all the timein ROOT Locale
(see below).
- Solr uses Locale.ROOT to parse the date (of course, because it's language 
independent). This locale is missing all
text representations of weekdays or timezones in OpenJDK's CLDR locale data, so 
it cannot parse the weekday or the
time zones. If I change DateUtil to use Locale.ENGLISH, it works as expected.

I will open a bug report at Oracle.
{quote}

...

bq. I opened Report (Review ID: JI-9022158) - Change to CLDR Locale data in JDK 
9 b71 causes SimpleDateFormat parsing errors

...

{quote}
I think the real issue here is the following (Rory can you add this to issue?):

According to Unicode, all locales should fall back to the ROOT locale, if the 
specific Locale does not have data
(e.g., 
http://cldr.unicode.org/development/development-process/design-proposals/generic-calendar-data).
 The problem
is now that the CLDR Java implementation seems to fall back to the root locale, 
but the root locale does not have
weekdays and time zone short names - our test verifies this: ROOT locale is 
missing all this information.

This causes all the bugs, also the one in 
https://bugs.openjdk.java.net/browse/JDK-8129881. The root locale should
have the default English weekday and timezone names (see
http://cldr.unicode.org/development/development-process/design-proposals/generic-calendar-data).

I think the ROOT locale and the fallback mechanism should be revisited in JDK's 
CLDR impl, there seems to be a bug
with that (either missing data or the fallback to defaults does not work 
correctly).
{quote}

from Balchandra...

bq. Here is the JBS id: https://bugs.openjdk.java.net/browse/JDK-8130845



 Date field problems using ExtractingRequestHandler and java 9 (b71)
 ---

 Key: SOLR-7770
 URL: https://issues.apache.org/jira/browse/SOLR-7770
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man

 Tracking bug to note that the (Tika based) ExtractingRequestHandler will not 
 work properly with jdk9 starting with build71.
 This first manifested itself with failures like this from the tests...
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=ExtractingRequestHandlerTest
 -Dtests.method=testArabicPDF -Dtests.seed=232D0A5404C2ADED 
 -Dtests.multiplier=3 -Dtests.slow=true
 -Dtests.locale=en_JM -Dtests.timezone=Etc/GMT-7 -Dtests.asserts=true 
 -Dtests.file.encoding=UTF-8
[junit4] ERROR   0.58s | ExtractingRequestHandlerTest.testArabicPDF 
[junit4] Throwable #1: org.apache.solr.common.SolrException: Invalid 
 Date String:'Tue Mar 09 13:44:49
 GMT+07:00 2010'
 {noformat}
 Workarround noted by Uwe...
 {quote}
 The test passes on JDK 9 b71 with:
 -Dargs=-Djava.locale.providers=JRE,SPI
 This reenabled the old Locale data. I will add this to the build parameters 
 of policeman Jenkins to stop this from
 failing. To me it looks like the locale data somehow is not able to correctly 
 parse weekdays and/or timezones. I
 will check this out tomorrow and report a bug to the OpenJDK people. There is 
 something fishy with CLDR locale data.
 There are already some bugs open, so work is not yet finished (e.g. sometimes 
 it uses wrong timezone shortcuts,...)
 {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6645) BKD tree queries should use BitDocIdSet.Builder

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

Michael McCandless updated LUCENE-6645:
---
Attachment: LUCENE-6645.patch

Slightly improved patch: I moved an assert higher up, and made the calls to
growBuffer consistently only call when threshold.

I'm not sure why the gains are so high, it must be hotspot silliness...

BKD tree queries should use BitDocIdSet.Builder
---

Key: LUCENE-6645
URL: https://issues.apache.org/jira/browse/LUCENE-6645
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
Attachments: LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch,
LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch

When I was iterating on BKD tree originally I remember trying to use this
builder (which makes a sparse bit set at first and then upgrades to dense if
enough bits get set) and being disappointed with its performance.
I wound up just making a FixedBitSet every time, but this is obviously
wasteful for small queries.
It could be the perf was poor because I was always .or'ing in DISIs that had
512 - 1024 hits each time (the size of each leaf cell in the BKD tree)? I
also had to make my own DISI wrapper around each leaf cell... maybe that was
the source of the slowness, not sure.
I also sort of wondered whether the SmallDocSet in spatial module (backed by
a SentinelIntSet) might be faster ... though it'd need to be sorted in the
and after building before returning to Lucene.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 897 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/897/

11 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([C82768D89BAAF9DE]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CollectionsAPIDistributedZkTest

Error Message:
Suite timeout exceeded (= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (= 720 msec).
at __randomizedtesting.SeedInfo.seed([C82768D89BAAF9DE]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CollectionsAPIDistributedZkTest

Error Message:
Captured an uncaught exception in thread: Thread[id=4667, name=collection0, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=4667, name=collection0, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:45440: collection already exists: 
awholynewstresscollection_collection0_0
at __randomizedtesting.SeedInfo.seed([C82768D89BAAF9DE]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1572)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:887)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CollectionsAPIDistributedZkTest

Error Message:
Captured an uncaught exception in thread: Thread[id=4671, name=collection4, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=4671, name=collection4, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:45440: collection already exists: 
awholynewstresscollection_collection4_0
at __randomizedtesting.SeedInfo.seed([C82768D89BAAF9DE]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1572)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:887)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CollectionsAPIDistributedZkTest

Error Message:
Captured an uncaught exception in thread: Thread[id=4670, name=collection3, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=4670,

[jira] [Updated] (LUCENE-6669) PATCH: the the


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

Richard Bowen updated LUCENE-6669:
--
Attachment: (was: the_the.patch)

 PATCH: the the
 --

 Key: LUCENE-6669
 URL: https://issues.apache.org/jira/browse/LUCENE-6669
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Richard Bowen
Priority: Trivial
 Attachments: the_the.patch, the_the.patch


 s/the the/the/g



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6669) PATCH: the the


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

Richard Bowen commented on LUCENE-6669:
---

Um. That's really weird. Sorry about that. Is there a way to delete an 
attachment. Uploading the right file in a moment ...


 PATCH: the the
 --

 Key: LUCENE-6669
 URL: https://issues.apache.org/jira/browse/LUCENE-6669
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Richard Bowen
Priority: Trivial
 Attachments: the_the.patch, the_the.patch


 s/the the/the/g



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-6670) OOM error in merge causes deadlock

2015-07-09 Thread Jeffrey Morlan (JIRA)

Jeffrey Morlan created LUCENE-6670:
--

 Summary: OOM error in merge causes deadlock
 Key: LUCENE-6670
 URL: https://issues.apache.org/jira/browse/LUCENE-6670
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 5.2.1
Reporter: Jeffrey Morlan


Using the ConcurrentMergeScheduler, when merging catches an OutOfMemoryError 
and tries to rollback, the merge thread ends up calling Thread.join on itself, 
which will never complete.

Stack trace (line numbers are for Lucene 5.2.1):
{noformat}
Lucene Merge Thread #1 #356502 daemon prio=5 os_prio=0 tid=0x7f3f78622000 
nid=0x11b5 in Object.wait() [0x7f3e90528000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1245)
- locked 0x0001965aff78 (a 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread)
at java.lang.Thread.join(Thread.java:1319)
at 
org.apache.lucene.index.ConcurrentMergeScheduler.sync(ConcurrentMergeScheduler.java:420)
at 
org.apache.lucene.index.ConcurrentMergeScheduler.close(ConcurrentMergeScheduler.java:401)
at 
org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:1948)
at org.apache.lucene.index.IndexWriter.rollback(IndexWriter.java:1921)
- locked 0x0001965b0100 (a java.lang.Object)
at 
org.apache.lucene.index.IndexWriter.tragicEvent(IndexWriter.java:4439)
- locked 0x0001965b0100 (a java.lang.Object)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3571)
at 
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:581)
at 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:619)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7455) Defer calculating non-sorting stats

2015-07-09 Thread Yonik Seeley (JIRA)


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

Yonik Seeley updated SOLR-7455:
---
Fix Version/s: (was: 5.2)
   5.3

 Defer calculating non-sorting stats
 ---

 Key: SOLR-7455
 URL: https://issues.apache.org/jira/browse/SOLR-7455
 Project: Solr
  Issue Type: Sub-task
Reporter: Yonik Seeley
 Fix For: 5.3


 Currently, all stats are calculated for every facet bucket, then we find the 
 top N with a sort and a limit.  We could choose to only calculate stats 
 needed for such narrowing and then calculate the remainder after.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6669) PATCH: the the


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

Richard Bowen updated LUCENE-6669:
--
Attachment: the_the.patch

I believe the attached patch addresses Robert's comment - reverted changes to 
3p js files, and to test files. Thanks.

 PATCH: the the
 --

 Key: LUCENE-6669
 URL: https://issues.apache.org/jira/browse/LUCENE-6669
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Richard Bowen
Priority: Trivial
 Attachments: the_the.patch, the_the.patch, the_the.patch


 s/the the/the/g



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (LUCENE-6669) PATCH: the the


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

Richard Bowen edited comment on LUCENE-6669 at 7/9/15 5:39 PM:
---

Um. That's really weird. Sorry about that. Bogus attachment removed. Uploading 
the right file in a moment ...



was (Author: rbowen):
Um. That's really weird. Sorry about that. Is there a way to delete an 
attachment. Uploading the right file in a moment ...


 PATCH: the the
 --

 Key: LUCENE-6669
 URL: https://issues.apache.org/jira/browse/LUCENE-6669
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Richard Bowen
Priority: Trivial
 Attachments: the_the.patch, the_the.patch, the_the.patch


 s/the the/the/g



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build # 13198 - Still Failing!

2015-07-09 Thread Chris Hostetter


Tracking this also as a known issue with solr = jdk1.9b71

https://issues.apache.org/jira/browse/SOLR-7770



: Date: Thu, 9 Jul 2015 00:40:25 +0200
: From: Uwe Schindler u...@thetaphi.de
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Cc: rory.odonn...@oracle.com
: Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build #
:  13198 - Still Failing!
: 
: The test passes on JDK 9 b71 with:
: -Dargs=-Djava.locale.providers=JRE,SPI
: 
: This reenabled the old Locale data. I will add this to the build parameters 
of policeman Jenkins to stop this from failing. To me it looks like the locale 
data somehow is not able to correctly parse weekdays and/or timezones. I will 
check this out tomorrow and report a bug to the OpenJDK people. There is 
something fishy with CLDR locale data. There are already some bugs open, so 
work is not yet finished (e.g. sometimes it uses wrong timezone shortcuts,...)
: 
: Uwe
: 
: -
: Uwe Schindler
: H.-H.-Meier-Allee 63, D-28213 Bremen
: http://www.thetaphi.de
: eMail: u...@thetaphi.de
: 
: 
:  -Original Message-
:  From: Uwe Schindler [mailto:u...@thetaphi.de]
:  Sent: Thursday, July 09, 2015 12:16 AM
:  To: dev@lucene.apache.org
:  Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - 
Build #
:  13198 - Still Failing!
:  
:  Hi,
:  
:  It is exactly like that. The contenthandler tries to parse all metadata 
strings as
:  date using DateUtil.parseDate() and if that fails, it leaves them 
unchanged. In
:  JDK 8 it succeeds to parse the date and then converts it to ISO-8601 Solr
:  format. With JDK 9 b71 it passes the plain string in the TIKA format (it 
uses
:  HTTP Cookie-like dates in TIKA), which then fails in TrieDateField.
:  
:  Unfortunately, I was not able to setup Eclipse with JDK 9, so I cannot debug
:  this. I just did this is JDK 8 to verify how it works...
:  
:  We should add a testcase for DateUtil and then try to find out how this 
fails in
:  JDK 9. It looks like this class is completely untested with strange date
:  formats.
:  Uwe
:  
:  -
:  Uwe Schindler
:  H.-H.-Meier-Allee 63, D-28213 Bremen
:  http://www.thetaphi.de
:  eMail: u...@thetaphi.de
:  
:  
:   -Original Message-
:   From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
:   Sent: Wednesday, July 08, 2015 11:46 PM
:   To: dev@lucene.apache.org
:   Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - 
Build
:  #
:   13198 - Still Failing!
:  
:  
:   My guess (haven't verified) is that if you dig into the
:   ExtractionRequestHandler code, you will probably find it parsing Tika
:   Metadata Strings (All Tika metadata are simple Strings, correct?) into
:   Date objects if/when it can/should based on the field type -- and when it
:   can't it propogates the metadata string as is (so that, for example, a
:   subsequent update processor can parse it)
:  
:   The error from TrieDateField is probably just because a completely
:   untouched metadta string (coming from Tika) is not a Date (or a correctly
:   ISO formatted string) ... leaving the big question being: what changed in
:   the JDK such that that tika metadta is no longer being parsed properly
:   into a Date in the first place?
:  
:   (NOTE: I'm speculating in all of this based on what little i remember
:   about Tika)
:  
:  
:   : Date: Wed, 8 Jul 2015 23:35:52 +0200
:   : From: Uwe Schindler u...@thetaphi.de
:   : Reply-To: dev@lucene.apache.org
:   : To: dev@lucene.apache.org
:   : Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -
:  Build
:   #
:   :  13198 - Still Failing!
:   :
:   : In fact this is really strange! The Exception is thrown because the
:   DateMathParser does not find the Z inside the date string - it just
:   complains that its not ISO8601... To me it looks like although it should 
only
:  get
:   ISO8601 date, somehow extracting contenthandler sends a default
:   formatted date to the importer, obviously the one from the input
:  document
:   - maybe TIKA exports it incorrectly...
:   :
:   : Unfortunately I have no idea how to explain this, the bug looks like 
being
:  in
:   contrib/extraction. Importing standard documents with ISO8601 date to
:  Solr
:   works perfectly fine! I have to setup debugging in Eclipse with Java 9!
:   :
:   : Uwe
:   :
:   : -
:   : Uwe Schindler
:   : H.-H.-Meier-Allee 63, D-28213 Bremen
:   : http://www.thetaphi.de
:   : eMail: u...@thetaphi.de
:   :
:   :
:   :  -Original Message-
:   :  From: Uwe Schindler [mailto:u...@thetaphi.de]
:   :  Sent: Wednesday, July 08, 2015 11:19 PM
:   :  To: dev@lucene.apache.org
:   :  Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -
:   Build #
:   :  13198 - Still Failing!
:   : 
:   :  Hi Hoss,
:   : 
:   :  it does not fail with build 70, but suddenly fails with build 71.
:   : 
:   :  The major change in build 71 is (next to the fix for the nasty 
arraycopy
:   bug),
:   :  that the JDK now

[jira] [Commented] (SOLR-7770) Date field problems using ExtractingRequestHandler and java 9 (b71)

2015-07-09 Thread Uwe Schindler (JIRA)


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

Uwe Schindler commented on SOLR-7770:
-

Hi, i keep this issue open for a while. There is nothing we can do at Solr 
side, this is really a bug. The only thing we *could* do is to use 
Locale.ENGLISH instead of Locale.ROOT for date parsing. But this is just a 
workaround and not really a good one.

 Date field problems using ExtractingRequestHandler and java 9 (b71)
 ---

 Key: SOLR-7770
 URL: https://issues.apache.org/jira/browse/SOLR-7770
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man

 Tracking bug to note that the (Tika based) ExtractingRequestHandler will not 
 work properly with jdk9 starting with build71.
 This first manifested itself with failures like this from the tests...
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=ExtractingRequestHandlerTest
 -Dtests.method=testArabicPDF -Dtests.seed=232D0A5404C2ADED 
 -Dtests.multiplier=3 -Dtests.slow=true
 -Dtests.locale=en_JM -Dtests.timezone=Etc/GMT-7 -Dtests.asserts=true 
 -Dtests.file.encoding=UTF-8
[junit4] ERROR   0.58s | ExtractingRequestHandlerTest.testArabicPDF 
[junit4] Throwable #1: org.apache.solr.common.SolrException: Invalid 
 Date String:'Tue Mar 09 13:44:49
 GMT+07:00 2010'
 {noformat}
 Workarround noted by Uwe...
 {quote}
 The test passes on JDK 9 b71 with:
 -Dargs=-Djava.locale.providers=JRE,SPI
 This reenabled the old Locale data. I will add this to the build parameters 
 of policeman Jenkins to stop this from
 failing. To me it looks like the locale data somehow is not able to correctly 
 parse weekdays and/or timezones. I
 will check this out tomorrow and report a bug to the OpenJDK people. There is 
 something fishy with CLDR locale data.
 There are already some bugs open, so work is not yet finished (e.g. sometimes 
 it uses wrong timezone shortcuts,...)
 {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7770) Date field problems using ExtractingRequestHandler and java 9 (b71)


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

Hoss Man commented on SOLR-7770:


bq. There is nothing we can do at Solr side, ...

correct.  my main concern is having an open issue here to track the known 
problem and the workarround -- once there is a jdk9 that doesn't have this 
problem we can resolve SOLR-7770 and note which JDK versions are known to work 
(vs known to be broken)

 Date field problems using ExtractingRequestHandler and java 9 (b71)
 ---

 Key: SOLR-7770
 URL: https://issues.apache.org/jira/browse/SOLR-7770
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man

 Tracking bug to note that the (Tika based) ExtractingRequestHandler will not 
 work properly with jdk9 starting with build71.
 This first manifested itself with failures like this from the tests...
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=ExtractingRequestHandlerTest
 -Dtests.method=testArabicPDF -Dtests.seed=232D0A5404C2ADED 
 -Dtests.multiplier=3 -Dtests.slow=true
 -Dtests.locale=en_JM -Dtests.timezone=Etc/GMT-7 -Dtests.asserts=true 
 -Dtests.file.encoding=UTF-8
[junit4] ERROR   0.58s | ExtractingRequestHandlerTest.testArabicPDF 
[junit4] Throwable #1: org.apache.solr.common.SolrException: Invalid 
 Date String:'Tue Mar 09 13:44:49
 GMT+07:00 2010'
 {noformat}
 Workarround noted by Uwe...
 {quote}
 The test passes on JDK 9 b71 with:
 -Dargs=-Djava.locale.providers=JRE,SPI
 This reenabled the old Locale data. I will add this to the build parameters 
 of policeman Jenkins to stop this from
 failing. To me it looks like the locale data somehow is not able to correctly 
 parse weekdays and/or timezones. I
 will check this out tomorrow and report a bug to the OpenJDK people. There is 
 something fishy with CLDR locale data.
 There are already some bugs open, so work is not yet finished (e.g. sometimes 
 it uses wrong timezone shortcuts,...)
 {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-7172) addreplica API fails with incorrect error msg cannot create collection


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

Erick Erickson reassigned SOLR-7172:


Assignee: Erick Erickson  (was: Shalin Shekhar Mangar)

 addreplica API fails with incorrect error msg cannot create collection
 

 Key: SOLR-7172
 URL: https://issues.apache.org/jira/browse/SOLR-7172
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.10.3, 5.0
Reporter: Shalin Shekhar Mangar
Assignee: Erick Erickson
 Fix For: 5.2, Trunk

 Attachments: SOLR-7172.patch


 Steps to reproduce:
 # Create 1 node solr cloud cluster
 # Create collection 'test' with 
 numShards=1replicationFactor=1maxShardsPerNode=1
 # Call addreplica API:
 {code}
 http://localhost:8983/solr/admin/collections?action=addreplicacollection=testshard=shard1wt=json
  
 {code}
 API fails with the following response:
 {code}
 {
 responseHeader: {
 status: 400,
 QTime: 9
 },
 Operation ADDREPLICA caused exception:: 
 org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
 Cannot create collection test. No live Solr-instances,
 exception: {
 msg: Cannot create collection test. No live Solr-instances,
 rspCode: 400
 },
 error: {
 msg: Cannot create collection test. No live Solr-instances,
 code: 400
 }
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7132) The Collections API ADDREPLICA command property.name is not reflected in the clusterstate until after Solr restarts


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

Erick Erickson updated SOLR-7132:
-
Attachment: SOLR-7132.patch

Final patch.

 The Collections API ADDREPLICA command property.name is not reflected in the 
 clusterstate until after Solr restarts
 ---

 Key: SOLR-7132
 URL: https://issues.apache.org/jira/browse/SOLR-7132
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1, Trunk
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Attachments: SOLR-7132.patch


 If you do an ADDREPLICA command with property.name=nonsense then go look at 
 clusterstate.json, you'll see the default name for the replica. But if you 
 then restart Solr, you see the name you specified on the create command, 
 which is a bit confusing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-7771) Classloader problem with solr.XXX class names and jars in SOLR_HOME/lib

2015-07-09 Thread Shawn Heisey (JIRA)

Shawn Heisey created SOLR-7771:
--

 Summary: Classloader problem with solr.XXX class names and jars 
in SOLR_HOME/lib
 Key: SOLR-7771
 URL: https://issues.apache.org/jira/browse/SOLR-7771
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.2.1
 Environment: C:\Users\elyograg\Downloads\solr-5.2.1java -version
java version 1.8.0_45
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
Reporter: Shawn Heisey


Jars placed in SOLR_HOME/lib seem to be loaded twice, which causes problems 
trying to use solr.XX class names in schema.xml.

If the full class name is used, it works.

Steps to recreate on an extracted Solr 5.2.1 download.  This was done on 
Windows, so I used backslashes as path separators:

{noformat}
bin\solr start
bin\solr create -c foo -d sample_techproducts_configs
bin\solr stop -all
{noformat}

Add the following to server\foo\conf\schema.xml, just before the /schema end 
tag:

{noformat}
fieldType name=icu_test class=solr.TextField
  analyzer 
tokenizer class=solr.ICUTokenizerFactory/
  /analyzer
/fieldType
{noformat}

Create a new directory -- server\solr\lib.
Copy icu4j-54.1.jar and lucene-analyzers-icu-5.2.1.jar from 
contrib\analysis-extras to server\solr\lib.

{noformat}
bin\solr start
{noformat}

Note an exception in the logging tab:
java.lang.NoClassDefFoundError: 
org/apache/lucene/analysis/icu/segmentation/ICUTokenizer

At this point, if the class name is changed from solr.ICUTokenizerFactory to 
org.apache.lucene.analysis.icu.segmentation.ICUTokenizerFactory and solr is 
stopped and started, then everything is OK.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 735 - Still Failing

2015-07-09 Thread ASF subversion and git services (JIRA)

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/735/

2 tests failed.
REGRESSION:  org.apache.solr.cloud.hdfs.HdfsChaosMonkeySafeLeaderTest.test

Error Message:
shard4 is not consistent.  Got 74 from 
http://127.0.0.1:50144/collection1lastClient and got 38 from 
http://127.0.0.1:47734/collection1

Stack Trace:
java.lang.AssertionError: shard4 is not consistent.  Got 74 from 
http://127.0.0.1:50144/collection1lastClient and got 38 from 
http://127.0.0.1:47734/collection1
at 
__randomizedtesting.SeedInfo.seed([D83020E37C7B824C:50641F39D287EFB4]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1244)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1223)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:165)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at

[jira] [Commented] (SOLR-7455) Defer calculating non-sorting stats


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

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

Commit 1690189 from [~yo...@apache.org] in branch 'dev/trunk'
[ https://svn.apache.org/r1690189 ]

SOLR-7455: defer non-sorting facet stats

 Defer calculating non-sorting stats
 ---

 Key: SOLR-7455
 URL: https://issues.apache.org/jira/browse/SOLR-7455
 Project: Solr
  Issue Type: Sub-task
Reporter: Yonik Seeley
 Fix For: 5.3

 Attachments: SOLR-7455.patch


 Currently, all stats are calculated for every facet bucket, then we find the 
 top N with a sort and a limit.  We could choose to only calculate stats 
 needed for such narrowing and then calculate the remainder after.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7132) The Collections API ADDREPLICA command property.name is not reflected in the clusterstate until after Solr restarts

2015-07-09 Thread ASF subversion and git services (JIRA)


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

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

Commit 1690190 from [~erickoerickson] in branch 'dev/trunk'
[ https://svn.apache.org/r1690190 ]

SOLR-7132: The Collections API ADDREPLICA command property.name is not 
reflected in the clusterstate until after Solr restarts

 The Collections API ADDREPLICA command property.name is not reflected in the 
 clusterstate until after Solr restarts
 ---

 Key: SOLR-7132
 URL: https://issues.apache.org/jira/browse/SOLR-7132
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1, Trunk
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Attachments: SOLR-7132.patch


 If you do an ADDREPLICA command with property.name=nonsense then go look at 
 clusterstate.json, you'll see the default name for the replica. But if you 
 then restart Solr, you see the name you specified on the create command, 
 which is a bit confusing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7771) Classloader problem with solr.XXX class names and jars in SOLR_HOME/lib

2015-07-09 Thread Shawn Heisey (JIRA)


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

Shawn Heisey commented on SOLR-7771:


This is the first part of the solr log during the startup with the errors:

{noformat}
INFO  - 2015-07-10 02:11:12.626; [   ] org.eclipse.jetty.util.log.Log; Logging 
initialized @216ms
INFO  - 2015-07-10 02:11:12.745; [   ] org.eclipse.jetty.server.Server; 
jetty-9.2.10.v20150310
WARN  - 2015-07-10 02:11:12.756; [   ] 
org.eclipse.jetty.server.handler.RequestLogHandler; !RequestLog
INFO  - 2015-07-10 02:11:12.757; [   ] 
org.eclipse.jetty.deploy.providers.ScanningAppProvider; Deployment monitor 
[file:/C:/Users/elyograg/Downloads/solr-5.2.1/server/contexts/] at interval 0
INFO  - 2015-07-10 02:11:13.219; [   ] 
org.eclipse.jetty.webapp.StandardDescriptorProcessor; NO JSP Support for /solr, 
did not find org.apache.jasper.servlet.JspServlet
WARN  - 2015-07-10 02:11:13.237; [   ] 
org.eclipse.jetty.security.ConstraintSecurityHandler; 
ServletContext@o.e.j.w.WebAppContext@457e2f02{/solr,file:/C:/Users/elyograg/Downloads/solr-5.2.1/server/solr-webapp/webapp/,STARTING}{/solr.war}
 has uncovered http methods for path: /
INFO  - 2015-07-10 02:11:13.258; [   ] 
org.apache.solr.servlet.SolrDispatchFilter; 
SolrDispatchFilter.init()WebAppClassLoader=1582797472@5e5792a0
INFO  - 2015-07-10 02:11:13.268; [   ] org.apache.solr.core.SolrResourceLoader; 
JNDI not configured for solr (NoInitialContextEx)
INFO  - 2015-07-10 02:11:13.269; [   ] org.apache.solr.core.SolrResourceLoader; 
using system property solr.solr.home: 
C:\Users\elyograg\Downloads\solr-5.2.1\server\solr
INFO  - 2015-07-10 02:11:13.269; [   ] org.apache.solr.core.SolrResourceLoader; 
new SolrResourceLoader for directory: 
'C:\Users\elyograg\Downloads\solr-5.2.1\server\solr\'
INFO  - 2015-07-10 02:11:13.270; [   ] org.apache.solr.core.SolrResourceLoader; 
Adding 
'file:/C:/Users/elyograg/Downloads/solr-5.2.1/server/solr/lib/icu4j-54.1.jar' 
to classloader
INFO  - 2015-07-10 02:11:13.271; [   ] org.apache.solr.core.SolrResourceLoader; 
Adding 
'file:/C:/Users/elyograg/Downloads/solr-5.2.1/server/solr/lib/lucene-analyzers-icu-5.2.1.jar'
 to classloader
INFO  - 2015-07-10 02:11:13.381; [   ] org.apache.solr.core.SolrXmlConfig; 
Loading container configuration from 
C:\Users\elyograg\Downloads\solr-5.2.1\server\solr\solr.xml
INFO  - 2015-07-10 02:11:13.431; [   ] 
org.apache.solr.core.CorePropertiesLocator; Config-defined core root directory: 
C:\Users\elyograg\Downloads\solr-5.2.1\server\solr
INFO  - 2015-07-10 02:11:13.447; [   ] org.apache.solr.core.CoreContainer; New 
CoreContainer 1362728240
INFO  - 2015-07-10 02:11:13.448; [   ] org.apache.solr.core.CoreContainer; 
Loading cores into CoreContainer 
[instanceDir=C:\Users\elyograg\Downloads\solr-5.2.1\server\solr\]
INFO  - 2015-07-10 02:11:13.449; [   ] org.apache.solr.core.CoreContainer; 
loading shared library: C:\Users\elyograg\Downloads\solr-5.2.1\server\solr\lib
INFO  - 2015-07-10 02:11:13.449; [   ] org.apache.solr.core.SolrResourceLoader; 
Adding 
'file:/C:/Users/elyograg/Downloads/solr-5.2.1/server/solr/lib/icu4j-54.1.jar' 
to classloader
INFO  - 2015-07-10 02:11:13.450; [   ] org.apache.solr.core.SolrResourceLoader; 
Adding 
'file:/C:/Users/elyograg/Downloads/solr-5.2.1/server/solr/lib/lucene-analyzers-icu-5.2.1.jar'
 to classloader
{noformat}

In it you can see the two jars being loaded twice, both times from the newly 
created lib directory.

 Classloader problem with solr.XXX class names and jars in SOLR_HOME/lib
 -

 Key: SOLR-7771
 URL: https://issues.apache.org/jira/browse/SOLR-7771
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.2.1
 Environment: C:\Users\elyograg\Downloads\solr-5.2.1java -version
 java version 1.8.0_45
 Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
 Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
Reporter: Shawn Heisey

 Jars placed in SOLR_HOME/lib seem to be loaded twice, which causes problems 
 trying to use solr.XX class names in schema.xml.
 If the full class name is used, it works.
 Steps to recreate on an extracted Solr 5.2.1 download.  This was done on 
 Windows, so I used backslashes as path separators:
 {noformat}
 bin\solr start
 bin\solr create -c foo -d sample_techproducts_configs
 bin\solr stop -all
 {noformat}
 Add the following to server\foo\conf\schema.xml, just before the /schema 
 end tag:
 {noformat}
 fieldType name=icu_test class=solr.TextField
   analyzer 
 tokenizer class=solr.ICUTokenizerFactory/
   /analyzer
 /fieldType
 {noformat}
 Create a new directory -- server\solr\lib.
 Copy icu4j-54.1.jar and lucene-analyzers-icu-5.2.1.jar from 
 contrib\analysis-extras to server\solr\lib.
 {noformat}
 bin\solr

[jira] [Commented] (SOLR-6234) Scoring modes for query time join

2015-07-09 Thread Ryan Josal (JIRA)


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

Ryan Josal commented on SOLR-6234:
--

That makes a lot of sense David, I would prefer this as it would reduce 
confusion, some similar code, and make implementation changes in the future 
more flexible.

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Timothy Potter
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, 
 otherHandler.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7132) The Collections API ADDREPLICA command property.name is not reflected in the clusterstate until after Solr restarts

2015-07-09 Thread ASF subversion and git services (JIRA)


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

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

Commit 1690198 from [~erickoerickson] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1690198 ]

SOLR-7132: The Collections API ADDREPLICA command property.name is not 
reflected in the clusterstate until after Solr restarts

 The Collections API ADDREPLICA command property.name is not reflected in the 
 clusterstate until after Solr restarts
 ---

 Key: SOLR-7132
 URL: https://issues.apache.org/jira/browse/SOLR-7132
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1, Trunk
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Attachments: SOLR-7132.patch


 If you do an ADDREPLICA command with property.name=nonsense then go look at 
 clusterstate.json, you'll see the default name for the replica. But if you 
 then restart Solr, you see the name you specified on the create command, 
 which is a bit confusing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (SOLR-7132) The Collections API ADDREPLICA command property.name is not reflected in the clusterstate until after Solr restarts

2015-07-09 Thread ASF subversion and git services (JIRA)


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

Erick Erickson closed SOLR-7132.

   Resolution: Fixed
Fix Version/s: Trunk
   5.3

 The Collections API ADDREPLICA command property.name is not reflected in the 
 clusterstate until after Solr restarts
 ---

 Key: SOLR-7132
 URL: https://issues.apache.org/jira/browse/SOLR-7132
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1, Trunk
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Fix For: 5.3, Trunk

 Attachments: SOLR-7132.patch


 If you do an ADDREPLICA command with property.name=nonsense then go look at 
 clusterstate.json, you'll see the default name for the replica. But if you 
 then restart Solr, you see the name you specified on the create command, 
 which is a bit confusing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6234) Scoring modes for query time join

2015-07-09 Thread David Smiley (JIRA)


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

David Smiley commented on SOLR-6234:


One tiny bit of input I have on this is rather cosmetic but nonetheless it'd be 
nice if the scoring mode could be specified via a local-param on the existing 
\{!join} QParserPlugin.  It's still a join, we just want the score too.  It 
very well may have a different implementation when it's scoring but that's an 
implementation detail.

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Timothy Potter
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, 
 otherHandler.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7455) Defer calculating non-sorting stats


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

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

Commit 1690199 from [~yo...@apache.org] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1690199 ]

SOLR-7455: defer non-sorting facet stats

 Defer calculating non-sorting stats
 ---

 Key: SOLR-7455
 URL: https://issues.apache.org/jira/browse/SOLR-7455
 Project: Solr
  Issue Type: Sub-task
Reporter: Yonik Seeley
 Fix For: 5.3

 Attachments: SOLR-7455.patch


 Currently, all stats are calculated for every facet bucket, then we find the 
 top N with a sort and a limit.  We could choose to only calculate stats 
 needed for such narrowing and then calculate the remainder after.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6645) BKD tree queries should use BitDocIdSet.Builder

2015-07-09 Thread David Smiley (JIRA)

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

David Smiley commented on LUCENE-6645:
--

I took a look at the code out of curiosity and I see that BitDocIdSetBuilder
is the old implementation and that it's been kept around in the spatial module
for the IntersectsRPTVerifyQuery. I think that deserved mention in the
commentary here. Can't we remove it, and have IntersectsRPTVerifyQuery use the
new DocIdSetBuilder? I suspect this was done because of
BitDocIdSetBuilder.isDefinitelyEmpty(); yes? If so can't we add a similar
method to DocIdSetBuilder?

Shouldn't QueryBitSetProducer in the join module use RoaringDocIdSet for it's
cached docIdSets instead of the Fixed/Sparse choice chosen by the new BitSet.of
method added in this patch? RoaringDocIdSet is ideal for caches; no?

BKD tree queries should use BitDocIdSet.Builder
---

Key: LUCENE-6645
URL: https://issues.apache.org/jira/browse/LUCENE-6645
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
Fix For: 5.3, Trunk

Attachments: LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch,
LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6645) BKD tree queries should use BitDocIdSet.Builder

2015-07-09 Thread ASF subversion and git services (JIRA)


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

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

Commit 1690026 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1690026 ]

LUCENE-6645: Optimized DocIdSet building for the many small postings lists 
case.

 BKD tree queries should use BitDocIdSet.Builder
 ---

 Key: LUCENE-6645
 URL: https://issues.apache.org/jira/browse/LUCENE-6645
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
 Attachments: LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch, 
 LUCENE-6645.patch


 When I was iterating on BKD tree originally I remember trying to use this 
 builder (which makes a sparse bit set at first and then upgrades to dense if 
 enough bits get set) and being disappointed with its performance.
 I wound up just making a FixedBitSet every time, but this is obviously 
 wasteful for small queries.
 It could be the perf was poor because I was always .or'ing in DISIs that had 
 512 - 1024 hits each time (the size of each leaf cell in the BKD tree)?  I 
 also had to make my own DISI wrapper around each leaf cell... maybe that was 
 the source of the slowness, not sure.
 I also sort of wondered whether the SmallDocSet in spatial module (backed by 
 a SentinelIntSet) might be faster ... though it'd need to be sorted in the 
 and after building before returning to Lucene.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build # 13198 - Still Failing!

Hi,

I debugged the date parsing problems with a new test (TestDateUtil in solrj).

The reason for this failing is the following 2 things, but they are related (if 
not even the same bug):
- https://bugs.openjdk.java.net/browse/JDK-8129881 is triggered: TIKA uses 
Date#toString() which inserts a broken timezone shortcut into the resulting 
date. This cannot be parsed anymore! This happens all the timein ROOT Locale 
(see below).
- Solr uses Locale.ROOT to parse the date (of course, because it's language 
independent). This locale is missing all text representations of weekdays or 
timezones in OpenJDK's CLDR locale data, so it cannot parse the weekday or the 
time zones. If I change DateUtil to use Locale.ENGLISH, it works as expected.

I will open a bug report at Oracle.

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


 -Original Message-
 From: Uwe Schindler [mailto:u...@thetaphi.de]
 Sent: Thursday, July 09, 2015 12:47 AM
 To: dev@lucene.apache.org
 Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build #
 13198 - Still Failing!
 
 Could be something like this bug:
 https://bugs.openjdk.java.net/browse/JDK-8129881
 
 -
 Uwe Schindler
 H.-H.-Meier-Allee 63, D-28213 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de
 
 
  -Original Message-
  From: Uwe Schindler [mailto:u...@thetaphi.de]
  Sent: Thursday, July 09, 2015 12:40 AM
  To: dev@lucene.apache.org
  Cc: rory.odonn...@oracle.com
  Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build
 #
  13198 - Still Failing!
 
  The test passes on JDK 9 b71 with:
  -Dargs=-Djava.locale.providers=JRE,SPI
 
  This reenabled the old Locale data. I will add this to the build parameters 
  of
  policeman Jenkins to stop this from failing. To me it looks like the locale
 data
  somehow is not able to correctly parse weekdays and/or timezones. I will
  check this out tomorrow and report a bug to the OpenJDK people. There is
  something fishy with CLDR locale data. There are already some bugs open,
 so
  work is not yet finished (e.g. sometimes it uses wrong timezone
 shortcuts,...)
 
  Uwe
 
  -
  Uwe Schindler
  H.-H.-Meier-Allee 63, D-28213 Bremen
  http://www.thetaphi.de
  eMail: u...@thetaphi.de
 
 
   -Original Message-
   From: Uwe Schindler [mailto:u...@thetaphi.de]
   Sent: Thursday, July 09, 2015 12:16 AM
   To: dev@lucene.apache.org
   Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -
 Build
  #
   13198 - Still Failing!
  
   Hi,
  
   It is exactly like that. The contenthandler tries to parse all metadata
 strings
  as
   date using DateUtil.parseDate() and if that fails, it leaves them
 unchanged.
  In
   JDK 8 it succeeds to parse the date and then converts it to ISO-8601 Solr
   format. With JDK 9 b71 it passes the plain string in the TIKA format (it 
   uses
   HTTP Cookie-like dates in TIKA), which then fails in TrieDateField.
  
   Unfortunately, I was not able to setup Eclipse with JDK 9, so I cannot
 debug
   this. I just did this is JDK 8 to verify how it works...
  
   We should add a testcase for DateUtil and then try to find out how this
 fails
  in
   JDK 9. It looks like this class is completely untested with strange date
   formats.
   Uwe
  
   -
   Uwe Schindler
   H.-H.-Meier-Allee 63, D-28213 Bremen
   http://www.thetaphi.de
   eMail: u...@thetaphi.de
  
  
-Original Message-
From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
Sent: Wednesday, July 08, 2015 11:46 PM
To: dev@lucene.apache.org
Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -
  Build
   #
13198 - Still Failing!
   
   
My guess (haven't verified) is that if you dig into the
ExtractionRequestHandler code, you will probably find it parsing Tika
Metadata Strings (All Tika metadata are simple Strings, correct?) into
Date objects if/when it can/should based on the field type -- and when
 it
can't it propogates the metadata string as is (so that, for example, a
subsequent update processor can parse it)
   
The error from TrieDateField is probably just because a completely
untouched metadta string (coming from Tika) is not a Date (or a
 correctly
ISO formatted string) ... leaving the big question being: what changed 
in
the JDK such that that tika metadta is no longer being parsed properly
into a Date in the first place?
   
(NOTE: I'm speculating in all of this based on what little i remember
about Tika)
   
   
: Date: Wed, 8 Jul 2015 23:35:52 +0200
: From: Uwe Schindler u...@thetaphi.de
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -
   Build
#
:  13198 - Still Failing!
:
: In fact this is really strange! The Exception is thrown because the
DateMathParser does not find the Z

[jira] [Commented] (SOLR-7172) addreplica API fails with incorrect error msg cannot create collection

2015-07-09 Thread Noble Paul (JIRA)


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

Noble Paul commented on SOLR-7172:
--

bq.It seems to me that nodeList is the wrong thing to be looking at as well, 
we've already collected a list of nodes we could put additional replicas on

Yes. your observation is correct. {{nodeNameVsShardCount}} has the appropriate 
nodes and it should be used to arrive at  {{maxCoresAllowedToCreate}}  

bq.How this interacts with rules is a mystery to me though

Rules actually ignores the {{maxShardsPerNode}} param. It totally relies on the 
rules to identify the nodes

While you are working on this please rename the class {{Node}} to something 
like {{ReplicaCount}} or whatever is suitable 

 addreplica API fails with incorrect error msg cannot create collection
 

 Key: SOLR-7172
 URL: https://issues.apache.org/jira/browse/SOLR-7172
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.10.3, 5.0
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
 Fix For: 5.2, Trunk

 Attachments: SOLR-7172.patch


 Steps to reproduce:
 # Create 1 node solr cloud cluster
 # Create collection 'test' with 
 numShards=1replicationFactor=1maxShardsPerNode=1
 # Call addreplica API:
 {code}
 http://localhost:8983/solr/admin/collections?action=addreplicacollection=testshard=shard1wt=json
  
 {code}
 API fails with the following response:
 {code}
 {
 responseHeader: {
 status: 400,
 QTime: 9
 },
 Operation ADDREPLICA caused exception:: 
 org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
 Cannot create collection test. No live Solr-instances,
 exception: {
 msg: Cannot create collection test. No live Solr-instances,
 rspCode: 400
 },
 error: {
 msg: Cannot create collection test. No live Solr-instances,
 code: 400
 }
 }
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 734 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/734/

5 tests failed.
REGRESSION:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
Didn't see all replicas for shard shard1 in c8n_1x2 come up within 3 ms! 
ClusterState: {   collection1:{ replicationFactor:1, shards:{   
shard1:{ range:8000-, state:active,   
  replicas:{core_node2:{ core:collection1, 
base_url:http://127.0.0.1:52977;, 
node_name:127.0.0.1:52977_, state:active, 
leader:true}}},   shard2:{ range:0-7fff, 
state:active, replicas:{   core_node1:{ 
core:collection1, base_url:http://127.0.0.1:48885;,  
   node_name:127.0.0.1:48885_, state:active, 
leader:true},   core_node3:{ core:collection1,
 base_url:http://127.0.0.1:56562;, 
node_name:127.0.0.1:56562_, state:active, 
router:{name:compositeId}, maxShardsPerNode:1, 
autoAddReplicas:false, autoCreated:true},   control_collection:{  
   replicationFactor:1, shards:{shard1:{ 
range:8000-7fff, state:active, 
replicas:{core_node1:{ core:collection1, 
base_url:http://127.0.0.1:56797;, 
node_name:127.0.0.1:56797_, state:active, 
leader:true, router:{name:compositeId}, 
maxShardsPerNode:1, autoAddReplicas:false, 
autoCreated:true},   c8n_1x2:{ replicationFactor:2, 
shards:{shard1:{ range:8000-7fff, 
state:active, replicas:{   core_node1:{ 
core:c8n_1x2_shard1_replica2, 
base_url:http://127.0.0.1:48885;, 
node_name:127.0.0.1:48885_, state:active, 
leader:true},   core_node2:{ 
core:c8n_1x2_shard1_replica1, 
base_url:http://127.0.0.1:56562;, 
node_name:127.0.0.1:56562_, state:recovering, 
router:{name:compositeId}, maxShardsPerNode:1, 
autoAddReplicas:false}}

Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in c8n_1x2 
come up within 3 ms! ClusterState: {
  collection1:{
replicationFactor:1,
shards:{
  shard1:{
range:8000-,
state:active,
replicas:{core_node2:{
core:collection1,
base_url:http://127.0.0.1:52977;,
node_name:127.0.0.1:52977_,
state:active,
leader:true}}},
  shard2:{
range:0-7fff,
state:active,
replicas:{
  core_node1:{
core:collection1,
base_url:http://127.0.0.1:48885;,
node_name:127.0.0.1:48885_,
state:active,
leader:true},
  core_node3:{
core:collection1,
base_url:http://127.0.0.1:56562;,
node_name:127.0.0.1:56562_,
state:active,
router:{name:compositeId},
maxShardsPerNode:1,
autoAddReplicas:false,
autoCreated:true},
  control_collection:{
replicationFactor:1,
shards:{shard1:{
range:8000-7fff,
state:active,
replicas:{core_node1:{
core:collection1,
base_url:http://127.0.0.1:56797;,
node_name:127.0.0.1:56797_,
state:active,
leader:true,
router:{name:compositeId},
maxShardsPerNode:1,
autoAddReplicas:false,
autoCreated:true},
  c8n_1x2:{
replicationFactor:2,
shards:{shard1:{
range:8000-7fff,
state:active,
replicas:{
  core_node1:{
core:c8n_1x2_shard1_replica2,
base_url:http://127.0.0.1:48885;,
node_name:127.0.0.1:48885_,
state:active,
leader:true},
  core_node2:{
core:c8n_1x2_shard1_replica1,
base_url:http://127.0.0.1:56562;,
node_name:127.0.0.1:56562_,
state:recovering,
router:{name:compositeId},
maxShardsPerNode:1,
autoAddReplicas:false}}
at 
__randomizedtesting.SeedInfo.seed([20660CD84FFDF448:A8323302E10199B0]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.ensureAllReplicasAreActive(AbstractFullDistribZkTestBase.java:1842)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:248)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_45) - Build # 13384 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13384/
Java: 64bit/jdk1.8.0_45 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [TransactionLog]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [TransactionLog]
at __randomizedtesting.SeedInfo.seed([A03D06DC214B8F4A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:235)
at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 10477 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2 Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.HttpPartitionTest_A03D06DC214B8F4A-001/init-core-data-001
   [junit4]   2 1003538 INFO  
(SUITE-HttpPartitionTest-seed#[A03D06DC214B8F4A]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: 
/xwql/ce
   [junit4]   2 1003540 INFO  
(TEST-HttpPartitionTest.test-seed#[A03D06DC214B8F4A]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2 1003540 INFO  (Thread-3302) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2 1003540 INFO  (Thread-3302) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2 1003640 INFO  
(TEST-HttpPartitionTest.test-seed#[A03D06DC214B8F4A]) [] 
o.a.s.c.ZkTestServer start zk server on port:45680
   [junit4]   2 1003640 INFO  
(TEST-HttpPartitionTest.test-seed#[A03D06DC214B8F4A]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2 1003641 INFO  
(TEST-HttpPartitionTest.test-seed#[A03D06DC214B8F4A]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2 1003644 INFO  (zkCallback-788-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@7ee41b4f 
name:ZooKeeperConnection Watcher:127.0.0.1:45680 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2 1003644 INFO  
(TEST-HttpPartitionTest.test-seed#[A03D06DC214B8F4A]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2 1003644 INFO  
(TEST-HttpPartitionTest.test-seed#[A03D06DC214B8F4A]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2 1003644 INFO  
(TEST-HttpPartitionTest.test-seed#[A03D06DC214B8F4A]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]

[jira] [Updated] (SOLR-7755) An API to edit the Basic Auth security params

2015-07-09 Thread Noble Paul (JIRA)


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

Noble Paul updated SOLR-7755:
-
Description: 
example: authentication commands
{code}
curl http://localhost:8983/solr/admin/authentication  -d '{
add-user: {tom:TomIsCool},
set-password:{ tom:TomIsUberCool}
}'
{code}
example : authorization commands
{code}
curl http://localhost:8983/solr/admin/authorization  -d '{
{set-user-role: { tom: [admin,dev]},
set-permission:{name: security-admin,
path: [/admin/authentication,/admin/authorization],
role: admin
},
set-permission:{name:some-permission,
collection:acoll,
path:/nonexistentpath,
role:guest,
before:security-admin
}
}'
{code}

Please note that the set of parameters required for a basic ZK based impl will 
be completely different from that of a Kerberos implementation. However the 
framework would remain the same. The end point will remain the same, though

  was:
example
{code}
curl http://localhost:8983/solr/admin/authorization -H 
'Content-type:application/json' -d '{
add-user : {name : tom, 
 role: [admin,dev]
 },
create-permission :{name:mycoll-update,
  before :some-other-permission,
  path:/update/*
  role:[dev,admin]
  }

}'
{code}

Please note that the set of parameters required for a basic ZK based impl will 
be completely different from that of a Kerberos implementation. However the 
framework would remain the same. The end point will remain the same, though


 An API to edit the Basic Auth security params
 -

 Key: SOLR-7755
 URL: https://issues.apache.org/jira/browse/SOLR-7755
 Project: Solr
  Issue Type: Sub-task
  Components: security
Reporter: Noble Paul
Assignee: Noble Paul

 example: authentication commands
 {code}
 curl http://localhost:8983/solr/admin/authentication  -d '{
 add-user: {tom:TomIsCool},
 set-password:{ tom:TomIsUberCool}
 }'
 {code}
 example : authorization commands
 {code}
 curl http://localhost:8983/solr/admin/authorization  -d '{
 {set-user-role: { tom: [admin,dev]},
 set-permission:{name: security-admin,
 path: [/admin/authentication,/admin/authorization],
 role: admin
 },
 set-permission:{name:some-permission,
 collection:acoll,
 path:/nonexistentpath,
 role:guest,
 before:security-admin
 }
 }'
 {code}
 Please note that the set of parameters required for a basic ZK based impl 
 will be completely different from that of a Kerberos implementation. However 
 the framework would remain the same. The end point will remain the same, 
 though



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Is solrconfig.xml a potentially misleading filename?

2015-07-09 Thread Shawn Heisey

I had a thought, wondering if the idea is completely insane.

The config file named solrconfig.xml suggests that it is a config file
for all of Solr, rather than configuring an individual index (core).

The radical idea that came out of this realization is to transition to
something like coreconfig.xml or core.xml instead.  All 5.x versions
would need to continue working with solrconfig.xml, if config is not
present in core.properties.

The name solrconfig.xml would be more appropriate for what is currently
found in solr.xml, but trying to do that rename would be enormously
confusing and painful for upgrading users, so I am not suggesting it.

Thoughts?

Thanks,
Shawn


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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 173 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/173/

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest

Error Message:
ERROR: SolrIndexSearcher opens=8 closes=7

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=8 closes=7
at __randomizedtesting.SeedInfo.seed([D7E6A177C0391159]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:472)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:232)
at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest: 1) Thread[id=3358, 
name=searcherExecutor-1684-thread-1, state=WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)2) Thread[id=3339, 
name=qtp404858408-3339, state=WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest] 
at java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:502) at 
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient.blockUntilFinished(ConcurrentUpdateSolrClient.java:404)
 at 
org.apache.solr.update.StreamingSolrClients.blockUntilFinished(StreamingSolrClients.java:103)
 at 
org.apache.solr.update.SolrCmdDistributor.blockAndDoRetries(SolrCmdDistributor.java:231)
 at 
org.apache.solr.update.SolrCmdDistributor.finish(SolrCmdDistributor.java:89)
 at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doFinish(DistributedUpdateProcessor.java:782)
 at 
org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1656)
 at 
org.apache.solr.update.processor.LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:183)
 at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:83)
 at

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3316 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3316/

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
ERROR: SolrIndexSearcher opens=51 closes=50

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50
at __randomizedtesting.SeedInfo.seed([D39203B3C85C715F]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:472)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:232)
at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=13683, name=searcherExecutor-5132-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestLazyCores: 
   1) Thread[id=13683, name=searcherExecutor-5132-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([D39203B3C85C715F]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=13683, name=searcherExecutor-5132-thread-1, state=WAITING,

[jira] [Created] (LUCENE-6668) Optimize SortedSet/SortedNumeric storage for the few unique sets use-case

Adrien Grand created LUCENE-6668:


 Summary: Optimize SortedSet/SortedNumeric storage for the few 
unique sets use-case
 Key: LUCENE-6668
 URL: https://issues.apache.org/jira/browse/LUCENE-6668
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor


Robert suggested this idea: if there are few unique sets of values, we could 
build a lookup table and then map each doc to an ord in this table, just like 
we already do for table compression for numerics.

I think this is especially compelling given that SortedSet/SortedNumeric are 
our two only doc values types that use O(maxDoc) memory because of the offsets 
map. When this new strategy is used, memory usage could be bounded to a 
constant.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7764) Solr indexing hangs if encounters an certain XML parse error

2015-07-09 Thread Tim Allison (JIRA)

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

Tim Allison commented on SOLR-7764:
---

1) Right. That's the problem with how Tika is currently being used within DIH.
If it hangs, you'll never get an exception. If the xlsx file is causing the
hang and given the vintage of Tika you're using, it might be a custom fraction
format (TIKA-1132)???

2) ummm...the pdcidfont issue sounds like a pdf problem, not an Excel problem.
Does the excel file have an embedded PDF? Will send email privately.

3) I can't quite tell what behavior you'd like. Please give more info.

Solr indexing hangs if encounters an certain XML parse error

Key: SOLR-7764
URL: https://issues.apache.org/jira/browse/SOLR-7764
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 4.7.2
Environment: Ubuntu 12.04.5 LTS
Reporter: Sorin Gheorghiu
Labels: indexing
Attachments: Solr_XML_parse_error_080715.txt

BlueSpice (http://bluespice.com/) uses Solr to index documents for the
'Extended search' feature.
Solr hangs if during indexing certain error occurs:
8.7.2015 15:34:26
ERROR
SolrCore
org.apache.solr.common.SolrException:
org.apache.tika.exception.TikaException: XML parse error
8.7.2015 15:34:26
ERROR
SolrDispatchFilter
null:org.apache.solr.common.SolrException:
org.apache.tika.exception.TikaException: XML parse error

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr pull request: Lucene solr 5 2

2015-07-09 Thread aniketkhare

GitHub user aniketkhare opened a pull request:

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

Lucene solr 5 2



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

$ git pull https://github.com/apache/lucene-solr lucene_solr_5_2

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

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

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

This closes #187


commit ffa9b51da56221caddb8e012c83931308f4de128
Author: shalin Shekhar Mangar sha...@apache.org
Date:   2015-04-20T04:44:57Z

SOLR-7421: RecoveryAfterSoftCommitTest fails frequently on Jenkins due to 
full index replication taking longer than 30 seconds

git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x@1674734 
13f79535-47bb-0310-9956-ffa450edef68

commit 131efa13445b3420e450a232866ee2196c7854e8
Author: Steven Rowe sar...@apache.org
Date:   2015-04-20T14:27:43Z

SOLR-7419: document intentional overflow in SolrQueryTimeoutImpl thread 
local (merged trunk r1674866)

git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x@1674867 
13f79535-47bb-0310-9956-ffa450edef68

commit 50aba5f845083bb6616f0f0a166a60827d14526a
Author: Robert Muir rm...@apache.org
Date:   2015-04-20T15:06:27Z

LUCENE-6440: Show LuceneTestCase LiveIndexWriterConfig changes with deltas

git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x@1674914 
13f79535-47bb-0310-9956-ffa450edef68

commit bbcb8b247c650083e199c4a66b8465c0980bd378
Author: Uwe Schindler uschind...@apache.org
Date:   2015-04-20T15:35:05Z

Merged revision(s) 1674926 from lucene/dev/trunk:
LUCENE-6420: Use forbidden-apis annotation @SuppressForbidden; cleanup 
maven build

git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x@1674931 
13f79535-47bb-0310-9956-ffa450edef68

commit a3ed1dc9810aaef983ae1047ed678d37e27dd25d
Author: Uwe Schindler uschind...@apache.org
Date:   2015-04-20T16:27:46Z

Merged revision(s) 1674939 from lucene/dev/trunk:
LUCENE-6420: Add missing suppressAnnotation declaration on forbiddenapis 
ANT task in test-frameworks

git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x@1674941 
13f79535-47bb-0310-9956-ffa450edef68

commit 6393c4e7a02d63c1bd2c3aabeb27e173b949aa7a
Author: Robert Muir rm...@apache.org
Date:   2015-04-20T17:46:46Z

LUCENE-6439: Create test-framework/src/test

git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x@1674948 
13f79535-47bb-0310-9956-ffa450edef68

commit 364c6ba2030b558029f8fa3629f5ef5560810572
Author: Uwe Schindler uschind...@apache.org
Date:   2015-04-20T21:34:32Z

Merged revision(s) 1674990 from lucene/dev/trunk:
LUCENE-6439: enable support fors test-framework-tests on Maven build

git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x@1674991 
13f79535-47bb-0310-9956-ffa450edef68

commit 040bfd7fd70689d3f3addfee8fb2ace4986f08f0
Author: Mark Robert Miller markrmil...@apache.org
Date:   2015-04-20T22:40:45Z

SOLR-7429: Remove Solr server module sync-hack introduced in SOLR-4050.

git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x@1674998 
13f79535-47bb-0310-9956-ffa450edef68

commit 551eee0dd76b1c2f46e1ee0a94e87c38f107c894
Author: shalin Shekhar Mangar sha...@apache.org
Date:   2015-04-21T05:29:53Z

SOLR-7429: Switch to standard servlet-api instead of orbit to get 5x build 
working

git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x@1675028 
13f79535-47bb-0310-9956-ffa450edef68

commit 590ab978a4ae62be65d4ca3b241f97cc745d2997
Author: shalin Shekhar Mangar sha...@apache.org
Date:   2015-04-21T05:55:00Z

SOLR-6665: ZkController.publishAndWaitForDownStates can return before all 
local cores are marked as 'down' if multiple replicas with the same core name 
exist in the cluster

git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x@1675033 
13f79535-47bb-0310-9956-ffa450edef68

commit 8004a38fd7ea77d8a1589c4e661e72de86561f30
Author: Shai Erera sh...@apache.org
Date:   2015-04-21T07:38:39Z

LUCENE-6441: Change default formatting settings to break lines at 120 
characters

git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x@1675057 
13f79535-47bb-0310-9956-ffa450edef68

commit ad789b81a311449a57f6f2aa7234063400ea7a7e
Author: shalin Shekhar Mangar sha...@apache.org
Date:   2015-04-21T09:04:49Z

SOLR-6665: Add AwaitsFix annotation to the new test

git-svn-id: 
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_5x@1675068 
13f79535-47bb-0310-9956-ffa450edef68

commit e0a71c56f42941df71eeb0c95c712508f6b099c2
Author: Robert Muir rm...@apache.org
Date:   2015-04-21T11:40:42Z

Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build # 13198 - Still Failing!

2015-07-09 Thread Balchandra Vaidya


Hi Uwe,

Here is the JBS id: https://bugs.openjdk.java.net/browse/JDK-8130845

Thank you for submitting the bug.

Regards
Balchandra


On 7/9/2015 3:01 PM, Uwe Schindler wrote:

Hi,

I opened Report (Review ID: JI-9022158) - Change to CLDR Locale data in JDK 9 
b71 causes SimpleDateFormat parsing errors

Uwe

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



-Original Message-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Thursday, July 09, 2015 11:01 AM
To: dev@lucene.apache.org
Cc: rory.odonn...@oracle.com; 'Dalibor Topic'; 'Balchandra Vaidya'
Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build #
13198 - Still Failing!

Hi,

I debugged the date parsing problems with a new test (TestDateUtil in solrj).

The reason for this failing is the following 2 things, but they are related (if 
not
even the same bug):
- https://bugs.openjdk.java.net/browse/JDK-8129881 is triggered: TIKA uses
Date#toString() which inserts a broken timezone shortcut into the resulting
date. This cannot be parsed anymore! This happens all the timein ROOT
Locale (see below).
- Solr uses Locale.ROOT to parse the date (of course, because it's language
independent). This locale is missing all text representations of weekdays or
timezones in OpenJDK's CLDR locale data, so it cannot parse the weekday or
the time zones. If I change DateUtil to use Locale.ENGLISH, it works as
expected.

I will open a bug report at Oracle.

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



-Original Message-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Thursday, July 09, 2015 12:47 AM
To: dev@lucene.apache.org
Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build

#

13198 - Still Failing!

Could be something like this bug:
https://bugs.openjdk.java.net/browse/JDK-8129881

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



-Original Message-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Thursday, July 09, 2015 12:40 AM
To: dev@lucene.apache.org
Cc: rory.odonn...@oracle.com
Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -

Build

#

13198 - Still Failing!

The test passes on JDK 9 b71 with:
-Dargs=-Djava.locale.providers=JRE,SPI

This reenabled the old Locale data. I will add this to the build parameters

of

policeman Jenkins to stop this from failing. To me it looks like the locale

data

somehow is not able to correctly parse weekdays and/or timezones. I will
check this out tomorrow and report a bug to the OpenJDK people. There

is

something fishy with CLDR locale data. There are already some bugs

open,

so

work is not yet finished (e.g. sometimes it uses wrong timezone

shortcuts,...)

Uwe

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



-Original Message-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Thursday, July 09, 2015 12:16 AM
To: dev@lucene.apache.org
Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -

Build

#

13198 - Still Failing!

Hi,

It is exactly like that. The contenthandler tries to parse all metadata

strings

as

date using DateUtil.parseDate() and if that fails, it leaves them

unchanged.

In

JDK 8 it succeeds to parse the date and then converts it to ISO-8601 Solr
format. With JDK 9 b71 it passes the plain string in the TIKA format (it

uses

HTTP Cookie-like dates in TIKA), which then fails in TrieDateField.

Unfortunately, I was not able to setup Eclipse with JDK 9, so I cannot

debug

this. I just did this is JDK 8 to verify how it works...

We should add a testcase for DateUtil and then try to find out how this

fails

in

JDK 9. It looks like this class is completely untested with strange date
formats.
Uwe

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



-Original Message-
From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
Sent: Wednesday, July 08, 2015 11:46 PM
To: dev@lucene.apache.org
Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -

Build

#

13198 - Still Failing!


My guess (haven't verified) is that if you dig into the
ExtractionRequestHandler code, you will probably find it parsing Tika
Metadata Strings (All Tika metadata are simple Strings, correct?) into
Date objects if/when it can/should based on the field type -- and

when

it

can't it propogates the metadata string as is (so that, for example, a
subsequent update processor can parse it)

The error from TrieDateField is probably just because a completely
untouched metadta string (coming from Tika) is not a Date (or a

correctly

ISO formatted string) ... leaving the big question being: what changed

in

the JDK such that that tika metadta is no longer being parsed properly
into a Date in the first

[jira] [Commented] (LUCENE-6660) Assertion fails for ToParentBlockJoinQuery$BlockJoinScorer.nextDoc

2015-07-09 Thread Mikhail Khludnev (JIRA)


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

Mikhail Khludnev commented on LUCENE-6660:
--

got it. It's worth put it as:
bq. when user supplies a wrong parent filter ie. it doesn't match the last doc 
in a segment (ignoring acceptedDocs), BJS should throw exception suggestion to 
verify the filter.

I bake the patch with test coverage soon. [~cdanningerCV] thanks for raising 
it, I didn't realize this trap. 


 Assertion fails for ToParentBlockJoinQuery$BlockJoinScorer.nextDoc
 --

 Key: LUCENE-6660
 URL: https://issues.apache.org/jira/browse/LUCENE-6660
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
Affects Versions: 5.2.1
 Environment: Running Solr 5.2.1 on Windows x64
 java version 1.7.0_51
 Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
 Java HotSpot(TM) Client VM (build 24.51-b03, mixed mode, sharing)
Reporter: Christian Danninger
 Attachments: index.zip


 After I enable assertion with -ea:org.apache... I got the stack trace 
 below. I checked that the parent filter only match parent documents and the 
 child filter only match child documents. Field id is unique.
 16:55:06,269 ERROR [org.apache.solr.servlet.SolrDispatchFilter] 
 (http-127.0.0.1/127.0.0.1:8080-1) null:java.lang.RuntimeException: 
 java.lang.AssertionError
   at org.apache.solr.servlet.HttpSolrCall.sendError(HttpSolrCall.java:593)
   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:465)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
   at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
   at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
   at 
 org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
   at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
   at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
   at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:559)
   at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
   at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336)
   at 
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
   at 
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
   at 
 org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920)
   at java.lang.Thread.run(Thread.java:744)
 Caused by: java.lang.AssertionError
   at 
 org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.nextDoc(ToParentBlockJoinQuery.java:278)
   at 
 org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:204)
   at 
 org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:176)
   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:771)
   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:485)
   at 
 org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:202)
   at 
 org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1666)
   at 
 org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1485)
   at 
 org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561)
   at 
 org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:518)
   at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
   ... 16 more
 Without assertions enabled:
 17:21:39,008 ERROR [org.apache.solr.servlet.SolrDispatchFilter] 
 (http-127.0.0.1/127.0.0.1:8080-1) null:java.lang.IllegalStateException: child 
 query must only match non-parent docs, but parent docID=2147483647 matched 
 childScorer=class

[jira] [Commented] (SOLR-7764) Solr indexing hangs if encounters an certain XML parse error

2015-07-09 Thread Sorin Gheorghiu (JIRA)


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

Sorin Gheorghiu commented on SOLR-7764:
---

After more test it results this is not a Tika or XML related issue and the 
stacktrace is NOT related to the hang.

1) I removed the XLSX file from the index list (actually I delete it temporary 
on Mediawiki) the Tika error occured and the index didn't hung at this place. 
It seems no error is reported when it hangs permanently on this file (!).

2) A second XLSX file will hang but this time with the following error:

ERROR
PDCIDFont
Error: Could not parse predefined CMAP file for 'é.5s¢-á.?null³!null¯-UCS2'

Thus after I remove both files, the index will end successfully.

As you guessed the information of the files is private, I am allowed to share, 
but not post them. 
Could you provide an email address to send them directly to you, pls?

This issue is related to the newer Solr version, the same files were properly 
indexed before the upgrade 4.5.0 - 4.7.2

3) It is worth to mention another difference between the versions. 
For long time ago, the docx, xlsx files were not migrated with proper Type 
Content, and they were recognized as ZIP files (that's fine)

in 4.5.0 ExtendedSearch.log reports:
3940: Indexiere hochgeladene Dateien: 8% - Filetype not allowed: zip 
(AtyponJR1_2011.xlsx)

while in 4.7.2 ExtendedSearchIndex.log (different log name) same file is no 
longer recognized as a ZIP archive but it should be, the files are identical.
4117: Indexiere hochgeladene Dateien: 9% - AtyponJR1_2011.xlsx


 Solr indexing hangs if encounters an certain XML parse error
 

 Key: SOLR-7764
 URL: https://issues.apache.org/jira/browse/SOLR-7764
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.7.2
 Environment: Ubuntu 12.04.5 LTS
Reporter: Sorin Gheorghiu
  Labels: indexing
 Attachments: Solr_XML_parse_error_080715.txt


 BlueSpice (http://bluespice.com/) uses Solr to index documents for the 
 'Extended search' feature.
 Solr hangs if during indexing certain error occurs:
 8.7.2015 15:34:26
 ERROR
 SolrCore
 org.apache.solr.common.SolrException: 
 org.apache.tika.exception.TikaException: XML parse error
 8.7.2015 15:34:26
 ERROR
 SolrDispatchFilter
 null:org.apache.solr.common.SolrException: 
 org.apache.tika.exception.TikaException: XML parse error



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6668) Optimize SortedSet/SortedNumeric storage for the few unique sets use-case


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

Adrien Grand updated LUCENE-6668:
-
Attachment: LUCENE-6668.patch

Here is a patch: it uses table encoding for SortedSet/SortedNumeric if the sum 
of the sizes of all unique sets is 256 or less. If my math is correct, this 
means it will always be used if there are 6 unique values or less (given that 
the sum of the sizes of all possible subsets would be 192), and might be used 
if the number of unique values is between 7 and 256.

 Optimize SortedSet/SortedNumeric storage for the few unique sets use-case
 -

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


 Robert suggested this idea: if there are few unique sets of values, we could 
 build a lookup table and then map each doc to an ord in this table, just like 
 we already do for table compression for numerics.
 I think this is especially compelling given that SortedSet/SortedNumeric are 
 our two only doc values types that use O(maxDoc) memory because of the 
 offsets map. When this new strategy is used, memory usage could be bounded to 
 a constant.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-7764) Solr indexing hangs if encounters an certain XML parse error

2015-07-09 Thread Tim Allison (JIRA)

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

Tim Allison edited comment on SOLR-7764 at 7/9/15 12:41 PM:

2) ummm...the pdcidfont issue sounds like a pdf problem, not an Excel problem.
Does the excel file have an embedded PDF? Will send email privately.

3) I can't quite tell what behavior you'd like. Please give more info.

As a side note, for debugging purposes, you might try grabbing the relevant
version of tika-app, and dropping potential problem files into that. If it
hangs, you've found your problem.

Another option is to run tika-app ( = 1.8) in batch mode against an input
directory. If your logging is set up correctly, you'll be able to tell which
file caused the hang. The commandline for that is: java -jar tika-app-xx.jar
-i inputdir -o outputdir, but see the tika-batch
[wiki|http://wiki.apache.org/tika/TikaBatchUsage] for advanced usage on
configuring logging. (well see it in about 10 minutes after I update it. ;) )

was (Author: talli...@mitre.org):
1) Right. That's the problem with how Tika is currently being used within DIH.
If it hangs, you'll never get an exception. If the xlsx file is causing the
hang and given the vintage of Tika you're using, it might be a custom fraction
format (TIKA-1132)???

2) ummm...the pdcidfont issue sounds like a pdf problem, not an Excel problem.
Does the excel file have an embedded PDF? Will send email privately.

3) I can't quite tell what behavior you'd like. Please give more info.

Solr indexing hangs if encounters an certain XML parse error

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6645) BKD tree queries should use BitDocIdSet.Builder


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

Michael McCandless commented on LUCENE-6645:


Thanks [~jpountz]!

 BKD tree queries should use BitDocIdSet.Builder
 ---

 Key: LUCENE-6645
 URL: https://issues.apache.org/jira/browse/LUCENE-6645
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
 Attachments: LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch, 
 LUCENE-6645.patch


 When I was iterating on BKD tree originally I remember trying to use this 
 builder (which makes a sparse bit set at first and then upgrades to dense if 
 enough bits get set) and being disappointed with its performance.
 I wound up just making a FixedBitSet every time, but this is obviously 
 wasteful for small queries.
 It could be the perf was poor because I was always .or'ing in DISIs that had 
 512 - 1024 hits each time (the size of each leaf cell in the BKD tree)?  I 
 also had to make my own DISI wrapper around each leaf cell... maybe that was 
 the source of the slowness, not sure.
 I also sort of wondered whether the SmallDocSet in spatial module (backed by 
 a SentinelIntSet) might be faster ... though it'd need to be sorted in the 
 and after building before returning to Lucene.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6645) BKD tree queries should use BitDocIdSet.Builder

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

Michael McCandless updated LUCENE-6645:
---
Attachment: LUCENE-6645.patch

I think with this small change to the builder, we can save one if check in the
add method.

In the BKD test this gives a good gain ... from 3.08 sec in trunk down to 2.32
sec ...

BKD tree queries should use BitDocIdSet.Builder
---

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

RE: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_45) - Build # 13386 - Failure!

Fixed already!

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


 -Original Message-
 From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
 Sent: Thursday, July 09, 2015 11:51 AM
 To: u...@thetaphi.de; jpou...@apache.org; dev@lucene.apache.org
 Subject: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_45) - Build #
 13386 - Failure!
 
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13386/
 Java: 64bit/jdk1.8.0_45 -XX:+UseCompressedOops -XX:+UseParallelGC
 
 1 tests failed.
 FAILED:  org.apache.solr.common.util.TestDateUtil.testCurrentTime
 
 Error Message:
 Incorrect parsed timestamp
 
 Stack Trace:
 java.lang.AssertionError: Incorrect parsed timestamp
   at
 __randomizedtesting.SeedInfo.seed([932EEB7F8C1F9CCA:18BB4A010FC12A9
 ]:0)
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.assertTrue(Assert.java:43)
   at
 org.apache.solr.common.util.TestDateUtil.assertParsedDate(TestDateUtil.jav
 a:38)
   at
 org.apache.solr.common.util.TestDateUtil.testCurrentTime(TestDateUtil.java
 :29)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
 ava:62)
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
 sorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:497)
   at
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize
 dRunner.java:1627)
   at
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando
 mizedRunner.java:836)
   at
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando
 mizedRunner.java:872)
   at
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
 mizedRunner.java:886)
   at
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule
 SetupTeardownChained.java:50)
   at
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
 fterRule.java:46)
   at
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh
 readAndTestName.java:49)
   at
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule
 IgnoreAfterMaxFailures.java:65)
   at
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure
 .java:48)
   at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
 ementAdapter.java:36)
   at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.
 run(ThreadLeakControl.java:365)
   at
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask
 (ThreadLeakControl.java:798)
   at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL
 eakControl.java:458)
   at
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran
 domizedRunner.java:845)
   at
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(Rando
 mizedRunner.java:747)
   at
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(Rando
 mizedRunner.java:781)
   at
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando
 mizedRunner.java:792)
   at
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
 fterRule.java:46)
   at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
 ementAdapter.java:36)
   at
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCl
 assName.java:42)
   at
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet
 hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
   at
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet
 hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
   at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
 ementAdapter.java:36)
   at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
 ementAdapter.java:36)
   at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
 ementAdapter.java:36)
   at
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAss
 ertionsRequired.java:54)
   at
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure
 .java:48)
   at
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule
 IgnoreAfterMaxFailures.java:65)
   at
 org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnore
 TestSuites.java:55)
   at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
 ementAdapter.java:36)
   at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.
 run(ThreadLeakControl.java:365)
   at java.lang.Thread.run(Thread.java:745)
 
 
 
 
 Build Log:
 [...truncated 11634 lines...]
[junit4] Suite: org.apache.solr.common.util.TestDateUtil
[junit4]   1

RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build # 13198 - Still Failing!

2015-07-09 Thread ASF subversion and git services (JIRA)

Hi,

I opened Report (Review ID: JI-9022158) - Change to CLDR Locale data in JDK 9 
b71 causes SimpleDateFormat parsing errors

Uwe

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


 -Original Message-
 From: Uwe Schindler [mailto:u...@thetaphi.de]
 Sent: Thursday, July 09, 2015 11:01 AM
 To: dev@lucene.apache.org
 Cc: rory.odonn...@oracle.com; 'Dalibor Topic'; 'Balchandra Vaidya'
 Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build #
 13198 - Still Failing!
 
 Hi,
 
 I debugged the date parsing problems with a new test (TestDateUtil in solrj).
 
 The reason for this failing is the following 2 things, but they are related 
 (if not
 even the same bug):
 - https://bugs.openjdk.java.net/browse/JDK-8129881 is triggered: TIKA uses
 Date#toString() which inserts a broken timezone shortcut into the resulting
 date. This cannot be parsed anymore! This happens all the timein ROOT
 Locale (see below).
 - Solr uses Locale.ROOT to parse the date (of course, because it's language
 independent). This locale is missing all text representations of weekdays or
 timezones in OpenJDK's CLDR locale data, so it cannot parse the weekday or
 the time zones. If I change DateUtil to use Locale.ENGLISH, it works as
 expected.
 
 I will open a bug report at Oracle.
 
 -
 Uwe Schindler
 H.-H.-Meier-Allee 63, D-28213 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de
 
 
  -Original Message-
  From: Uwe Schindler [mailto:u...@thetaphi.de]
  Sent: Thursday, July 09, 2015 12:47 AM
  To: dev@lucene.apache.org
  Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build
 #
  13198 - Still Failing!
 
  Could be something like this bug:
  https://bugs.openjdk.java.net/browse/JDK-8129881
 
  -
  Uwe Schindler
  H.-H.-Meier-Allee 63, D-28213 Bremen
  http://www.thetaphi.de
  eMail: u...@thetaphi.de
 
 
   -Original Message-
   From: Uwe Schindler [mailto:u...@thetaphi.de]
   Sent: Thursday, July 09, 2015 12:40 AM
   To: dev@lucene.apache.org
   Cc: rory.odonn...@oracle.com
   Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -
 Build
  #
   13198 - Still Failing!
  
   The test passes on JDK 9 b71 with:
   -Dargs=-Djava.locale.providers=JRE,SPI
  
   This reenabled the old Locale data. I will add this to the build 
   parameters
 of
   policeman Jenkins to stop this from failing. To me it looks like the 
   locale
  data
   somehow is not able to correctly parse weekdays and/or timezones. I will
   check this out tomorrow and report a bug to the OpenJDK people. There
 is
   something fishy with CLDR locale data. There are already some bugs
 open,
  so
   work is not yet finished (e.g. sometimes it uses wrong timezone
  shortcuts,...)
  
   Uwe
  
   -
   Uwe Schindler
   H.-H.-Meier-Allee 63, D-28213 Bremen
   http://www.thetaphi.de
   eMail: u...@thetaphi.de
  
  
-Original Message-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Thursday, July 09, 2015 12:16 AM
To: dev@lucene.apache.org
Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -
  Build
   #
13198 - Still Failing!
   
Hi,
   
It is exactly like that. The contenthandler tries to parse all metadata
  strings
   as
date using DateUtil.parseDate() and if that fails, it leaves them
  unchanged.
   In
JDK 8 it succeeds to parse the date and then converts it to ISO-8601 
Solr
format. With JDK 9 b71 it passes the plain string in the TIKA format (it
 uses
HTTP Cookie-like dates in TIKA), which then fails in TrieDateField.
   
Unfortunately, I was not able to setup Eclipse with JDK 9, so I cannot
  debug
this. I just did this is JDK 8 to verify how it works...
   
We should add a testcase for DateUtil and then try to find out how this
  fails
   in
JDK 9. It looks like this class is completely untested with strange 
date
formats.
Uwe
   
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
   
   
 -Original Message-
 From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
 Sent: Wednesday, July 08, 2015 11:46 PM
 To: dev@lucene.apache.org
 Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -
   Build
#
 13198 - Still Failing!


 My guess (haven't verified) is that if you dig into the
 ExtractionRequestHandler code, you will probably find it parsing Tika
 Metadata Strings (All Tika metadata are simple Strings, correct?) into
 Date objects if/when it can/should based on the field type -- and
 when
  it
 can't it propogates the metadata string as is (so that, for example, a
 subsequent update processor can parse it)

 The error from TrieDateField is probably just because a completely
 untouched metadta string (coming from Tika) is not a Date (or a
  correctly

Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build # 13198 - Still Failing!

2015-07-09 Thread Rory O'Donnell


Thanks Uwe, let me know the incident-id.

Rgds,Rory

On 09/07/2015 10:01, Uwe Schindler wrote:

Hi,

I debugged the date parsing problems with a new test (TestDateUtil in solrj).

The reason for this failing is the following 2 things, but they are related (if 
not even the same bug):
- https://bugs.openjdk.java.net/browse/JDK-8129881 is triggered: TIKA uses 
Date#toString() which inserts a broken timezone shortcut into the resulting 
date. This cannot be parsed anymore! This happens all the timein ROOT Locale 
(see below).
- Solr uses Locale.ROOT to parse the date (of course, because it's language 
independent). This locale is missing all text representations of weekdays or 
timezones in OpenJDK's CLDR locale data, so it cannot parse the weekday or the 
time zones. If I change DateUtil to use Locale.ENGLISH, it works as expected.

I will open a bug report at Oracle.

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



-Original Message-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Thursday, July 09, 2015 12:47 AM
To: dev@lucene.apache.org
Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build #
13198 - Still Failing!

Could be something like this bug:
https://bugs.openjdk.java.net/browse/JDK-8129881

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



-Original Message-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Thursday, July 09, 2015 12:40 AM
To: dev@lucene.apache.org
Cc: rory.odonn...@oracle.com
Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build

#

13198 - Still Failing!

The test passes on JDK 9 b71 with:
-Dargs=-Djava.locale.providers=JRE,SPI

This reenabled the old Locale data. I will add this to the build parameters of
policeman Jenkins to stop this from failing. To me it looks like the locale

data

somehow is not able to correctly parse weekdays and/or timezones. I will
check this out tomorrow and report a bug to the OpenJDK people. There is
something fishy with CLDR locale data. There are already some bugs open,

so

work is not yet finished (e.g. sometimes it uses wrong timezone

shortcuts,...)

Uwe

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



-Original Message-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Thursday, July 09, 2015 12:16 AM
To: dev@lucene.apache.org
Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -

Build

#

13198 - Still Failing!

Hi,

It is exactly like that. The contenthandler tries to parse all metadata

strings

as

date using DateUtil.parseDate() and if that fails, it leaves them

unchanged.

In

JDK 8 it succeeds to parse the date and then converts it to ISO-8601 Solr
format. With JDK 9 b71 it passes the plain string in the TIKA format (it uses
HTTP Cookie-like dates in TIKA), which then fails in TrieDateField.

Unfortunately, I was not able to setup Eclipse with JDK 9, so I cannot

debug

this. I just did this is JDK 8 to verify how it works...

We should add a testcase for DateUtil and then try to find out how this

fails

in

JDK 9. It looks like this class is completely untested with strange date
formats.
Uwe

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



-Original Message-
From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
Sent: Wednesday, July 08, 2015 11:46 PM
To: dev@lucene.apache.org
Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -

Build

#

13198 - Still Failing!


My guess (haven't verified) is that if you dig into the
ExtractionRequestHandler code, you will probably find it parsing Tika
Metadata Strings (All Tika metadata are simple Strings, correct?) into
Date objects if/when it can/should based on the field type -- and when

it

can't it propogates the metadata string as is (so that, for example, a
subsequent update processor can parse it)

The error from TrieDateField is probably just because a completely
untouched metadta string (coming from Tika) is not a Date (or a

correctly

ISO formatted string) ... leaving the big question being: what changed in
the JDK such that that tika metadta is no longer being parsed properly
into a Date in the first place?

(NOTE: I'm speculating in all of this based on what little i remember
about Tika)


: Date: Wed, 8 Jul 2015 23:35:52 +0200
: From: Uwe Schindler u...@thetaphi.de
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -

Build

#
:  13198 - Still Failing!
:
: In fact this is really strange! The Exception is thrown because the
DateMathParser does not find the Z inside the date string - it just
complains that its not ISO8601... To me it looks like although it should

only

get

ISO8601 date, somehow extracting contenthandler sends a default

[jira] [Commented] (LUCENE-6645) BKD tree queries should use BitDocIdSet.Builder


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

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

Commit 1690041 from [~jpountz] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1690041 ]

LUCENE-6645: Optimized DocIdSet building for the many small postings lists 
case.

 BKD tree queries should use BitDocIdSet.Builder
 ---

 Key: LUCENE-6645
 URL: https://issues.apache.org/jira/browse/LUCENE-6645
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
 Attachments: LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch, 
 LUCENE-6645.patch


 When I was iterating on BKD tree originally I remember trying to use this 
 builder (which makes a sparse bit set at first and then upgrades to dense if 
 enough bits get set) and being disappointed with its performance.
 I wound up just making a FixedBitSet every time, but this is obviously 
 wasteful for small queries.
 It could be the perf was poor because I was always .or'ing in DISIs that had 
 512 - 1024 hits each time (the size of each leaf cell in the BKD tree)?  I 
 also had to make my own DISI wrapper around each leaf cell... maybe that was 
 the source of the slowness, not sure.
 I also sort of wondered whether the SmallDocSet in spatial module (backed by 
 a SentinelIntSet) might be faster ... though it'd need to be sorted in the 
 and after building before returning to Lucene.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build # 13198 - Still Failing!

I think the real issue here is the following (Rory can you add this to issue?):

According to Unicode, all locales should fall back to the ROOT locale, if the 
specific Locale does not have data (e.g., 
http://cldr.unicode.org/development/development-process/design-proposals/generic-calendar-data).
 The problem is now that the CLDR Java implementation seems to fall back to the 
root locale, but the root locale does not have weekdays and time zone short 
names - our test verifies this: ROOT locale is missing all this information.

This causes all the bugs, also the one in 
https://bugs.openjdk.java.net/browse/JDK-8129881. The root locale should have 
the default English weekday and timezone names (see 
http://cldr.unicode.org/development/development-process/design-proposals/generic-calendar-data).

I think the ROOT locale and the fallback mechanism should be revisited in JDK's 
CLDR impl, there seems to be a bug with that (either missing data or the 
fallback to defaults does not work correctly).

Uwe

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


 -Original Message-
 From: Uwe Schindler [mailto:u...@thetaphi.de]
 Sent: Thursday, July 09, 2015 11:32 AM
 To: dev@lucene.apache.org
 Cc: rory.odonn...@oracle.com; 'Dalibor Topic'; 'Balchandra Vaidya'
 Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build #
 13198 - Still Failing!
 
 Hi,
 
 I opened Report (Review ID: JI-9022158) - Change to CLDR Locale data in JDK
 9 b71 causes SimpleDateFormat parsing errors
 
 Uwe
 
 -
 Uwe Schindler
 H.-H.-Meier-Allee 63, D-28213 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de
 
 
  -Original Message-
  From: Uwe Schindler [mailto:u...@thetaphi.de]
  Sent: Thursday, July 09, 2015 11:01 AM
  To: dev@lucene.apache.org
  Cc: rory.odonn...@oracle.com; 'Dalibor Topic'; 'Balchandra Vaidya'
  Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) - Build
 #
  13198 - Still Failing!
 
  Hi,
 
  I debugged the date parsing problems with a new test (TestDateUtil in
 solrj).
 
  The reason for this failing is the following 2 things, but they are related 
  (if
 not
  even the same bug):
  - https://bugs.openjdk.java.net/browse/JDK-8129881 is triggered: TIKA
 uses
  Date#toString() which inserts a broken timezone shortcut into the resulting
  date. This cannot be parsed anymore! This happens all the timein ROOT
  Locale (see below).
  - Solr uses Locale.ROOT to parse the date (of course, because it's language
  independent). This locale is missing all text representations of weekdays or
  timezones in OpenJDK's CLDR locale data, so it cannot parse the weekday
 or
  the time zones. If I change DateUtil to use Locale.ENGLISH, it works as
  expected.
 
  I will open a bug report at Oracle.
 
  -
  Uwe Schindler
  H.-H.-Meier-Allee 63, D-28213 Bremen
  http://www.thetaphi.de
  eMail: u...@thetaphi.de
 
 
   -Original Message-
   From: Uwe Schindler [mailto:u...@thetaphi.de]
   Sent: Thursday, July 09, 2015 12:47 AM
   To: dev@lucene.apache.org
   Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -
 Build
  #
   13198 - Still Failing!
  
   Could be something like this bug:
   https://bugs.openjdk.java.net/browse/JDK-8129881
  
   -
   Uwe Schindler
   H.-H.-Meier-Allee 63, D-28213 Bremen
   http://www.thetaphi.de
   eMail: u...@thetaphi.de
  
  
-Original Message-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Thursday, July 09, 2015 12:40 AM
To: dev@lucene.apache.org
Cc: rory.odonn...@oracle.com
Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -
  Build
   #
13198 - Still Failing!
   
The test passes on JDK 9 b71 with:
-Dargs=-Djava.locale.providers=JRE,SPI
   
This reenabled the old Locale data. I will add this to the build
 parameters
  of
policeman Jenkins to stop this from failing. To me it looks like the 
locale
   data
somehow is not able to correctly parse weekdays and/or timezones. I
 will
check this out tomorrow and report a bug to the OpenJDK people.
 There
  is
something fishy with CLDR locale data. There are already some bugs
  open,
   so
work is not yet finished (e.g. sometimes it uses wrong timezone
   shortcuts,...)
   
Uwe
   
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
   
   
 -Original Message-
 From: Uwe Schindler [mailto:u...@thetaphi.de]
 Sent: Thursday, July 09, 2015 12:16 AM
 To: dev@lucene.apache.org
 Subject: RE: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b71) -
   Build
#
 13198 - Still Failing!

 Hi,

 It is exactly like that. The contenthandler tries to parse all 
 metadata
   strings
as
 date using DateUtil.parseDate() and if that fails, it leaves them
   unchanged.
In
 JDK 8 it succeeds to parse

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_45) - Build # 13386 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13386/
Java: 64bit/jdk1.8.0_45 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.common.util.TestDateUtil.testCurrentTime

Error Message:
Incorrect parsed timestamp

Stack Trace:
java.lang.AssertionError: Incorrect parsed timestamp
at 
__randomizedtesting.SeedInfo.seed([932EEB7F8C1F9CCA:18BB4A010FC12A9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.util.TestDateUtil.assertParsedDate(TestDateUtil.java:38)
at 
org.apache.solr.common.util.TestDateUtil.testCurrentTime(TestDateUtil.java:29)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11634 lines...]
   [junit4] Suite: org.apache.solr.common.util.TestDateUtil
   [junit4]   1 1226583351000
   [junit4]   1 1436392177000
   [junit4]   2 NOTE: reproduce with: ant test  -Dtestcase=TestDateUtil 
-Dtests.method=testCurrentTime -Dtests.seed=932EEB7F8C1F9CCA 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=pt 
-Dtests.timezone=Europe/Riga -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 0.02s J0 | TestDateUtil.testCurrentTime 
   [junit4] Throwable #1: java.lang.AssertionError: Incorrect parsed 
timestamp

[jira] [Commented] (SOLR-7766) support creation of a coreless collection

2015-07-09 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on SOLR-7766:
--

GitHub user cpoerschke opened a pull request:

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

SOLR-7766: support creation of a coreless collection

for https://issues.apache.org/jira/i#browse/SOLR-7766

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

$ git pull https://github.com/bloomberg/lucene-solr 
trunk-create-coreless-collection

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

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

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

This closes #186


commit 74d2d93b24dcb4e8aa4f72a386b2a1f02abd7aa9
Author: Christine Poerschke cpoersc...@bloomberg.net
Date:   2015-04-02T16:22:04Z

SOLR-: support creation of a coreless collection

By supplying a deliberately empty create node set (via 
.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...) 
the collection can be created in the usual manner but it will just not yet 
contain any cores for any of its shards. Later on 
.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...
 calls can create cores as and when and where required.

The change to suppport this small new feature is in 
OverseerCollectionProcessor.java and in TestMiniSolrCloudCluster a new test 
case (testCollectionCreateWithoutCoresThenDelete) was added.




 support creation of a coreless collection
 -

 Key: SOLR-7766
 URL: https://issues.apache.org/jira/browse/SOLR-7766
 Project: Solr
  Issue Type: New Feature
Reporter: Christine Poerschke
Priority: Minor

 By supplying a deliberately empty create node set (via 
 {{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
  the collection can be created in the usual manner but it will just not yet 
 contain any cores for any of its shards. Later on 
 {{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
  calls can create cores as and when and where required.
 github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr pull request: SOLR-7766: support creation of a coreles...

2015-07-09 Thread cpoerschke

GitHub user cpoerschke opened a pull request:

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

SOLR-7766: support creation of a coreless collection

for https://issues.apache.org/jira/i#browse/SOLR-7766

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

$ git pull https://github.com/bloomberg/lucene-solr 
trunk-create-coreless-collection

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

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

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

This closes #186


commit 74d2d93b24dcb4e8aa4f72a386b2a1f02abd7aa9
Author: Christine Poerschke cpoersc...@bloomberg.net
Date:   2015-04-02T16:22:04Z

SOLR-: support creation of a coreless collection

By supplying a deliberately empty create node set (via 
.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...) 
the collection can be created in the usual manner but it will just not yet 
contain any cores for any of its shards. Later on 
.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...
 calls can create cores as and when and where required.

The change to suppport this small new feature is in 
OverseerCollectionProcessor.java and in TestMiniSolrCloudCluster a new test 
case (testCollectionCreateWithoutCoresThenDelete) was added.




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

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

[jira] [Created] (SOLR-7766) support creation of a coreless collection

2015-07-09 Thread Christine Poerschke (JIRA)

Christine Poerschke created SOLR-7766:
-

 Summary: support creation of a coreless collection
 Key: SOLR-7766
 URL: https://issues.apache.org/jira/browse/SOLR-7766
 Project: Solr
  Issue Type: New Feature
Reporter: Christine Poerschke
Priority: Minor


By supplying a deliberately empty create node set (via 
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
 the collection can be created in the usual manner but it will just not yet 
contain any cores for any of its shards. Later on 
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
 calls can create cores as and when and where required.

github pull request with proposed changes to follow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6645) BKD tree queries should use BitDocIdSet.Builder


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

Adrien Grand commented on LUCENE-6645:
--

+1 I'm curious if you know what part makes it so much faster? Is it limiting 
the maximum array size to threshold at most, or the fact that some ArrayUtil 
logic is now inlined in the builder?

 BKD tree queries should use BitDocIdSet.Builder
 ---

 Key: LUCENE-6645
 URL: https://issues.apache.org/jira/browse/LUCENE-6645
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
 Attachments: LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch, 
 LUCENE-6645.patch, LUCENE-6645.patch


 When I was iterating on BKD tree originally I remember trying to use this 
 builder (which makes a sparse bit set at first and then upgrades to dense if 
 enough bits get set) and being disappointed with its performance.
 I wound up just making a FixedBitSet every time, but this is obviously 
 wasteful for small queries.
 It could be the perf was poor because I was always .or'ing in DISIs that had 
 512 - 1024 hits each time (the size of each leaf cell in the BKD tree)?  I 
 also had to make my own DISI wrapper around each leaf cell... maybe that was 
 the source of the slowness, not sure.
 I also sort of wondered whether the SmallDocSet in spatial module (backed by 
 a SentinelIntSet) might be faster ... though it'd need to be sorted in the 
 and after building before returning to Lucene.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-7767) Zookeeper Ensamble Admin UI

2015-07-09 Thread Aniket Khare (JIRA)

Aniket Khare created SOLR-7767:
--

 Summary: Zookeeper Ensamble Admin UI
 Key: SOLR-7767
 URL: https://issues.apache.org/jira/browse/SOLR-7767
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud, UI, web gui
Reporter: Aniket Khare


For SolrCloud mode can we have the functionality to display the live nodes from 
the zookeeper ensemble. So that user can easily get to know if any of zookeeper 
instance is down or having any other issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-7768) Admin GUI to upload configuration files to Zookeeper

2015-07-09 Thread Aniket Khare (JIRA)

Aniket Khare created SOLR-7768:
--

 Summary: Admin GUI to upload configuration files to Zookeeper
 Key: SOLR-7768
 URL: https://issues.apache.org/jira/browse/SOLR-7768
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud, web gui
Reporter: Aniket Khare


can we have functionality where user can easily upload the configuration files 
to zookeeper.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr pull request: Lucene solr 5 2

2015-07-09 Thread aniketkhare

Github user aniketkhare closed the pull request at:

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


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

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

[jira] [Commented] (LUCENE-6670) OOM error in merge causes deadlock


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

Michael McCandless commented on LUCENE-6670:


Thanks, this should be fixed by LUCENE-6579 ... I hit exactly the same deadlock 
and fixed it there by having CMS.sync skip waiting on the calling thread.

 OOM error in merge causes deadlock
 --

 Key: LUCENE-6670
 URL: https://issues.apache.org/jira/browse/LUCENE-6670
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 5.2.1
Reporter: Jeffrey Morlan

 Using the ConcurrentMergeScheduler, when merging catches an OutOfMemoryError 
 and tries to rollback, the merge thread ends up calling Thread.join on 
 itself, which will never complete.
 Stack trace (line numbers are for Lucene 5.2.1):
 {noformat}
 Lucene Merge Thread #1 #356502 daemon prio=5 os_prio=0 
 tid=0x7f3f78622000 nid=0x11b5 in Object.wait() [0x7f3e90528000]
java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 at java.lang.Thread.join(Thread.java:1245)
 - locked 0x0001965aff78 (a 
 org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread)
 at java.lang.Thread.join(Thread.java:1319)
 at 
 org.apache.lucene.index.ConcurrentMergeScheduler.sync(ConcurrentMergeScheduler.java:420)
 at 
 org.apache.lucene.index.ConcurrentMergeScheduler.close(ConcurrentMergeScheduler.java:401)
 at 
 org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:1948)
 at org.apache.lucene.index.IndexWriter.rollback(IndexWriter.java:1921)
 - locked 0x0001965b0100 (a java.lang.Object)
 at 
 org.apache.lucene.index.IndexWriter.tragicEvent(IndexWriter.java:4439)
 - locked 0x0001965b0100 (a java.lang.Object)
 at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3571)
 at 
 org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:581)
 at 
 org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:619)
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2494 - Failure!

2015-07-09 Thread ASF subversion and git services (JIRA)

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2494/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([1903AEB43CC3824E:9157916E923FEFB6]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.junit.Assert.assertNull(Assert.java:562)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testNoConfigSetExist(CollectionsAPIDistributedZkTest.java:518)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:165)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at

[jira] [Commented] (LUCENE-6645) BKD tree queries should use BitDocIdSet.Builder


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

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

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

LUCENE-6645: optimize DocIdSetBuilder a bit more

 BKD tree queries should use BitDocIdSet.Builder
 ---

 Key: LUCENE-6645
 URL: https://issues.apache.org/jira/browse/LUCENE-6645
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
 Attachments: LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch, 
 LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch


 When I was iterating on BKD tree originally I remember trying to use this 
 builder (which makes a sparse bit set at first and then upgrades to dense if 
 enough bits get set) and being disappointed with its performance.
 I wound up just making a FixedBitSet every time, but this is obviously 
 wasteful for small queries.
 It could be the perf was poor because I was always .or'ing in DISIs that had 
 512 - 1024 hits each time (the size of each leaf cell in the BKD tree)?  I 
 also had to make my own DISI wrapper around each leaf cell... maybe that was 
 the source of the slowness, not sure.
 I also sort of wondered whether the SmallDocSet in spatial module (backed by 
 a SentinelIntSet) might be faster ... though it'd need to be sorted in the 
 and after building before returning to Lucene.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (LUCENE-6645) BKD tree queries should use BitDocIdSet.Builder

2015-07-09 Thread ASF subversion and git services (JIRA)

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

Michael McCandless resolved LUCENE-6645.

Resolution: Fixed
Fix Version/s: Trunk
5.3

BKD tree queries should use BitDocIdSet.Builder
---

Key: LUCENE-6645
URL: https://issues.apache.org/jira/browse/LUCENE-6645
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
Fix For: 5.3, Trunk

Attachments: LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch,
LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6645) BKD tree queries should use BitDocIdSet.Builder


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

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

Commit 1690176 from [~mikemccand] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1690176 ]

LUCENE-6645: optimize DocIdSetBuilder a bit more

 BKD tree queries should use BitDocIdSet.Builder
 ---

 Key: LUCENE-6645
 URL: https://issues.apache.org/jira/browse/LUCENE-6645
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
 Attachments: LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch, 
 LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch


 When I was iterating on BKD tree originally I remember trying to use this 
 builder (which makes a sparse bit set at first and then upgrades to dense if 
 enough bits get set) and being disappointed with its performance.
 I wound up just making a FixedBitSet every time, but this is obviously 
 wasteful for small queries.
 It could be the perf was poor because I was always .or'ing in DISIs that had 
 512 - 1024 hits each time (the size of each leaf cell in the BKD tree)?  I 
 also had to make my own DISI wrapper around each leaf cell... maybe that was 
 the source of the slowness, not sure.
 I also sort of wondered whether the SmallDocSet in spatial module (backed by 
 a SentinelIntSet) might be faster ... though it'd need to be sorted in the 
 and after building before returning to Lucene.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Is solrconfig.xml a potentially misleading filename?

2015-07-09 Thread Mark Miller

It is the wrong name - mostly because it came from a single core solution.
We could change it, but you have to pretty carefully consider how heavily
it's embedded out there now.

- Mark

On Thu, Jul 9, 2015 at 1:20 PM Shawn Heisey apa...@elyograg.org wrote:

 On 7/9/2015 10:55 AM, Erick Erickson wrote:
  coreconfig.xml has it's own problems in SolrCloud,
  collectionconfig seems better. Except in that case
  stand-alone Solr doesn't really use collections...
 
  Siiggghhh.

 I debated with myself on whether I even wanted to bring this up.
 Ultimately I decided it would be interesting to discuss, even if we
 don't take any action.

 As potential replacements for solrconfig.xml, I find that core.xml or
 possibly just config.xml are the most appealing ... but the former might
 be confusing in a SolrCloud context.  I'm biased towards cores, because
 the Solr indexes that I interact with most often are NOT using
 SolrCloud, and might never use it.  I've heard rumblings about SolrCloud
 becoming the *only* running mode, but that hasn't happened so far.

 I understand how we got where we are today -- in the early days, Solr
 only handled one index, so the solrconfig.xml actually did configure all
 of Solr.

 Thanks,
 Shawn


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

 --
- Mark
about.me/markrmiller

[jira] [Commented] (LUCENE-6645) BKD tree queries should use BitDocIdSet.Builder


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

Adrien Grand commented on LUCENE-6645:
--

+1 thanks for fixing the javadocs ;-)

 BKD tree queries should use BitDocIdSet.Builder
 ---

 Key: LUCENE-6645
 URL: https://issues.apache.org/jira/browse/LUCENE-6645
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
 Attachments: LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch, 
 LUCENE-6645.patch, LUCENE-6645.patch, LUCENE-6645.patch


 When I was iterating on BKD tree originally I remember trying to use this 
 builder (which makes a sparse bit set at first and then upgrades to dense if 
 enough bits get set) and being disappointed with its performance.
 I wound up just making a FixedBitSet every time, but this is obviously 
 wasteful for small queries.
 It could be the perf was poor because I was always .or'ing in DISIs that had 
 512 - 1024 hits each time (the size of each leaf cell in the BKD tree)?  I 
 also had to make my own DISI wrapper around each leaf cell... maybe that was 
 the source of the slowness, not sure.
 I also sort of wondered whether the SmallDocSet in spatial module (backed by 
 a SentinelIntSet) might be faster ... though it'd need to be sorted in the 
 and after building before returning to Lucene.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60-ea-b21) - Build # 13392 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13392/
Java: 32bit/jdk1.8.0_60-ea-b21 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([DE284F93390C07ED:567C704997F06A15]:0)
at 
org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test(TestSolrConfigHandlerConcurrent.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 10902 lines...]
   [junit4] Suite: org.apache.solr.handler.TestSolrConfigHandlerConcurrent
   [junit4]   2 Creating dataDir:

[jira] [Commented] (LUCENE-6629) Random 7200 seconds build timeouts / infinite loops in Lucene tests?


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

Michael McCandless commented on LUCENE-6629:


bq. Can we have the 1.9ea JVM upgraded to b71 on that machine? Maybe it's a JVM 
issue that's been solved already.

The hangs seem to happen with 1.8.0_40 and 1.9ea...

 Random 7200 seconds build timeouts / infinite loops in Lucene tests?
 

 Key: LUCENE-6629
 URL: https://issues.apache.org/jira/browse/LUCENE-6629
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
 Attachments: 54457_consoleText.txt


 I'm not sure what's going on here, but every so often a Jenkins run will fail 
 with a build timeout (7200 seconds) with stack traces that do not look like 
 deadlock.  They never reproduce for me.
 We really need to improve test infra here, so that each HEARTBEAT we also got 
 1) full thread stacks and 2) total CPU usage of the process as reported by 
 the ManagementBean APIs ... this would shed more light on whether the JVM is 
 somehow hung vs our bug (infinite loop).  But infinite loop seems most likely 
 ... the stacks always seem to be somewhere spooky.
 We should try to gather recent Jenkins runs where this is happening, here, to 
 see if there are patterns / we can get to the root cause.
 Anyway, this happened to me on my old beast box, which runs the nightly ant 
 test times graphs: 
 http://people.apache.org/~mikemccand/lucenebench/antcleantest.html
 The 2015/06/27 data point is missing because it failed with this timeout:
 {noformat}
[junit4] Suite: org.apache.lucene.search.TestDocValuesRewriteMethod
[junit4]   2 ??? 28, 2015 7:01:29 ? 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
[junit4]   2 WARNING: Suite execution timed out: 
 org.apache.lucene.search.TestDocValuesRewriteMethod
[junit4]   21) Thread[id=1, name=main, state=WAITING, group=main]
[junit4]   2 at java.lang.Object.wait(Native Method)
[junit4]   2 at java.lang.Thread.join(Thread.java:1245)
[junit4]   2 at java.lang.Thread.join(Thread.java:1319)
[junit4]   2 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:578)
[junit4]   2 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.run(RandomizedRunner.java:444)
[junit4]   2 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:199)
[junit4]   2 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:310)
[junit4]   2 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)
[junit4]   22) Thread[id=213, 
 name=TEST-TestDocValuesRewriteMethod.testRegexps-seed#[C2DDF486BB909D8], 
 state=RUNNABLE, group=TGRP-TestDocValuesRewriteMethod]
[junit4]   2 at 
 org.apache.lucene.util.automaton.Operations.getLiveStates(Operations.java:900)
[junit4]   2 at 
 org.apache.lucene.util.automaton.Operations.hasDeadStates(Operations.java:389)
[junit4]   2 at 
 org.apache.lucene.util.automaton.Automata.makeString(Automata.java:517)
[junit4]   2 at 
 org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:579)
[junit4]   2 at 
 org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
[junit4]   2 at 
 org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:519)
[junit4]   2 at 
 org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
[junit4]   2 at 
 org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:510)
[junit4]   2 at 
 org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
[junit4]   2 at 
 org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:466)
[junit4]   2 at 
 org.apache.lucene.search.RegexpQuery.init(RegexpQuery.java:109)
[junit4]   2 at 
 org.apache.lucene.search.RegexpQuery.init(RegexpQuery.java:79)
[junit4]   2 at 
 org.apache.lucene.search.TestDocValuesRewriteMethod.assertSame(TestDocValuesRewriteMethod.java:117)
[junit4]   2 at 
 org.apache.lucene.search.TestDocValuesRewriteMethod.testRegexps(TestDocValuesRewriteMethod.java:109)
[junit4]   2 at 
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4]   2 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit4]   2 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4]   2 at java.lang.reflect.Method.invoke(Method.java:497)
[junit4]   2 at

[jira] [Commented] (LUCENE-6629) Random 7200 seconds build timeouts / infinite loops in Lucene tests?


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

Michael McCandless commented on LUCENE-6629:


Another confusing build hang: 
http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/55047/

{noformat}
  [junit4]   2 NOTE: reproduce with: ant test  -Dtestcase=TestJapaneseAnalyzer 
-Dtests.method=test5thCuriousString -Dtests.seed=4C20E5ADD6D736D1 
-Dtests.slow=true -Dtests.locale=pl_PL -Dtests.timezone=Indian/Mahe 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   7197s J2 | TestJapaneseAnalyzer.test5thCuriousString 
   [junit4] Throwable #1: java.lang.Exception: Test abandoned because 
suite timeout was reached.
   [junit4]at 
__randomizedtesting.SeedInfo.seed([4C20E5ADD6D736D1]:0)
   [junit4]   2 lip 09, 2015 5:49:51 PM 
com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
   [junit4]   2 WARNING: Will linger awaiting termination of 1 leaked 
thread(s).
   [junit4]   2 lip 09, 2015 5:50:11 PM 
com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
   [junit4]   2 SEVERE: 1 thread leaked from SUITE scope at 
org.apache.lucene.analysis.ja.TestJapaneseAnalyzer: 
   [junit4]   21) Thread[id=13, 
name=TEST-TestJapaneseAnalyzer.test5thCuriousString-seed#[4C20E5ADD6D736D1], 
state=RUNNABLE, group=TGRP-TestJapaneseAnalyzer]
   [junit4]   2 at 
org.apache.lucene.analysis.ja.JapaneseTokenizer.backtrace(JapaneseTokenizer.java:1056)
   [junit4]   2 at 
org.apache.lucene.analysis.ja.JapaneseTokenizer.parse(JapaneseTokenizer.java:647)
   [junit4]   2 at 
org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:474)
   [junit4]   2 at 
org.apache.lucene.analysis.ja.JapaneseBaseFormFilter.incrementToken(JapaneseBaseFormFilter.java:50)
   [junit4]   2 at 
org.apache.lucene.analysis.util.FilteringTokenFilter.incrementToken(FilteringTokenFilter.java:51)
   [junit4]   2 at 
org.apache.lucene.analysis.cjk.CJKWidthFilter.incrementToken(CJKWidthFilter.java:63)
   [junit4]   2 at 
org.apache.lucene.analysis.util.FilteringTokenFilter.incrementToken(FilteringTokenFilter.java:51)
   [junit4]   2 at 
org.apache.lucene.analysis.ja.JapaneseKatakanaStemFilter.incrementToken(JapaneseKatakanaStemFilter.java:63)
   [junit4]   2 at 
org.apache.lucene.analysis.core.LowerCaseFilter.incrementToken(LowerCaseFilter.java:45)
   [junit4]   2 at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:706)
   [junit4]   2 at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:680)
   [junit4]   2 at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:676)
   [junit4]   2 at 
org.apache.lucene.analysis.ja.TestJapaneseAnalyzer.test5thCuriousString(TestJapaneseAnalyzer.java:217)
   [junit4]   2 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
   [junit4]   2 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   [junit4]   2 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]   2 at java.lang.reflect.Method.invoke(Method.java:497)
   [junit4]   2 at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
   [junit4]   2 at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
   [junit4]   2 at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
   [junit4]   2 at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
   [junit4]   2 at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
   [junit4]   2 at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
   [junit4]   2 at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
   [junit4]   2 at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
   [junit4]   2 at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
   [junit4]   2 at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4]   2 at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
   [junit4]   2 at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
   [junit4]   2 at

Re: Is solrconfig.xml a potentially misleading filename?

2015-07-09 Thread Upayavira

Then make it accept two names, and start shipping examples with the new
name. Old stuff works, new stuff makes sense.

Upayavira


On Thu, Jul 9, 2015, at 08:47 PM, Mark Miller wrote:
 It is the wrong name - mostly because it came from a single core
 solution. We could change it, but you have to pretty carefully
 consider how heavily it's embedded out there now.

 - Mark

 On Thu, Jul 9, 2015 at 1:20 PM Shawn Heisey
 apa...@elyograg.org wrote:
 On 7/9/2015 10:55 AM, Erick Erickson wrote:

 coreconfig.xml has it's own problems in SolrCloud,

 collectionconfig seems better. Except in that case

 stand-alone Solr doesn't really use collections...



 Siiggghhh.


I debated with myself on whether I even wanted to bring this up.

Ultimately I decided it would be interesting to discuss, even if we

don't take any action.


As potential replacements for solrconfig.xml, I find that core.xml or

possibly just config.xml are the most appealing ... but the former might

be confusing in a SolrCloud context.  I'm biased towards cores, because

the Solr indexes that I interact with most often are NOT using

SolrCloud, and might never use it.  I've heard rumblings about SolrCloud

becoming the *only* running mode, but that hasn't happened so far.


I understand how we got where we are today -- in the early days, Solr

only handled one index, so the solrconfig.xml actually did configure all

of Solr.


Thanks,

Shawn



-

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

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

 --
 - Mark about.me/markrmiller

[jira] [Commented] (SOLR-6234) Scoring modes for query time join


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

Timothy Potter commented on SOLR-6234:
--

Well, nm ... I must not have done a full clean / rebuild. After doing so, it is 
working! Sorry for the noise ... will start looking into Ryan's contribution as 
well now. Thanks [~mkhludnev] - great feature!

 Scoring modes for query time join 
 --

 Key: SOLR-6234
 URL: https://issues.apache.org/jira/browse/SOLR-6234
 Project: Solr
  Issue Type: New Feature
  Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Timothy Potter
  Labels: features, patch, test
 Fix For: 5.3

 Attachments: SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, 
 otherHandler.patch


 it adds {{scorejoin}} query parser which calls Lucene's JoinUtil underneath. 
 It supports:
 - {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
  - {{score=none}} is *default*, eg if you *omit* this localparam 
 - supports {{b=100}} param to pass {{Query.setBoost()}}.
 - {{multiVals=true|false}} is introduced 
 - there is a test coverage for cross core join case. 
 - so far it joins string and multivalue string fields (Sorted, SortedSet, 
 Binary), but not Numerics DVs. follow-up LUCENE-5868  
 -there was a bug in cross core join, however there is a workaround for it- 
 it's fixed in Dec'14 patch.
 Note: the development of this patch was sponsored by an anonymous contributor 
 and approved for release under Apache License.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6736) A collections-like request handler to manage solr configurations on zookeeper


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

Erick Erickson commented on SOLR-6736:
--

This keeps recurring and recurring and recurring. I wonder if a graphical UI 
exists that we could reference, seems like it would be isolated enough.

 A collections-like request handler to manage solr configurations on zookeeper
 -

 Key: SOLR-6736
 URL: https://issues.apache.org/jira/browse/SOLR-6736
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud
Reporter: Varun Rajput
Assignee: Anshum Gupta
 Attachments: SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
 SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
 SOLR-6736.patch, newzkconf.zip, test_private.pem, test_pub.der, 
 zkconfighandler.zip, zkconfighandler.zip


 Managing Solr configuration files on zookeeper becomes cumbersome while using 
 solr in cloud mode, especially while trying out changes in the 
 configurations. 
 It will be great if there is a request handler that can provide an API to 
 manage the configurations similar to the collections handler that would allow 
 actions like uploading new configurations, linking them to a collection, 
 deleting configurations, etc.
 example : 
 {code}
 #use the following command to upload a new configset called mynewconf. This 
 will fail if there is alredy a conf called 'mynewconf'. The file could be a 
 jar , zip or a tar file which contains all the files for the this conf.
 curl -X POST -H 'Content-Type: application/octet-stream' --data-binary 
 @testconf.zip 
 http://localhost:8983/solr/admin/configs/mynewconf?sig=the-signature
 {code}
 A GET to http://localhost:8983/solr/admin/configs will give a list of configs 
 available
 A GET to http://localhost:8983/solr/admin/configs/mynewconf would give the 
 list of files in mynewconf



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 177 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/177/

1 tests failed.
REGRESSION:  org.apache.solr.search.TestSearcherReuse.test

Error Message:
expected same:Searcher@6c846341[collection1] 
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_0(6.0.0):c1)
 Uninverting(_1(6.0.0):c2)))} was not:Searcher@1ac92ca8[collection1] 
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_0(6.0.0):c1)
 Uninverting(_2(6.0.0):c2)))}

Stack Trace:
java.lang.AssertionError: expected same:Searcher@6c846341[collection1] 
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_0(6.0.0):c1)
 Uninverting(_1(6.0.0):c2)))} was not:Searcher@1ac92ca8[collection1] 
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_0(6.0.0):c1)
 Uninverting(_2(6.0.0):c2)))}
at 
__randomizedtesting.SeedInfo.seed([356D2712B09200E8:BD3918C81E6E6D10]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotSame(Assert.java:641)
at org.junit.Assert.assertSame(Assert.java:580)
at org.junit.Assert.assertSame(Assert.java:593)
at 
org.apache.solr.search.TestSearcherReuse.assertSearcherHasNotChanged(TestSearcherReuse.java:247)
at 
org.apache.solr.search.TestSearcherReuse.test(TestSearcherReuse.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at

[jira] [Commented] (SOLR-6234) Scoring modes for query time join