[jira] [Comment Edited] (SOLR-7948) MapReduceIndexerTool of solr 5.2.1 doesn't work with hadoop 2.7.1

[davidchiu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15088868#comment-15088868
 ] 

davidchiu edited comment on SOLR-7948 at 1/8/16 8:19 AM:
-

I found a same issue about oozie with hadoop, the issue's jira is 
https://issues.apache.org/jira/browse/OOZIE-2066;

Can it inspire us?

another infomation:
http://mail-archives.apache.org/mod_mbox//oozie-user/201508.mbox/


was (Author: davidchiu):
I found a same issue about oozie with hadoop, the issue's jira is 
https://issues.apache.org/jira/browse/OOZIE-2066;

Can it inspire us?


> MapReduceIndexerTool of solr 5.2.1 doesn't work with hadoop 2.7.1
> -
>
> Key: SOLR-7948
> URL: https://issues.apache.org/jira/browse/SOLR-7948
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Affects Versions: 5.2.1
> Environment: OS:suse 11
> JDK:java version "1.7.0_65" 
> Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
> HADOOP:hadoop 2.7.1 
> SOLR:5.2.1
>Reporter: davidchiu
>Assignee: Mark Miller
>
> When I used MapReduceIndexerTool of 5.2.1 to index files, I got follwoing 
> errors,but I used 4.9.0's MapReduceIndexerTool, it did work with hadoop 2.7.1.
> Exception ERROR as following:
> INFO  - 2015-08-20 11:44:45.155; [   ] org.apache.solr.hadoop.HeartBeater; 
> Heart beat reporting class is 
> org.apache.hadoop.mapreduce.task.TaskAttemptContextImpl
> INFO  - 2015-08-20 11:44:45.161; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Using this unpacked directory as 
> solr home: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
> INFO  - 2015-08-20 11:44:45.162; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Creating embedded Solr server with 
> solrHomeDir: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip,
>  fs: 
> DFS[DFSClient[clientName=DFSClient_attempt_1440040092614_0004_r_01_0_1678264055_1,
>  ugi=root (auth:SIMPLE)]], outputShardDir: 
> hdfs://127.0.0.1:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1
> INFO  - 2015-08-20 11:44:45.194; [   ] 
> org.apache.solr.core.SolrResourceLoader; new SolrResourceLoader for 
> directory: 
> '/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/'
> INFO  - 2015-08-20 11:44:45.206; [   ] org.apache.solr.hadoop.HeartBeater; 
> HeartBeat thread running
> INFO  - 2015-08-20 11:44:45.207; [   ] org.apache.solr.hadoop.HeartBeater; 
> Issuing heart beat for 1 threads
> INFO  - 2015-08-20 11:44:45.418; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Constructed instance information 
> solr.home 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
>  
> (/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip),
>  instance dir 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/,
>  conf dir 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/conf/,
>  writing index to solr.data.dir 
> hdfs://127.0.0.1:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1/data,
>  with permdir 
> hdfs://127.0.0.10:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1
> INFO  - 2015-08-20 11:44:45.426; [   ] org.apache.solr.core.SolrXmlConfig; 
> Loading container configuration from 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/solr.xml
> INFO  - 2015-08-20 11:44:45.474; [   ] 
> org.apache.solr.core.CorePropertiesLocator; Config-defined core root 
> directory: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
> INFO  - 2015-08-20 11:44:45.503; [   ] 

RE: how to search miilions of record in Lucene query

[Uwe Schindler]

Hi,

this is not responsibility of a query parser. You need the right Query class! 
And here it is:

(Lucene 5): new TermsQuery(array/list of terms)
https://lucene.apache.org/core/5_4_0/queries/org/apache/lucene/queries/TermsQuery.html

(Lucene 4): new ConstantScoreQuery(TermsFilter(array/list of terms))
https://lucene.apache.org/core/4_10_4/queries/org/apache/lucene/queries/TermsFilter.html

The terms are instances of Term with your ID-field name and the ID value. Any 
document that has any of the listed IDs will match.

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


> -Original Message-
> From: Mugeesh Husain [mailto:muge...@gmail.com]
> Sent: Friday, January 08, 2016 8:05 AM
> To: dev@lucene.apache.org
> Subject: how to search miilions of record in Lucene query
> 
> Hello,
> How to create Lucene query parser which could accept 1 millions ID search
> like ID:1,2,.. upto 1 Millions with good performance.
> 
> Please give me suggestion which query parser i should use or custom etc
> 
> Thanks
> 
> 
> 
> --
> View this message in context: http://lucene.472066.n3.nabble.com/how-to-
> search-miilions-of-record-in-Lucene-query-tp4249341.html
> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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

[jira] [Created] (LUCENE-6968) LSH Filter

[Cao Manh Dat (JIRA)]

Cao Manh Dat created LUCENE-6968:


 Summary: LSH Filter
 Key: LUCENE-6968
 URL: https://issues.apache.org/jira/browse/LUCENE-6968
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Cao Manh Dat


I'm planning to implement LSH. Which support query like this
{quote}
Find similar documents that have 0.8 or higher similar score with a given 
document. Similarity measurement can be cosine, jaccard, euclid..
{quote}
For example. Given following corpus
{quote}
1. Solr is an open source search engine based on Lucene
2. Solr is an open source enterprise search engine based on Lucene
3. Solr is an popular open source enterprise search engine based on Lucene
4. Apache Lucene is a high-performance, full-featured text search engine 
library written entirely in Java
{quote}
We wanna find documents that have 0.6 score in jaccard with this doc
{quote}
Solr is an open source search engine
{quote}
It we return only docs 1,2 and 3 (MoreLikeThis will also return doc 4)



--
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-6968) LSH Filter

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated LUCENE-6968:
-
Attachment: LUCENE-6968.patch

Initial patch. Can find similar documents based on Jaccard similarity.

> LSH Filter
> --
>
> Key: LUCENE-6968
> URL: https://issues.apache.org/jira/browse/LUCENE-6968
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Cao Manh Dat
> Attachments: LUCENE-6968.patch
>
>
> I'm planning to implement LSH. Which support query like this
> {quote}
> Find similar documents that have 0.8 or higher similar score with a given 
> document. Similarity measurement can be cosine, jaccard, euclid..
> {quote}
> For example. Given following corpus
> {quote}
> 1. Solr is an open source search engine based on Lucene
> 2. Solr is an open source enterprise search engine based on Lucene
> 3. Solr is an popular open source enterprise search engine based on Lucene
> 4. Apache Lucene is a high-performance, full-featured text search engine 
> library written entirely in Java
> {quote}
> We wanna find documents that have 0.6 score in jaccard with this doc
> {quote}
> Solr is an open source search engine
> {quote}
> It we return only docs 1,2 and 3 (MoreLikeThis will also return doc 4)



--
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-8418) BoostQuery cannot be cast to TermQuery

[Ere Maijala (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15088958#comment-15088958
 ] 

Ere Maijala commented on SOLR-8418:
---

Confirmed fixed for me too. Thanks!

> BoostQuery cannot be cast to TermQuery
> --
>
> Key: SOLR-8418
> URL: https://issues.apache.org/jira/browse/SOLR-8418
> Project: Solr
>  Issue Type: Bug
>  Components: MoreLikeThis
>Affects Versions: 5.4
>Reporter: Jens Wille
>Assignee: Ramkumar Aiyengar
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8418.patch, SOLR-8418.patch
>
>
> As a consequence of LUCENE-6590, {{MoreLikeThisHandler}} was changed in 
> r1701621 to use the new API. In SOLR-7912, I adapted that code for 
> {{CloudMLTQParser}} and {{SimpleMLTQParser}}. However, setting the {{boost}} 
> parameter just failed for me after updating to 5.4 with the following error 
> message:
> {code}
> java.lang.ClassCastException: org.apache.lucene.search.BoostQuery cannot be 
> cast to org.apache.lucene.search.TermQuery
> at 
> org.apache.solr.search.mlt.SimpleMLTQParser.parse(SimpleMLTQParser.java:139)
> at org.apache.solr.search.QParser.getQuery(QParser.java:141)
> at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:160)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:254)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:457)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:222)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> {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

how to search miilions of record in Lucene query

[Mugeesh Husain]

Hello,
How to create Lucene query parser which could accept 1 millions ID search
like ID:1,2,.. upto 1 Millions with good performance.

Please give me suggestion which query parser i should use or custom etc

Thanks



--
View this message in context: 
http://lucene.472066.n3.nabble.com/how-to-search-miilions-of-record-in-Lucene-query-tp4249341.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

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

[jira] [Commented] (SOLR-8453) Jetty update from 9.2 to 9.3 causes the server to reset formerly legitimate client connections.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15088866#comment-15088866
 ] 

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

Commit 1723660 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1723660 ]

SOLR-8453: Fix raw socket test to correctly use HTTP spec: headers in HTTP are 
US-ASCII, body's Content-Length is number of bytes (not chars!), PrintWriter 
swallows Exceptions and was not needed (Forbidden apis found the bug, but fix 
was incorrect)

> Jetty update from 9.2 to 9.3 causes the server to reset formerly legitimate 
> client connections.
> ---
>
> Key: SOLR-8453
> URL: https://issues.apache.org/jira/browse/SOLR-8453
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-8453.patch, SOLR-8453.patch, SOLR-8453.patch, 
> SOLR-8453.patch, SOLR-8453.patch, SOLR-8453.patch, SOLR-8453.patch, 
> SOLR-8453.patch, SOLR-8453_test.patch, SOLR-8453_test.patch, jetty9.2.pcapng, 
> jetty9.3.pcapng
>
>
> The basic problem is that when we are streaming in updates via a client, an 
> update can fail in a way that further updates in the request will not be 
> processed, but not in a way that causes the client to stop and finish up the 
> request before the server does something else with that connection.
> This seems to mean that even after the server stops processing the request, 
> the concurrent update client is still in the process of sending the request. 
> It seems previously, Jetty would not go after the connection very quickly 
> after the server processing thread was stopped via exception, and the client 
> (usually?) had time to clean up properly. But after the Jetty upgrade from 
> 9.2 to 9.3, Jetty closes the connection on the server sooner than previous 
> versions (?), and the client does not end up getting notified of the original 
> exception at all and instead hits a connection reset exception. The result 
> was random fails due to connection reset throughout our tests and one 
> particular test failing consistently. Even before this update, it does not 
> seem like we are acting in a safe or 'behaved' manner, but our version of 
> Jetty was relaxed enough (or a bug was fixed?) for our tests to work out.



--
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-7948) MapReduceIndexerTool of solr 5.2.1 doesn't work with hadoop 2.7.1

[davidchiu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15088868#comment-15088868
 ] 

davidchiu commented on SOLR-7948:
-

I found a same issue about oozie with hadoop, the issue's jira is 
https://issues.apache.org/jira/browse/OOZIE-2066;

Can it inspire us?


> MapReduceIndexerTool of solr 5.2.1 doesn't work with hadoop 2.7.1
> -
>
> Key: SOLR-7948
> URL: https://issues.apache.org/jira/browse/SOLR-7948
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Affects Versions: 5.2.1
> Environment: OS:suse 11
> JDK:java version "1.7.0_65" 
> Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
> HADOOP:hadoop 2.7.1 
> SOLR:5.2.1
>Reporter: davidchiu
>Assignee: Mark Miller
>
> When I used MapReduceIndexerTool of 5.2.1 to index files, I got follwoing 
> errors,but I used 4.9.0's MapReduceIndexerTool, it did work with hadoop 2.7.1.
> Exception ERROR as following:
> INFO  - 2015-08-20 11:44:45.155; [   ] org.apache.solr.hadoop.HeartBeater; 
> Heart beat reporting class is 
> org.apache.hadoop.mapreduce.task.TaskAttemptContextImpl
> INFO  - 2015-08-20 11:44:45.161; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Using this unpacked directory as 
> solr home: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
> INFO  - 2015-08-20 11:44:45.162; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Creating embedded Solr server with 
> solrHomeDir: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip,
>  fs: 
> DFS[DFSClient[clientName=DFSClient_attempt_1440040092614_0004_r_01_0_1678264055_1,
>  ugi=root (auth:SIMPLE)]], outputShardDir: 
> hdfs://127.0.0.1:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1
> INFO  - 2015-08-20 11:44:45.194; [   ] 
> org.apache.solr.core.SolrResourceLoader; new SolrResourceLoader for 
> directory: 
> '/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/'
> INFO  - 2015-08-20 11:44:45.206; [   ] org.apache.solr.hadoop.HeartBeater; 
> HeartBeat thread running
> INFO  - 2015-08-20 11:44:45.207; [   ] org.apache.solr.hadoop.HeartBeater; 
> Issuing heart beat for 1 threads
> INFO  - 2015-08-20 11:44:45.418; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Constructed instance information 
> solr.home 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
>  
> (/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip),
>  instance dir 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/,
>  conf dir 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/conf/,
>  writing index to solr.data.dir 
> hdfs://127.0.0.1:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1/data,
>  with permdir 
> hdfs://127.0.0.10:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1
> INFO  - 2015-08-20 11:44:45.426; [   ] org.apache.solr.core.SolrXmlConfig; 
> Loading container configuration from 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/solr.xml
> INFO  - 2015-08-20 11:44:45.474; [   ] 
> org.apache.solr.core.CorePropertiesLocator; Config-defined core root 
> directory: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
> INFO  - 2015-08-20 11:44:45.503; [   ] org.apache.solr.core.CoreContainer; 
> New CoreContainer 1656436773
> INFO  - 2015-08-20 11:44:45.503; [   ] org.apache.solr.core.CoreContainer; 
> Loading cores into CoreContainer 
> 

[jira] [Updated] (LUCENE-6932) Seek past EOF with RAMDirectory should throw EOFException

[Michael McCandless (JIRA)]

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

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

Thanks [~stephane campinas], I merged your two patches together into one, and 
changed the approach a bit to avoid adding a new {{enforceEOF}} member to 
{{RAMInputStream}} ... does it look OK?

> Seek past EOF with RAMDirectory should throw EOFException
> -
>
> Key: LUCENE-6932
> URL: https://issues.apache.org/jira/browse/LUCENE-6932
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: Trunk
>Reporter: Stéphane Campinas
> Attachments: LUCENE-6932.patch, issue6932.patch, testcase.txt
>
>
> In the JUnit test case from the attached file, I call "IndexInput.seek()" on 
> a position past
> EOF. However, there is no EOFException that is thrown.
> To reproduce the error, please use the seed test: 
> -Dtests.seed=8273A81C129D35E2



--
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-8527) Improve JdbcTest to cleanup properly on failures

[Kevin Risden (JIRA)]

Kevin Risden created SOLR-8527:
--

 Summary: Improve JdbcTest to cleanup properly on failures
 Key: SOLR-8527
 URL: https://issues.apache.org/jira/browse/SOLR-8527
 Project: Solr
  Issue Type: Improvement
  Components: SolrJ
Affects Versions: Trunk
Reporter: Kevin Risden


Currently if a test case fails in JdbcTest then resources are not closed 
properly.



--
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-8505) core/DirectoryFactory.LOCK_TYPE_HDFS - add & use it instead of String literals

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-8505.
---
   Resolution: Fixed
Fix Version/s: Trunk
   5.5

> core/DirectoryFactory.LOCK_TYPE_HDFS - add & use it instead of String literals
> --
>
> Key: SOLR-8505
> URL: https://issues.apache.org/jira/browse/SOLR-8505
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8505.patch
>
>
> * Add {{core/DirectoryFactory.LOCK_TYPE_HDFS}}, other 
> {{core/DirectoryFactory.LOCK_TYPE_*}} values already exist.
> * Extend {{DirectoryFactoryTest.testLockTypesUnchanged}} to account for 
> LOCK_TYPE_HDFS.
> * Change {{SolrIndexConfigTest.testToMap}} to also consider 
> "hdfs"/LOCK_TYPE_HDFS.



--
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-8502) Improve Solr JDBC Driver to support SQL Clients like DBVisualizer

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089599#comment-15089599
 ] 

Kevin Risden commented on SOLR-8502:


Here are some of the JIRAs are that are ready for review.
* SOLR-8503
* SOLR-8507
* SOLR-8511
* SOLR-8513
* SOLR-8514
* SOLR-8515
* SOLR-8516

> Improve Solr JDBC Driver to support SQL Clients like DBVisualizer
> -
>
> Key: SOLR-8502
> URL: https://issues.apache.org/jira/browse/SOLR-8502
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>  Labels: jdbc
>
> Currently when trying to connect to Solr with the JDBC driver with a SQL 
> client the driver must implement more methods and metadata to allow 
> connections. This JIRA is designed to act as an umbrella for the JDBC changes.
> An initial pass from a few months ago is here: 
> https://github.com/risdenk/lucene-solr/tree/expand-jdbc. This needs to be 
> broken up and create patches for the related sub tasks.



--
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-6944) BooleanWeight.bulkScorer should not build any sub bulk scorer if there are required/prohibited clauses

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-6944.
--
Resolution: Fixed

Yep, that's fixed!

> BooleanWeight.bulkScorer should not build any sub bulk scorer if there are 
> required/prohibited clauses
> --
>
> Key: LUCENE-6944
> URL: https://issues.apache.org/jira/browse/LUCENE-6944
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: LUCENE-6944.patch
>
>
> BooleanWeight.bulkScorer creates a sub bulk scorer for all clauses until it 
> meets a clause that is not optional (the only kind of clause it can deal 
> with). However the Weight.bulkScorer method is sometimes costly, so 
> BooleanWeight.bulkScorer should first inspect all clauses to see if any of 
> them is not optional to avoid creating costly bulk scorers to only trash them 
> later.



--
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] (LUCENE-6948) ArrayIndexOutOfBoundsException in PagedBytes$Reader.fill

[Christine Poerschke (JIRA)]

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

Christine Poerschke reassigned LUCENE-6948:
---

Assignee: Christine Poerschke

> ArrayIndexOutOfBoundsException in PagedBytes$Reader.fill
> 
>
> Key: LUCENE-6948
> URL: https://issues.apache.org/jira/browse/LUCENE-6948
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 4.10.4
>Reporter: Michael Lawley
>Assignee: Christine Poerschke
> Attachments: LUCENE-6948.patch
>
>
> With a very large index (in our case > 10G), we are seeing exceptions like:
> java.lang.ArrayIndexOutOfBoundsException: -62400
>   at org.apache.lucene.util.PagedBytes$Reader.fill(PagedBytes.java:116)
>   at 
> org.apache.lucene.search.FieldCacheImpl$BinaryDocValuesImpl$1.get(FieldCacheImpl.java:1342)
>   at 
> org.apache.lucene.search.join.TermsCollector$SV.collect(TermsCollector.java:106)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:193)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:309)
> The code in question is trying to allocate an array with a negative size.  We 
> believe the source of the error is in 
> org.apache.lucene.search.FieldCacheImpl$BinaryDocValuesImpl$1.get where the 
> following code occurs:
>   final int pointer = (int) docToOffset.get(docID);
>   if (pointer == 0) {
> term.length = 0;
>   } else {
> bytes.fill(term, pointer);
>   }
> The cast to int will break if the (long) result of docToOffset.get is too 
> large, and is unnecessary in the first place since bytes.fill takes a long as 
> its second parameter.
> Proposed fix:
>   final long pointer = docToOffset.get(docID);
>   if (pointer == 0) {
> term.length = 0;
>   } else {
> bytes.fill(term, pointer);
>   }



--
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 # 3003 - Still Failing!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testMaxTime

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([4B4BBA2C5F675922:D1BFC7CEC1FDC51E]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:755)
at 
org.apache.solr.update.AutoCommitTest.testMaxTime(AutoCommitTest.java:244)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529=standard=0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:748)
... 40 more




Build Log:
[...truncated 9572 lines...]
   [junit4] Suite: org.apache.solr.update.AutoCommitTest
   

[jira] [Resolved] (SOLR-8504) (IndexSchema|SolrIndexConfig)Test: private static finals for solrconfig.xml and schema.xml String literals

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-8504.
---
   Resolution: Fixed
Fix Version/s: Trunk
   5.5

> (IndexSchema|SolrIndexConfig)Test: private static finals for solrconfig.xml 
> and schema.xml String literals
> --
>
> Key: SOLR-8504
> URL: https://issues.apache.org/jira/browse/SOLR-8504
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8504.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] [Created] (SOLR-8529) Improve JdbcTest to not use plain assert statements

[Kevin Risden (JIRA)]

Kevin Risden created SOLR-8529:
--

 Summary: Improve JdbcTest to not use plain assert statements
 Key: SOLR-8529
 URL: https://issues.apache.org/jira/browse/SOLR-8529
 Project: Solr
  Issue Type: Improvement
  Components: SolrJ
Affects Versions: Trunk
Reporter: Kevin Risden


Plain assert statements work but it makes debugging hard. Instead should use 
assertEquals, etc.



--
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-8529) Improve JdbcTest to not use plain assert statements

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089810#comment-15089810
 ] 

Kevin Risden commented on SOLR-8529:


Builds upon improvements from SOLR-8527.

> Improve JdbcTest to not use plain assert statements
> ---
>
> Key: SOLR-8529
> URL: https://issues.apache.org/jira/browse/SOLR-8529
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>
> Plain assert statements work but it makes debugging hard. Instead should use 
> assertEquals, etc.



--
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-7739) Lucene Classification Integration - UpdateRequestProcessor

[David de Kleer (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089837#comment-15089837
 ] 

David de Kleer commented on SOLR-7739:
--

Any updates on your update? ;-)

David

> Lucene Classification Integration - UpdateRequestProcessor
> --
>
> Key: SOLR-7739
> URL: https://issues.apache.org/jira/browse/SOLR-7739
> Project: Solr
>  Issue Type: New Feature
>  Components: update
>Affects Versions: 5.2.1
>Reporter: Alessandro Benedetti
>Assignee: Tommaso Teofili
>Priority: Minor
>  Labels: classification, index-time, update.chain, 
> updateProperties
> Attachments: SOLR-7739.patch
>
>
> It would be nice to have an UpdateRequestProcessor to interact with the 
> Lucene Classification Module and provide an easy way of auto classifying Solr 
> Documents on indexing.
> Documentation will be provided with the patch
> A first design will be provided soon.



--
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-8462) Improve error reporting for /stream handler

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8462:
-
Fix Version/s: (was: Trunk)
   6.0

> Improve error reporting for /stream handler
> ---
>
> Key: SOLR-8462
> URL: https://issues.apache.org/jira/browse/SOLR-8462
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>Assignee: Joel Bernstein
>Priority: Trivial
> Fix For: 6.0
>
> Attachments: SOLR-8462.patch, SOLR-8462.patch
>
>
> Currently, the /stream request handler reports errors by adding an 
> "EXCEPTION" name/value pair on a tuple in the TupleStream where the error 
> arose.  The "value" in this name/value pair is the message attached to the 
> exception.
> This works well in most instances, however it could be better in a few ways:
> 1.) Not all exceptions have messages.  For instance, 
> {{NullPointerExceptions}} and other run time exceptions fall into this 
> category.  This causes the /stream handler to return the relatively unhelpful 
> value: {"EXCEPTION":null,"EOF":true}.  The /stream handler should make sure 
> the exception has a message, and if not, it should report some other 
> information about the error (exception class name?).
> 2.) There are some common error cases that can arise from mis-use of the API. 
>  For instance, if the 'expr' parameter is missing.  Detecting and handling 
> these cases specifically would allow users to get back clearer, more useful 
> error messages.



--
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-8462) Improve error reporting for /stream handler

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-8462:


Assignee: Joel Bernstein

> Improve error reporting for /stream handler
> ---
>
> Key: SOLR-8462
> URL: https://issues.apache.org/jira/browse/SOLR-8462
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>Assignee: Joel Bernstein
>Priority: Trivial
> Fix For: Trunk
>
> Attachments: SOLR-8462.patch, SOLR-8462.patch
>
>
> Currently, the /stream request handler reports errors by adding an 
> "EXCEPTION" name/value pair on a tuple in the TupleStream where the error 
> arose.  The "value" in this name/value pair is the message attached to the 
> exception.
> This works well in most instances, however it could be better in a few ways:
> 1.) Not all exceptions have messages.  For instance, 
> {{NullPointerExceptions}} and other run time exceptions fall into this 
> category.  This causes the /stream handler to return the relatively unhelpful 
> value: {"EXCEPTION":null,"EOF":true}.  The /stream handler should make sure 
> the exception has a message, and if not, it should report some other 
> information about the error (exception class name?).
> 2.) There are some common error cases that can arise from mis-use of the API. 
>  For instance, if the 'expr' parameter is missing.  Detecting and handling 
> these cases specifically would allow users to get back clearer, more useful 
> error messages.



--
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-8509) Determine test strategy and add tests for JDBC driver metadata.

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8509:
---
Flags: Patch

> Determine test strategy and add tests for JDBC driver metadata.
> ---
>
> Key: SOLR-8509
> URL: https://issues.apache.org/jira/browse/SOLR-8509
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8509.patch
>
>
> Currently there is no testing of the JDBC metadata. Need to determine best 
> way to do this and add tests. Probably makes sense to add new metadata tests 
> to JdbcTest in many cases since need a cluster.



--
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-8502) Improve Solr JDBC Driver to support SQL Clients like DBVisualizer

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089599#comment-15089599
 ] 

Kevin Risden edited comment on SOLR-8502 at 1/8/16 9:21 PM:


Here are some of the JIRAs are that are ready for review.
* SOLR-8503
* SOLR-8507
* SOLR-8509
* SOLR-8511
* SOLR-8513
* SOLR-8514
* SOLR-8515
* SOLR-8516


was (Author: risdenk):
Here are some of the JIRAs are that are ready for review.
* SOLR-8503
* SOLR-8507
* SOLR-8511
* SOLR-8513
* SOLR-8514
* SOLR-8515
* SOLR-8516

> Improve Solr JDBC Driver to support SQL Clients like DBVisualizer
> -
>
> Key: SOLR-8502
> URL: https://issues.apache.org/jira/browse/SOLR-8502
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>  Labels: jdbc
> Fix For: 6.0
>
>
> Currently when trying to connect to Solr with the JDBC driver with a SQL 
> client the driver must implement more methods and metadata to allow 
> connections. This JIRA is designed to act as an umbrella for the JDBC changes.
> An initial pass from a few months ago is here: 
> https://github.com/risdenk/lucene-solr/tree/expand-jdbc. This needs to be 
> broken up and create patches for the related sub tasks.



--
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-5.x-Linux (64bit/jdk1.7.0_80) - Build # 15190 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15190/
Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler

Error Message:
ObjectTracker found 2 object(s) that were not released!!! [NRTCachingDirectory, 
NRTCachingDirectory]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 2 object(s) that were not 
released!!! [NRTCachingDirectory, NRTCachingDirectory]
at __randomizedtesting.SeedInfo.seed([2C5F2838D1794722]: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:228)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 9754 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_2C5F2838D1794722-001/init-core-data-001
   [junit4]   2> 7657 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[2C5F2838D1794722]) [ 
   ] o.a.s.SolrTestCaseJ4 ###Starting doTestStressReplication
   [junit4]   2> 7658 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[2C5F2838D1794722]) [ 
   ] o.a.s.SolrTestCaseJ4 Writing core.properties file to 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_2C5F2838D1794722-001/solr-instance-001/collection1
   [junit4]   2> 7683 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[2C5F2838D1794722]) [ 
   ] o.e.j.u.log Logging initialized @9292ms
   [junit4]   2> 7789 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[2C5F2838D1794722]) [ 
   ] o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 7839 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[2C5F2838D1794722]) [ 
   ] o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@4a0f2976{/solr,null,AVAILABLE}
   [junit4]   2> 7851 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[2C5F2838D1794722]) [ 
   ] o.e.j.s.ServerConnector Started 
ServerConnector@f8baa15{HTTP/1.1}{127.0.0.1:46538}
   [junit4]   2> 7851 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[2C5F2838D1794722]) [ 
   ] o.e.j.s.Server Started @9461ms
   [junit4]   2> 7851 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[2C5F2838D1794722]) [ 
   ] o.a.s.c.s.e.JettySolrRunner Jetty properties: 

[jira] [Commented] (SOLR-6622) Issue with Multivalued fields when using UIMA

[Tomasz Oliwa (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089815#comment-15089815
 ] 

Tomasz Oliwa commented on SOLR-6622:


I just reported https://issues.apache.org/jira/browse/SOLR-8528 , a bug with 
UIMA and multivalued fields that might have the same or similar underlying 
problem.

> Issue with Multivalued fields when using UIMA
> -
>
> Key: SOLR-6622
> URL: https://issues.apache.org/jira/browse/SOLR-6622
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - UIMA
>Affects Versions: Trunk
>Reporter: Maryam Khordad
> Attachments: SOLR-6622.patch
>
>
> When using any of UIMA addons on a multivalued fields, only the first row of 
> the field gets processed and UIMA update ignores the remaining rows. 
> This bug caused by "getTextsToAnalyze" method in "UIMAUpdateRequestProcessor" 
> class. SolrInputDocument
> .getFieldValue  must be changes to olrInputDocument
> .getFieldValues and the result must be an array not a single 
> variable.



--
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-8529) Improve JdbcTest to not use plain assert statements

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8529:
---
Attachment: SOLR-8529.patch

Changes assert statements to assertTrue, assertFalse, and assertEquals as 
appropriate.

> Improve JdbcTest to not use plain assert statements
> ---
>
> Key: SOLR-8529
> URL: https://issues.apache.org/jira/browse/SOLR-8529
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8529.patch
>
>
> Plain assert statements work but it makes debugging hard. Instead should use 
> assertEquals, etc.



--
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-8529) Improve JdbcTest to not use plain assert statements

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8529:
---
Flags: Patch

> Improve JdbcTest to not use plain assert statements
> ---
>
> Key: SOLR-8529
> URL: https://issues.apache.org/jira/browse/SOLR-8529
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8529.patch
>
>
> Plain assert statements work but it makes debugging hard. Instead should use 
> assertEquals, etc.



--
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-6948) ArrayIndexOutOfBoundsException in PagedBytes$Reader.fill

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089850#comment-15089850
 ] 

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

Commit 1723787 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1723787 ]

LUCENE-6948: Fix ArrayIndexOutOfBoundsException in PagedBytes$Reader.fill by 
removing an unnecessary long-to-int cast. Also, unrelated, 2 
ArrayList<>(initialCapacity) tweaks in getChildResources methods.

> ArrayIndexOutOfBoundsException in PagedBytes$Reader.fill
> 
>
> Key: LUCENE-6948
> URL: https://issues.apache.org/jira/browse/LUCENE-6948
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 4.10.4
>Reporter: Michael Lawley
>Assignee: Christine Poerschke
> Attachments: LUCENE-6948.patch
>
>
> With a very large index (in our case > 10G), we are seeing exceptions like:
> java.lang.ArrayIndexOutOfBoundsException: -62400
>   at org.apache.lucene.util.PagedBytes$Reader.fill(PagedBytes.java:116)
>   at 
> org.apache.lucene.search.FieldCacheImpl$BinaryDocValuesImpl$1.get(FieldCacheImpl.java:1342)
>   at 
> org.apache.lucene.search.join.TermsCollector$SV.collect(TermsCollector.java:106)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:193)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:309)
> The code in question is trying to allocate an array with a negative size.  We 
> believe the source of the error is in 
> org.apache.lucene.search.FieldCacheImpl$BinaryDocValuesImpl$1.get where the 
> following code occurs:
>   final int pointer = (int) docToOffset.get(docID);
>   if (pointer == 0) {
> term.length = 0;
>   } else {
> bytes.fill(term, pointer);
>   }
> The cast to int will break if the (long) result of docToOffset.get is too 
> large, and is unnecessary in the first place since bytes.fill takes a long as 
> its second parameter.
> Proposed fix:
>   final long pointer = docToOffset.get(docID);
>   if (pointer == 0) {
> term.length = 0;
>   } else {
> bytes.fill(term, pointer);
>   }



--
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-8502) Improve Solr JDBC Driver to support SQL Clients like DBVisualizer

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8502:
-
Fix Version/s: 6.0

> Improve Solr JDBC Driver to support SQL Clients like DBVisualizer
> -
>
> Key: SOLR-8502
> URL: https://issues.apache.org/jira/browse/SOLR-8502
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>  Labels: jdbc
> Fix For: 6.0
>
>
> Currently when trying to connect to Solr with the JDBC driver with a SQL 
> client the driver must implement more methods and metadata to allow 
> connections. This JIRA is designed to act as an umbrella for the JDBC changes.
> An initial pass from a few months ago is here: 
> https://github.com/risdenk/lucene-solr/tree/expand-jdbc. This needs to be 
> broken up and create patches for the related sub tasks.



--
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-8527) Improve JdbcTest to cleanup properly on failures

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8527:
---
Flags: Patch

> Improve JdbcTest to cleanup properly on failures
> 
>
> Key: SOLR-8527
> URL: https://issues.apache.org/jira/browse/SOLR-8527
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8527.patch
>
>
> Currently if a test case fails in JdbcTest then resources are not closed 
> properly.



--
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-8528) UIMA processor with multivalued fields and atomic updates bug

[Tomasz Oliwa (JIRA)]

Tomasz Oliwa created SOLR-8528:
--

 Summary: UIMA processor with multivalued fields and atomic updates 
bug
 Key: SOLR-8528
 URL: https://issues.apache.org/jira/browse/SOLR-8528
 Project: Solr
  Issue Type: Bug
  Components: contrib - UIMA, Schema and Analysis, update
Affects Versions: 5.3.1
 Environment: Linux (Fedora 21)
Reporter: Tomasz Oliwa


There is a showstopping bug with the UIMA processor and using atomic updates in 
Solr.

I am using the UIMA processor to populate multivalued fields upon indexing. 
When I later use atomic updates to update a document, all UIMA populated 
multivalued fields have only one value, the others are gone!

To reproduce:

1. Use the org.apache.solr.uima.processor.UIMAUpdateRequestProcessorFactory to 
populate a multivalued field during the indexing of a document. 
2. Use Solr atomic updates (http://yonik.com/solr/atomic-updates/) to set a 
different field of the document to a new value and commit
3. Any multivalued fields created by the UIMAUpdateRequestProcessorFactory now 
only have one value. 



--
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-8509) Determine test strategy and add tests for JDBC driver metadata.

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8509:
---
Attachment: SOLR-8509.patch

Idea for testing JDBC driver metadata. Currently this has some tests for each 
of the items to be implemented under SOLR-8502. Tests currently fail since many 
of the methods are not implemented yet.

A thought here is to comment out the assertions currently and uncomment them as 
part of each subtask under SOLR-8502.

> Determine test strategy and add tests for JDBC driver metadata.
> ---
>
> Key: SOLR-8509
> URL: https://issues.apache.org/jira/browse/SOLR-8509
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8509.patch
>
>
> Currently there is no testing of the JDBC metadata. Need to determine best 
> way to do this and add tests. Probably makes sense to add new metadata tests 
> to JdbcTest in many cases since need a cluster.



--
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-5.x-Linux (64bit/jdk1.8.0_66) - Build # 15189 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15189/
Java: 64bit/jdk1.8.0_66 -XX:-UseCompressedOops -XX:+UseSerialGC

5 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.MigrateRouteKeyTest

Error Message:
ObjectTracker found 3 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, SolrCore]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 3 object(s) that were not 
released!!! [MockDirectoryWrapper, MockDirectoryWrapper, SolrCore]
at __randomizedtesting.SeedInfo.seed([FC43CF849DD0E08]: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:228)
at sun.reflect.GeneratedMethodAccessor17.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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.cloud.DistribJoinFromCollectionTest.test

Error Message:
Error from server at http://127.0.0.1:40289/ct_o/ew/to_2x2_shard1_replica2: 
SolrCloud join: from_1x2 has a local replica (from_1x2_shard1_replica1) on 
127.0.0.1:40289_ct_o%2Few, but it is down

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:40289/ct_o/ew/to_2x2_shard1_replica2: SolrCloud 
join: from_1x2 has a local replica (from_1x2_shard1_replica1) on 
127.0.0.1:40289_ct_o%2Few, but it is down
at 
__randomizedtesting.SeedInfo.seed([FC43CF849DD0E08:87900322E72163F0]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.DistribJoinFromCollectionTest.testJoins(DistribJoinFromCollectionTest.java:132)
at 
org.apache.solr.cloud.DistribJoinFromCollectionTest.test(DistribJoinFromCollectionTest.java:103)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  

[jira] [Updated] (SOLR-8527) Improve JdbcTest to cleanup properly on failures

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8527:
---
Attachment: SOLR-8527.patch

This patch uses try-with-resources on the JDBC connections, statements, and 
resultsets. The diff looks a lot better in IntelliJ ignoring the whitespace 
changes in front of the assert statements.

> Improve JdbcTest to cleanup properly on failures
> 
>
> Key: SOLR-8527
> URL: https://issues.apache.org/jira/browse/SOLR-8527
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8527.patch
>
>
> Currently if a test case fails in JdbcTest then resources are not closed 
> properly.



--
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: Lucene/Solr 6.0.0 release

[Michael McCandless]

I don't think we should hold the major release for lots of new large
features that are not even started yet; they can just as easily be
done in a 6.x release.

Remember the counterbalance here is major new features that are done
(as far as we know!), yet not readily available to users.  And moving
away from Java 7, and lightning our back-compat burden.

At some point soonish (a week or two) I'd like to cut the 6.x branch.

I agree it would be nice to have cutover to git by then: are we ready
to open an INFRA issue to do the hard cutover?  Or do we still have
things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
and everyone else for pushing hard on this front!).

I don't think we need an umbrella Jira issue to track this ... let's
just mark the issues as 6.0 Fix Version (I just added 6.0 to Lucene
and Solr Jira).

I'll open an issue and work on removing StorableField from trunk, and
another for DimensionalTermQuery.

Mike McCandless

http://blog.mikemccandless.com


On Fri, Jan 8, 2016 at 11:45 AM, Jack Krupansky
 wrote:
> +1 for a 5.x deprecation release so 6.0 can remove old stuff.
>
> +1 for a git-based release
>
> +1 for at least 3 months for people to finish and stabilize work in progress
> - April to July seems like the right window to target
>
> -- Jack Krupansky
>
> On Fri, Jan 8, 2016 at 10:09 AM, Anshum Gupta 
> wrote:
>>
>> +1 to that ! Do you have a planned timeline for this?
>>
>> I would want some time to clean up code and also have a deprecation
>> release (5.5 or 5.6) out so we don't have to carry all the cruft through the
>> 6x series.
>>
>> On Fri, Jan 8, 2016 at 4:37 AM, Michael McCandless
>>  wrote:
>>>
>>> I think we should get the ball rolling for our next major release
>>> (6.0.0)?
>>>
>>> E.g., dimensional values is a big new feature for 6.x, and I think
>>> it's nearly ready except maybe fixing up the API so it's easier for
>>> the 1D case.
>>>
>>> I think we should maybe remove StorableField before releasing?  I.e.,
>>> go back to what we have in 5.x.  This change also caused challenges in
>>> the 5.0 release, and we just kicked the can down the road, but I think
>>> now we should just kick the can off the road...
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>>
>>
>> --
>> Anshum Gupta
>
>

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

[jira] [Updated] (SOLR-5209) last replica removal cascades to remove shard from clusterstate

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-5209:
--
Fix Version/s: (was: 5.0)
   6.0

> last replica removal cascades to remove shard from clusterstate
> ---
>
> Key: SOLR-5209
> URL: https://issues.apache.org/jira/browse/SOLR-5209
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.4
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Blocker
> Fix For: Trunk, 6.0
>
> Attachments: SOLR-5209.patch, SOLR-5209.patch
>
>
> The problem we saw was that unloading of an only replica of a shard deleted 
> that shard's info from the clusterstate. Once it was gone then there was no 
> easy way to re-create the shard (other than dropping and re-creating the 
> whole collection's state).
> This seems like a bug?
> Overseer.java around line 600 has a comment and commented out code:
> // TODO TODO TODO!!! if there are no replicas left for the slice, and the 
> slice has no hash range, remove it
> // if (newReplicas.size() == 0 && slice.getRange() == null) {
> // if there are no replicas left for the slice remove it



--
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: Lucene/Solr 6.0.0 release

[Joel Bernstein]

I agree completely with this approach. There's always another release right
around the corner. There's some nice features waiting in trunk.

+1 moving forward fairly soon.
+1 to 6.0 being the git release if possible.

Joel Bernstein
http://joelsolr.blogspot.com/

On Fri, Jan 8, 2016 at 2:51 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> I don't think we should hold the major release for lots of new large
> features that are not even started yet; they can just as easily be
> done in a 6.x release.
>
> Remember the counterbalance here is major new features that are done
> (as far as we know!), yet not readily available to users.  And moving
> away from Java 7, and lightning our back-compat burden.
>
> At some point soonish (a week or two) I'd like to cut the 6.x branch.
>
> I agree it would be nice to have cutover to git by then: are we ready
> to open an INFRA issue to do the hard cutover?  Or do we still have
> things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
> and everyone else for pushing hard on this front!).
>
> I don't think we need an umbrella Jira issue to track this ... let's
> just mark the issues as 6.0 Fix Version (I just added 6.0 to Lucene
> and Solr Jira).
>
> I'll open an issue and work on removing StorableField from trunk, and
> another for DimensionalTermQuery.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Fri, Jan 8, 2016 at 11:45 AM, Jack Krupansky
>  wrote:
> > +1 for a 5.x deprecation release so 6.0 can remove old stuff.
> >
> > +1 for a git-based release
> >
> > +1 for at least 3 months for people to finish and stabilize work in
> progress
> > - April to July seems like the right window to target
> >
> > -- Jack Krupansky
> >
> > On Fri, Jan 8, 2016 at 10:09 AM, Anshum Gupta 
> > wrote:
> >>
> >> +1 to that ! Do you have a planned timeline for this?
> >>
> >> I would want some time to clean up code and also have a deprecation
> >> release (5.5 or 5.6) out so we don't have to carry all the cruft
> through the
> >> 6x series.
> >>
> >> On Fri, Jan 8, 2016 at 4:37 AM, Michael McCandless
> >>  wrote:
> >>>
> >>> I think we should get the ball rolling for our next major release
> >>> (6.0.0)?
> >>>
> >>> E.g., dimensional values is a big new feature for 6.x, and I think
> >>> it's nearly ready except maybe fixing up the API so it's easier for
> >>> the 1D case.
> >>>
> >>> I think we should maybe remove StorableField before releasing?  I.e.,
> >>> go back to what we have in 5.x.  This change also caused challenges in
> >>> the 5.0 release, and we just kicked the can down the road, but I think
> >>> now we should just kick the can off the road...
> >>>
> >>> Mike McCandless
> >>>
> >>> http://blog.mikemccandless.com
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Anshum Gupta
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Comment Edited] (SOLR-6622) Issue with Multivalued fields when using UIMA

[Tomasz Oliwa (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089815#comment-15089815
 ] 

Tomasz Oliwa edited comment on SOLR-6622 at 1/8/16 8:29 PM:


This patch also fixes the issue I reported in 
https://issues.apache.org/jira/browse/SOLR-8528 , I just tested it. Would be 
nice if the patch could be committed to Solr.


was (Author: toldev):
I just reported https://issues.apache.org/jira/browse/SOLR-8528 , a bug with 
UIMA and multivalued fields that might have the same or similar underlying 
problem.

> Issue with Multivalued fields when using UIMA
> -
>
> Key: SOLR-6622
> URL: https://issues.apache.org/jira/browse/SOLR-6622
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - UIMA
>Affects Versions: Trunk
>Reporter: Maryam Khordad
> Attachments: SOLR-6622.patch
>
>
> When using any of UIMA addons on a multivalued fields, only the first row of 
> the field gets processed and UIMA update ignores the remaining rows. 
> This bug caused by "getTextsToAnalyze" method in "UIMAUpdateRequestProcessor" 
> class. SolrInputDocument
> .getFieldValue  must be changes to olrInputDocument
> .getFieldValues and the result must be an array not a single 
> variable.



--
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-8528) UIMA processor with multivalued fields and atomic updates bug

[Tomasz Oliwa (JIRA)]

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

Tomasz Oliwa resolved SOLR-8528.

   Resolution: Fixed
Fix Version/s: 5.3.1

This issue is resolved by the patch in 
https://issues.apache.org/jira/browse/SOLR-6622

It would be good if the aforementioned patch could be committed to Solr.

> UIMA processor with multivalued fields and atomic updates bug
> -
>
> Key: SOLR-8528
> URL: https://issues.apache.org/jira/browse/SOLR-8528
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - UIMA, Schema and Analysis, update
>Affects Versions: 5.3.1
> Environment: Linux (Fedora 21)
>Reporter: Tomasz Oliwa
>  Labels: solr, uima
> Fix For: 5.3.1
>
>
> There is a showstopping bug with the UIMA processor and using atomic updates 
> in Solr.
> I am using the UIMA processor to populate multivalued fields upon indexing. 
> When I later use atomic updates to update a document, all UIMA populated 
> multivalued fields have only one value, the others are gone!
> To reproduce:
> 1. Use the org.apache.solr.uima.processor.UIMAUpdateRequestProcessorFactory 
> to populate a multivalued field during the indexing of a document. 
> 2. Use Solr atomic updates (http://yonik.com/solr/atomic-updates/) to set a 
> different field of the document to a new value and commit
> 3. Any multivalued fields created by the UIMAUpdateRequestProcessorFactory 
> now only have one value. 



--
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-8285) Ensure that /export handles documents that have no value for the field gracefully.

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8285:
-
Fix Version/s: 6.0

> Ensure that /export handles documents that have no value for the field 
> gracefully.
> --
>
> Key: SOLR-8285
> URL: https://issues.apache.org/jira/browse/SOLR-8285
> Project: Solr
>  Issue Type: Bug
>Reporter: Erick Erickson
> Fix For: 6.0
>
>




--
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-8285) Ensure that /export handles documents that have no value for the field gracefully.

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-8285:


Assignee: Joel Bernstein

> Ensure that /export handles documents that have no value for the field 
> gracefully.
> --
>
> Key: SOLR-8285
> URL: https://issues.apache.org/jira/browse/SOLR-8285
> Project: Solr
>  Issue Type: Bug
>Reporter: Erick Erickson
>Assignee: Joel Bernstein
> Fix For: 6.0
>
>




--
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-8511) Implement DatabaseMetaDataImpl.getURL()

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8511:
---
Attachment: SOLR-8511.patch

Removed for getCollection and use getCatalog instead.

> Implement DatabaseMetaDataImpl.getURL()
> ---
>
> Key: SOLR-8511
> URL: https://issues.apache.org/jira/browse/SOLR-8511
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
> Attachments: SOLR-8511.patch, SOLR-8511.patch
>
>
> /**
>  * Retrieves the URL for this DBMS.
>  *
>  * @return the URL for this DBMS or null if it cannot be
>  *  generated
>  * @exception SQLException if a database access error occurs
>  */



--
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-8530) Add HavingStream to Streaming API and StreamingExpressions

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090073#comment-15090073
 ] 

Joel Bernstein edited comment on SOLR-8530 at 1/8/16 10:32 PM:
---

Is there a specific reason to use an index for the comparison logic? We could 
also add a ComparisonOperator interface and implement the basic comparison 
logic. 

{code}

having(reduce(), gt("x", 100))

{code}

And with boolean operators

{code}
having(rollup(), or(gt("x", 100), lt("x", 500)))
{code}


was (Author: joel.bernstein):
Is there a specific reason to use an index for the comparison logic? We could 
also add a ComparisonOperator interface and implement the basic comparison 
logic. 

{code}

having(reduce(), gt("x", 100))

{code}

And with boolean operators

{code}
having(reduce(), or(gt("x", 100), lt("x", 500)))
{code}

> Add HavingStream to Streaming API and StreamingExpressions
> --
>
> Key: SOLR-8530
> URL: https://issues.apache.org/jira/browse/SOLR-8530
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
>
> The goal here is to support something similar to SQL's HAVING clause where 
> one can filter documents based on data that is not available in the index. 
> For example, filter the output of a reduce() based on the calculated 
> metrics.
> {code}
> having(
>   reduce(
> search(.),
> sum(cost),
> on=customerId
>   ),
>   q="sum(cost):[500 TO *]"
> )
> {code}
> This example would return all where the total spent by each distinct customer 
> is >= 500. The total spent is calculated via the sum(cost) metric in the 
> reduce stream.
> The intent is to support as the filters in the having(...) clause the full 
> query syntax of a search(...) clause. I see this being possible in one of two 
> ways. 
> 1. Use Lucene's MemoryIndex and as each tuple is read out of the underlying 
> stream creating an instance of MemoryIndex and apply the query to it. If the 
> result of that is >0 then the tuple should be returned from the HavingStream.
> 2. Create an in-memory solr index via something like RamDirectory, read all 
> tuples into that in-memory index using the UpdateStream, and then stream out 
> of that all the matching tuples from the query.
> There are benefits to each approach but I think the easiest and most direct 
> one is the MemoryIndex approach. With MemoryIndex it isn't necessary to read 
> all incoming tuples before returning a single tuple. With a MemoryIndex there 
> is a need to parse the solr query parameters and create a valid Lucene query 
> but I suspect that can be done using existing QParser implementations.



--
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-8500) Allow the number of threads ConcurrentUpdateSolrClient StreamingSolrClients configurable by a system property

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090169#comment-15090169
 ] 

Mark Miller commented on SOLR-8500:
---

I think using more than 1 thread may actually introduce more reordering 
problems right now.

> Allow the number of threads ConcurrentUpdateSolrClient StreamingSolrClients 
> configurable by a system property
> -
>
> Key: SOLR-8500
> URL: https://issues.apache.org/jira/browse/SOLR-8500
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Priority: Minor
> Attachments: SOLR-8500.patch
>
>
> Despite the warning in that code, in extremely high throughput situations 
> where there are guaranteed to be no updates to existing documents, it can be 
> useful to have more than one runner.
> I envision this as an "expert" kind of thing, used only in situations where 
> the a-priori knowledge is that there are no updates to existing documents.



--
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-8530) Add HavingStream to Streaming API and StreamingExpressions

[Dennis Gove (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090228#comment-15090228
 ] 

Dennis Gove edited comment on SOLR-8530 at 1/8/16 11:57 PM:


A ComparisonOperation is another good option. 

My thinking for using an index is three-fold. First, a desire to not ask users 
to learn yet another way to do comparisons. If they already know the Solr 
syntax they can use that directly in this stream. And second to support even 
the non simple comparisons without having to implement them. For example a date 
range filter. This assumes that at some point we'll support metrics over dates 
but I think that's a reasonable assumption. And third, given the JDBCStream 
this provides a way for someone to do textual based queries over a subset of 
documents out of a join of Solr and non-Solr supplied documents. Obviously one 
could do a textual search over the Solr supplied stream directly but that may 
not be possible over the JDBC supplied stream.

That said, I'm not adverse to a ComparisonOperation. I just feel that a full 
index support gives us a lot of power going forward.


was (Author: dpgove):
This is another good option. 

My thinking for using an index is three-fold. First, a desire to not ask users 
to learn yet another way to do comparisons. If they already know the Solr 
syntax they can use that directly in this stream. And second to support even 
the non simple comparisons without having to implement them. For example a date 
range filter. This assumes that at some point we'll support metrics over dates 
but I think that's a reasonable assumption. And third, given the JDBCStream 
this provides a way for someone to do textual based queries over a subset of 
documents out of a join of Solr and non-Solr supplied documents. Obviously one 
could do a textual search over the Solr supplied stream directly but that may 
not be possible over the JDBC supplied stream.

That said, I'm not adverse to a ComparisonOperation. I just feel that a full 
index support gives us a lot of power going forward.

> Add HavingStream to Streaming API and StreamingExpressions
> --
>
> Key: SOLR-8530
> URL: https://issues.apache.org/jira/browse/SOLR-8530
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
>
> The goal here is to support something similar to SQL's HAVING clause where 
> one can filter documents based on data that is not available in the index. 
> For example, filter the output of a reduce() based on the calculated 
> metrics.
> {code}
> having(
>   reduce(
> search(.),
> sum(cost),
> on=customerId
>   ),
>   q="sum(cost):[500 TO *]"
> )
> {code}
> This example would return all where the total spent by each distinct customer 
> is >= 500. The total spent is calculated via the sum(cost) metric in the 
> reduce stream.
> The intent is to support as the filters in the having(...) clause the full 
> query syntax of a search(...) clause. I see this being possible in one of two 
> ways. 
> 1. Use Lucene's MemoryIndex and as each tuple is read out of the underlying 
> stream creating an instance of MemoryIndex and apply the query to it. If the 
> result of that is >0 then the tuple should be returned from the HavingStream.
> 2. Create an in-memory solr index via something like RamDirectory, read all 
> tuples into that in-memory index using the UpdateStream, and then stream out 
> of that all the matching tuples from the query.
> There are benefits to each approach but I think the easiest and most direct 
> one is the MemoryIndex approach. With MemoryIndex it isn't necessary to read 
> all incoming tuples before returning a single tuple. With a MemoryIndex there 
> is a need to parse the solr query parameters and create a valid Lucene query 
> but I suspect that can be done using existing QParser implementations.



--
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-8530) Add HavingStream to Streaming API and StreamingExpressions

[Dennis Gove (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090228#comment-15090228
 ] 

Dennis Gove commented on SOLR-8530:
---

This is another good option. 

My thinking for using an index is three-fold. First, a desire to not ask users 
to learn yet another way to do comparisons. If they already know the Solr 
syntax they can use that directly in this stream. And second to support even 
the non simple comparisons without having to implement them. For example a date 
range filter. This assumes that at some point we'll support metrics over dates 
but I think that's a reasonable assumption. And third, given the JDBCStream 
this provides a way for someone to do textual based queries over a subset of 
documents out of a join of Solr and non-Solr supplied documents. Obviously one 
could do a textual search over the Solr supplied stream directly but that may 
not be possible over the JDBC supplied stream.

That said, I'm not adverse to a ComparisonOperation. I just feel that a full 
index support gives us a lot of power going forward.

> Add HavingStream to Streaming API and StreamingExpressions
> --
>
> Key: SOLR-8530
> URL: https://issues.apache.org/jira/browse/SOLR-8530
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
>
> The goal here is to support something similar to SQL's HAVING clause where 
> one can filter documents based on data that is not available in the index. 
> For example, filter the output of a reduce() based on the calculated 
> metrics.
> {code}
> having(
>   reduce(
> search(.),
> sum(cost),
> on=customerId
>   ),
>   q="sum(cost):[500 TO *]"
> )
> {code}
> This example would return all where the total spent by each distinct customer 
> is >= 500. The total spent is calculated via the sum(cost) metric in the 
> reduce stream.
> The intent is to support as the filters in the having(...) clause the full 
> query syntax of a search(...) clause. I see this being possible in one of two 
> ways. 
> 1. Use Lucene's MemoryIndex and as each tuple is read out of the underlying 
> stream creating an instance of MemoryIndex and apply the query to it. If the 
> result of that is >0 then the tuple should be returned from the HavingStream.
> 2. Create an in-memory solr index via something like RamDirectory, read all 
> tuples into that in-memory index using the UpdateStream, and then stream out 
> of that all the matching tuples from the query.
> There are benefits to each approach but I think the easiest and most direct 
> one is the MemoryIndex approach. With MemoryIndex it isn't necessary to read 
> all incoming tuples before returning a single tuple. With a MemoryIndex there 
> is a need to parse the solr query parameters and create a valid Lucene query 
> but I suspect that can be done using existing QParser implementations.



--
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: Breaking Java back-compat in Solr

[Jack Krupansky]

With the talk of 6.0 coming out real soon and not waiting for new work,
will this 6.0/5.x issue become moot and morph into an issue for 7.0/6.x?

Settling the criteria for Solr plugin API back-compat still seems urgent,
but if the SOLR-8475 work can quickly get committed to trunk for 6.0 maybe
that takes some of the pressure off. Still, I'd prefer that the back-compat
criteria be settled ASAP.


-- Jack Krupansky

On Wed, Jan 6, 2016 at 10:43 AM, Yonik Seeley  wrote:

> On Wed, Jan 6, 2016 at 1:03 AM, Anshum Gupta 
> wrote:
> > As I understand, seems like there's reasonable consensus that we will:
> >
> > 1. provide strong back-compat for for SolrJ and REST APIs
> > 2. Strive to maintain but not guarantee *strong* back-compat for Java
> APIs.
>
> I think this actually represents what our current policy already is.
> The sticking point is perhaps "Strive to maintain" is changing
> definition to become much more lenient, to the point of being
> meaningless.
>
> Let's look at the issue that spawned this thread:
> https://issues.apache.org/jira/browse/SOLR-8475  (Some refactoring to
> SolrIndexSearcher)
>
> The issue is if QueryCommand and QueryResult should be moved out of
> SolrIndexSearcher in 5.x (essentially a rename), or of that rename
> should only be in 6.0.  If one's desire for a class rename (of classes
> that are likely to be used by plugins) overrides #2, I'd argue that
> means we essentially have no #2 at all.  Or perhaps I'm not grasping
> why it's really that important to rename those classes.
>
> Regarding annotations:
> Multiple people have suggested annotating classes that should remain
> back compat.  If we were to do this, wouldn't we want those
> annotations to cover the classes in question
> (SolrIndexSearcher,QueryCommand,QueryResult)?  If not, what would they
> cover and still be useful?
>
> -Yonik
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (LUCENE-6938) Convert build to work with Git rather than SVN.

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090296#comment-15090296
 ] 

Mark Miller commented on LUCENE-6938:
-

Doesn't look easy to share any state between multiple inits.

I don't even know if doing it at the top level appears any better than per jar. 
It's still a ton of calls per run.

We can simply allow it to be disabled via build.properties if it's an issue for 
some Windows devs.

> Convert build to work with Git rather than SVN.
> ---
>
> Key: LUCENE-6938
> URL: https://issues.apache.org/jira/browse/LUCENE-6938
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: LUCENE-6938.patch
>
>
> We assume an SVN checkout in parts of our build and will need to move to 
> assuming a Git checkout.
> Patches against https://github.com/dweiss/lucene-solr-svn2git from 
> LUCENE-6933.



--
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: Lucene/Solr 6.0.0 release

[Mark Miller]

On Fri, Jan 8, 2016 at 2:52 PM Michael McCandless 
wrote:

> I agree it would be nice to have cutover to git by then: are we ready
> to open an INFRA issue to do the hard cutover?  Or do we still have
> things to do on our end?  (Thank you Dawid and Mark and Paul and Uwe
> and everyone else for pushing hard on this front!).
>

We are fairly close - just one last thing to come to consensus on. Remains
to be seen how fast INFRA reacts for us though.

There will also probably be a bit to do as we work through the first
release, in terms of release scripts, docs, etc. I think most of it should
be fairly light weight changes though.

- Mark
-- 
- Mark
about.me/markrmiller

[jira] [Comment Edited] (SOLR-8530) Add HavingStream to Streaming API and StreamingExpressions

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090316#comment-15090316
 ] 

Joel Bernstein edited comment on SOLR-8530 at 1/9/16 1:27 AM:
--

I think it makes sense to have two implementations:

*MatchStream*: Uses an in-memory index to match Tuples.
*HavingStream*: Uses a ComparisionOperation to match Tuples.

One of the things we can think over is a specific stream for doing *parallel 
alerting*. The MatchStream is a step in that direction.


was (Author: joel.bernstein):
I think it makes sense to have two implementations:

*MatchStream*: Uses an in-memory index to match Tuples.
*HavingStream*: Uses a ComparisionOperation to match Tuples.

One of the things we can think over is a specific stream for doing *parallel 
alerting*. The MatchStream is step in that direction.

> Add HavingStream to Streaming API and StreamingExpressions
> --
>
> Key: SOLR-8530
> URL: https://issues.apache.org/jira/browse/SOLR-8530
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
>
> The goal here is to support something similar to SQL's HAVING clause where 
> one can filter documents based on data that is not available in the index. 
> For example, filter the output of a reduce() based on the calculated 
> metrics.
> {code}
> having(
>   reduce(
> search(.),
> sum(cost),
> on=customerId
>   ),
>   q="sum(cost):[500 TO *]"
> )
> {code}
> This example would return all where the total spent by each distinct customer 
> is >= 500. The total spent is calculated via the sum(cost) metric in the 
> reduce stream.
> The intent is to support as the filters in the having(...) clause the full 
> query syntax of a search(...) clause. I see this being possible in one of two 
> ways. 
> 1. Use Lucene's MemoryIndex and as each tuple is read out of the underlying 
> stream creating an instance of MemoryIndex and apply the query to it. If the 
> result of that is >0 then the tuple should be returned from the HavingStream.
> 2. Create an in-memory solr index via something like RamDirectory, read all 
> tuples into that in-memory index using the UpdateStream, and then stream out 
> of that all the matching tuples from the query.
> There are benefits to each approach but I think the easiest and most direct 
> one is the MemoryIndex approach. With MemoryIndex it isn't necessary to read 
> all incoming tuples before returning a single tuple. With a MemoryIndex there 
> is a need to parse the solr query parameters and create a valid Lucene query 
> but I suspect that can be done using existing QParser implementations.



--
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 # 906 - Still Failing

[Apache Jenkins Server]

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

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

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

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=2203, name=collection0, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
at 
__randomizedtesting.SeedInfo.seed([D783DC589FA23CF7:5FD7E382315E510F]:0)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:54310: Could not find collection : 
awholynewstresscollection_collection0_7
at __randomizedtesting.SeedInfo.seed([D783DC589FA23CF7]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:574)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:888)


FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication

Error Message:
[/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_D783DC589FA23CF7-001/solr-instance-015/./collection1/data,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_D783DC589FA23CF7-001/solr-instance-015/./collection1/data/index.20160109035248280,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_D783DC589FA23CF7-001/solr-instance-015/./collection1/data/index.20160109035248176]
 expected:<2> but was:<3>

Stack Trace:
java.lang.AssertionError: 
[/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_D783DC589FA23CF7-001/solr-instance-015/./collection1/data,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_D783DC589FA23CF7-001/solr-instance-015/./collection1/data/index.20160109035248280,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_D783DC589FA23CF7-001/solr-instance-015/./collection1/data/index.20160109035248176]
 expected:<2> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([D783DC589FA23CF7:20F03200594A9311]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:815)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1245)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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)

[jira] [Commented] (LUCENE-6938) Convert build to work with Git rather than SVN.

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090325#comment-15090325
 ] 

Mark Miller commented on LUCENE-6938:
-

bq. I think this is an improvement, not a requirement?

I think I slightly misunderstood this the first time. You meant making it more 
efficient for windows was not a requirement?

In that case I agree, though I figured if it was easy, we should just do it. It 
does not look so easy though. So I suggest a switch to turn it off in 
build.properties. But right, I don't think it's a requirement that we make it 
more efficient, just that we keep an id in the jars.

> Convert build to work with Git rather than SVN.
> ---
>
> Key: LUCENE-6938
> URL: https://issues.apache.org/jira/browse/LUCENE-6938
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: LUCENE-6938.patch
>
>
> We assume an SVN checkout in parts of our build and will need to move to 
> assuming a Git checkout.
> Patches against https://github.com/dweiss/lucene-solr-svn2git from 
> LUCENE-6933.



--
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-6938) Convert build to work with Git rather than SVN.

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090259#comment-15090259
 ] 

Mark Miller commented on LUCENE-6938:
-

bq. there must be some way to just get the checkout sha *once*

The key word is once. Yes, of course we can get the sha the same way as we can 
get an svn version :) Uwe's concern is how many times we execute a program to 
do it. Our ant scripts init 8 billion times per target.

I'll look into trying to exec a minimal number of times.

> Convert build to work with Git rather than SVN.
> ---
>
> Key: LUCENE-6938
> URL: https://issues.apache.org/jira/browse/LUCENE-6938
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: LUCENE-6938.patch
>
>
> We assume an SVN checkout in parts of our build and will need to move to 
> assuming a Git checkout.
> Patches against https://github.com/dweiss/lucene-solr-svn2git from 
> LUCENE-6933.



--
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-8531) ZK leader path changed in 5.4

[Jeff Wartes (JIRA)]

Jeff Wartes created SOLR-8531:
-

 Summary: ZK leader path changed in 5.4
 Key: SOLR-8531
 URL: https://issues.apache.org/jira/browse/SOLR-8531
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 5.4
Reporter: Jeff Wartes



While doing a rolling upgrade from 5.3 to 5.4 of a solrcloud cluster, I 
observed that upgraded nodes would not register their shards as active unless 
they were elected the leader for the shard.
There were no errors, the shards were fully up and responsive, but would not  
publish any change from the "down" state.

This appears to be because the recovery process never happens, because the ZK 
node containing the current leader can't be found, because the ZK path has 
changed.

Specifically, the leader data node changed from:
/leaders/
to
/leaders//leader

It looks to me like this happened during SOLR-7844, perhaps accidentally. 

At the least, the "Migrating to Solr 5.4" section of the README should get 
updated with this info, since it means a rolling upgrade of a collection with 
multiple replicas will suffer serious degradation in the number of active 
replicas as nodes are upgraded. It's entirely possible this will reduce some 
shards to a single active replica.






--
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-8530) Add HavingStream to Streaming API and StreamingExpressions

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090316#comment-15090316
 ] 

Joel Bernstein commented on SOLR-8530:
--

I think it makes sense to have two implementations:

*MatchStream*: Uses an in-memory index to match Tuples.
*HavingStream*: Uses a ComparisionOperation to match Tuples.

One of the things we can think over is a specific stream for doing *parallel 
alerting*. The MatchStream is step in that direction.

> Add HavingStream to Streaming API and StreamingExpressions
> --
>
> Key: SOLR-8530
> URL: https://issues.apache.org/jira/browse/SOLR-8530
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
>
> The goal here is to support something similar to SQL's HAVING clause where 
> one can filter documents based on data that is not available in the index. 
> For example, filter the output of a reduce() based on the calculated 
> metrics.
> {code}
> having(
>   reduce(
> search(.),
> sum(cost),
> on=customerId
>   ),
>   q="sum(cost):[500 TO *]"
> )
> {code}
> This example would return all where the total spent by each distinct customer 
> is >= 500. The total spent is calculated via the sum(cost) metric in the 
> reduce stream.
> The intent is to support as the filters in the having(...) clause the full 
> query syntax of a search(...) clause. I see this being possible in one of two 
> ways. 
> 1. Use Lucene's MemoryIndex and as each tuple is read out of the underlying 
> stream creating an instance of MemoryIndex and apply the query to it. If the 
> result of that is >0 then the tuple should be returned from the HavingStream.
> 2. Create an in-memory solr index via something like RamDirectory, read all 
> tuples into that in-memory index using the UpdateStream, and then stream out 
> of that all the matching tuples from the query.
> There are benefits to each approach but I think the easiest and most direct 
> one is the MemoryIndex approach. With MemoryIndex it isn't necessary to read 
> all incoming tuples before returning a single tuple. With a MemoryIndex there 
> is a need to parse the solr query parameters and create a valid Lucene query 
> but I suspect that can be done using existing QParser implementations.



--
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-Solaris (64bit/jdk1.8.0) - Build # 321 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/321/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

3 tests failed.
FAILED:  org.apache.solr.schema.TestCloudSchemaless.test

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:48472 within 3 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:48472 within 3 ms
at 
__randomizedtesting.SeedInfo.seed([BE26000435498C18:36723FDE9BB5E1E0]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:181)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:115)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:110)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:97)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.printLayout(AbstractDistribZkTestBase.java:286)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.distribTearDown(AbstractFullDistribZkTestBase.java:1475)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:942)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.concurrent.TimeoutException: Could not connect to 
ZooKeeper 127.0.0.1:48472 within 3 ms
at 
org.apache.solr.common.cloud.ConnectionManager.waitForConnected(ConnectionManager.java:209)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:173)
... 37 more


FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestCloudSchemaless

Error 

[jira] [Commented] (SOLR-8530) Add HavingStream to Streaming API and StreamingExpressions

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090073#comment-15090073
 ] 

Joel Bernstein commented on SOLR-8530:
--

Is there a specific reason to use an index for the comparison logic? We could 
also add a ComparisonOperator interface and implements the basic comparison 
logic. 

> Add HavingStream to Streaming API and StreamingExpressions
> --
>
> Key: SOLR-8530
> URL: https://issues.apache.org/jira/browse/SOLR-8530
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
>
> The goal here is to support something similar to SQL's HAVING clause where 
> one can filter documents based on data that is not available in the index. 
> For example, filter the output of a reduce() based on the calculated 
> metrics.
> {code}
> having(
>   reduce(
> search(.),
> sum(cost),
> on=customerId
>   ),
>   q="sum(cost):[500 TO *]"
> )
> {code}
> This example would return all where the total spent by each distinct customer 
> is >= 500. The total spent is calculated via the sum(cost) metric in the 
> reduce stream.
> The intent is to support as the filters in the having(...) clause the full 
> query syntax of a search(...) clause. I see this being possible in one of two 
> ways. 
> 1. Use Lucene's MemoryIndex and as each tuple is read out of the underlying 
> stream creating an instance of MemoryIndex and apply the query to it. If the 
> result of that is >0 then the tuple should be returned from the HavingStream.
> 2. Create an in-memory solr index via something like RamDirectory, read all 
> tuples into that in-memory index using the UpdateStream, and then stream out 
> of that all the matching tuples from the query.
> There are benefits to each approach but I think the easiest and most direct 
> one is the MemoryIndex approach. With MemoryIndex it isn't necessary to read 
> all incoming tuples before returning a single tuple. With a MemoryIndex there 
> is a need to parse the solr query parameters and create a valid Lucene query 
> but I suspect that can be done using existing QParser implementations.



--
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-8530) Add HavingStream to Streaming API and StreamingExpressions

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090073#comment-15090073
 ] 

Joel Bernstein edited comment on SOLR-8530 at 1/8/16 10:28 PM:
---

Is there a specific reason to use an index for the comparison logic? We could 
also add a ComparisonOperator interface and implement the basic comparison 
logic. 


was (Author: joel.bernstein):
Is there a specific reason to use an index for the comparison logic? We could 
also add a ComparisonOperator interface and implements the basic comparison 
logic. 

> Add HavingStream to Streaming API and StreamingExpressions
> --
>
> Key: SOLR-8530
> URL: https://issues.apache.org/jira/browse/SOLR-8530
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
>
> The goal here is to support something similar to SQL's HAVING clause where 
> one can filter documents based on data that is not available in the index. 
> For example, filter the output of a reduce() based on the calculated 
> metrics.
> {code}
> having(
>   reduce(
> search(.),
> sum(cost),
> on=customerId
>   ),
>   q="sum(cost):[500 TO *]"
> )
> {code}
> This example would return all where the total spent by each distinct customer 
> is >= 500. The total spent is calculated via the sum(cost) metric in the 
> reduce stream.
> The intent is to support as the filters in the having(...) clause the full 
> query syntax of a search(...) clause. I see this being possible in one of two 
> ways. 
> 1. Use Lucene's MemoryIndex and as each tuple is read out of the underlying 
> stream creating an instance of MemoryIndex and apply the query to it. If the 
> result of that is >0 then the tuple should be returned from the HavingStream.
> 2. Create an in-memory solr index via something like RamDirectory, read all 
> tuples into that in-memory index using the UpdateStream, and then stream out 
> of that all the matching tuples from the query.
> There are benefits to each approach but I think the easiest and most direct 
> one is the MemoryIndex approach. With MemoryIndex it isn't necessary to read 
> all incoming tuples before returning a single tuple. With a MemoryIndex there 
> is a need to parse the solr query parameters and create a valid Lucene query 
> but I suspect that can be done using existing QParser implementations.



--
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-8530) Add HavingStream to Streaming API and StreamingExpressions

[Dennis Gove (JIRA)]

Dennis Gove created SOLR-8530:
-

 Summary: Add HavingStream to Streaming API and StreamingExpressions
 Key: SOLR-8530
 URL: https://issues.apache.org/jira/browse/SOLR-8530
 Project: Solr
  Issue Type: Improvement
  Components: SolrJ
Affects Versions: Trunk
Reporter: Dennis Gove
Priority: Minor


The goal here is to support something similar to SQL's HAVING clause where one 
can filter documents based on data that is not available in the index. For 
example, filter the output of a reduce() based on the calculated metrics.

{code}
having(
  reduce(
search(.),
sum(cost),
on=customerId
  ),
  q="sum(cost):[500 TO *]"
)
{code}

This example would return all where the total spent by each distinct customer 
is >= 500. The total spent is calculated via the sum(cost) metric in the reduce 
stream.

The intent is to support as the filters in the having(...) clause the full 
query syntax of a search(...) clause. I see this being possible in one of two 
ways. 

1. Use Lucene's MemoryIndex and as each tuple is read out of the underlying 
stream creating an instance of MemoryIndex and apply the query to it. If the 
result of that is >0 then the tuple should be returned from the HavingStream.

2. Create an in-memory solr index via something like RamDirectory, read all 
tuples into that in-memory index using the UpdateStream, and then stream out of 
that all the matching tuples from the query.

There are benefits to each approach but I think the easiest and most direct one 
is the MemoryIndex approach. With MemoryIndex it isn't necessary to read all 
incoming tuples before returning a single tuple. With a MemoryIndex there is a 
need to parse the solr query parameters and create a valid Lucene query but I 
suspect that can be done using existing QParser implementations.



--
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-6948) ArrayIndexOutOfBoundsException in PagedBytes$Reader.fill

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090042#comment-15090042
 ] 

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

Commit 1723810 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1723810 ]

LUCENE-6948: Fix ArrayIndexOutOfBoundsException in PagedBytes$Reader.fill by 
removing an unnecessary long-to-int cast. Also, unrelated, 2 
ArrayList<>(initialCapacity) tweaks in getChildResources methods. (merge in 
revision 1723787 from trunk)

> ArrayIndexOutOfBoundsException in PagedBytes$Reader.fill
> 
>
> Key: LUCENE-6948
> URL: https://issues.apache.org/jira/browse/LUCENE-6948
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 4.10.4
>Reporter: Michael Lawley
>Assignee: Christine Poerschke
> Attachments: LUCENE-6948.patch
>
>
> With a very large index (in our case > 10G), we are seeing exceptions like:
> java.lang.ArrayIndexOutOfBoundsException: -62400
>   at org.apache.lucene.util.PagedBytes$Reader.fill(PagedBytes.java:116)
>   at 
> org.apache.lucene.search.FieldCacheImpl$BinaryDocValuesImpl$1.get(FieldCacheImpl.java:1342)
>   at 
> org.apache.lucene.search.join.TermsCollector$SV.collect(TermsCollector.java:106)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:193)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:309)
> The code in question is trying to allocate an array with a negative size.  We 
> believe the source of the error is in 
> org.apache.lucene.search.FieldCacheImpl$BinaryDocValuesImpl$1.get where the 
> following code occurs:
>   final int pointer = (int) docToOffset.get(docID);
>   if (pointer == 0) {
> term.length = 0;
>   } else {
> bytes.fill(term, pointer);
>   }
> The cast to int will break if the (long) result of docToOffset.get is too 
> large, and is unnecessary in the first place since bytes.fill takes a long as 
> its second parameter.
> Proposed fix:
>   final long pointer = docToOffset.get(docID);
>   if (pointer == 0) {
> term.length = 0;
>   } else {
> bytes.fill(term, pointer);
>   }



--
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-6948) ArrayIndexOutOfBoundsException in PagedBytes$Reader.fill

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved LUCENE-6948.
-
   Resolution: Fixed
Fix Version/s: Trunk
   5.5

[~mjlawley] - thanks for the JIRA ticket and proposed fix. [~mikemccand] - 
thanks for the patch review.

> ArrayIndexOutOfBoundsException in PagedBytes$Reader.fill
> 
>
> Key: LUCENE-6948
> URL: https://issues.apache.org/jira/browse/LUCENE-6948
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 4.10.4
>Reporter: Michael Lawley
>Assignee: Christine Poerschke
> Fix For: 5.5, Trunk
>
> Attachments: LUCENE-6948.patch
>
>
> With a very large index (in our case > 10G), we are seeing exceptions like:
> java.lang.ArrayIndexOutOfBoundsException: -62400
>   at org.apache.lucene.util.PagedBytes$Reader.fill(PagedBytes.java:116)
>   at 
> org.apache.lucene.search.FieldCacheImpl$BinaryDocValuesImpl$1.get(FieldCacheImpl.java:1342)
>   at 
> org.apache.lucene.search.join.TermsCollector$SV.collect(TermsCollector.java:106)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:193)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:309)
> The code in question is trying to allocate an array with a negative size.  We 
> believe the source of the error is in 
> org.apache.lucene.search.FieldCacheImpl$BinaryDocValuesImpl$1.get where the 
> following code occurs:
>   final int pointer = (int) docToOffset.get(docID);
>   if (pointer == 0) {
> term.length = 0;
>   } else {
> bytes.fill(term, pointer);
>   }
> The cast to int will break if the (long) result of docToOffset.get is too 
> large, and is unnecessary in the first place since bytes.fill takes a long as 
> its second parameter.
> Proposed fix:
>   final long pointer = docToOffset.get(docID);
>   if (pointer == 0) {
> term.length = 0;
>   } else {
> bytes.fill(term, pointer);
>   }



--
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-8530) Add HavingStream to Streaming API and StreamingExpressions

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090073#comment-15090073
 ] 

Joel Bernstein edited comment on SOLR-8530 at 1/8/16 10:37 PM:
---

Is there a specific reason to use an index for the comparison logic? We could 
also add a ComparisonOperation interface and implement the basic comparison 
logic. 

{code}

having(reduce(), gt("x", 100))

{code}

And with boolean operators

{code}
having(rollup(), or(gt("x", 100), lt("x", 500)))
{code}


was (Author: joel.bernstein):
Is there a specific reason to use an index for the comparison logic? We could 
also add a ComparisonOperator interface and implement the basic comparison 
logic. 

{code}

having(reduce(), gt("x", 100))

{code}

And with boolean operators

{code}
having(rollup(), or(gt("x", 100), lt("x", 500)))
{code}

> Add HavingStream to Streaming API and StreamingExpressions
> --
>
> Key: SOLR-8530
> URL: https://issues.apache.org/jira/browse/SOLR-8530
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
>
> The goal here is to support something similar to SQL's HAVING clause where 
> one can filter documents based on data that is not available in the index. 
> For example, filter the output of a reduce() based on the calculated 
> metrics.
> {code}
> having(
>   reduce(
> search(.),
> sum(cost),
> on=customerId
>   ),
>   q="sum(cost):[500 TO *]"
> )
> {code}
> This example would return all where the total spent by each distinct customer 
> is >= 500. The total spent is calculated via the sum(cost) metric in the 
> reduce stream.
> The intent is to support as the filters in the having(...) clause the full 
> query syntax of a search(...) clause. I see this being possible in one of two 
> ways. 
> 1. Use Lucene's MemoryIndex and as each tuple is read out of the underlying 
> stream creating an instance of MemoryIndex and apply the query to it. If the 
> result of that is >0 then the tuple should be returned from the HavingStream.
> 2. Create an in-memory solr index via something like RamDirectory, read all 
> tuples into that in-memory index using the UpdateStream, and then stream out 
> of that all the matching tuples from the query.
> There are benefits to each approach but I think the easiest and most direct 
> one is the MemoryIndex approach. With MemoryIndex it isn't necessary to read 
> all incoming tuples before returning a single tuple. With a MemoryIndex there 
> is a need to parse the solr query parameters and create a valid Lucene query 
> but I suspect that can be done using existing QParser implementations.



--
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-8530) Add HavingStream to Streaming API and StreamingExpressions

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090089#comment-15090089
 ] 

Joel Bernstein edited comment on SOLR-8530 at 1/8/16 10:38 PM:
---

Then we could also throw away the HavingStream that comes with the SQLHandler 
which relies on Presto classes. 


was (Author: joel.bernstein):
Then I could also throw away the HavingStream that comes with the SQLHandler 
which relies on Presto classes. 

> Add HavingStream to Streaming API and StreamingExpressions
> --
>
> Key: SOLR-8530
> URL: https://issues.apache.org/jira/browse/SOLR-8530
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
>
> The goal here is to support something similar to SQL's HAVING clause where 
> one can filter documents based on data that is not available in the index. 
> For example, filter the output of a reduce() based on the calculated 
> metrics.
> {code}
> having(
>   reduce(
> search(.),
> sum(cost),
> on=customerId
>   ),
>   q="sum(cost):[500 TO *]"
> )
> {code}
> This example would return all where the total spent by each distinct customer 
> is >= 500. The total spent is calculated via the sum(cost) metric in the 
> reduce stream.
> The intent is to support as the filters in the having(...) clause the full 
> query syntax of a search(...) clause. I see this being possible in one of two 
> ways. 
> 1. Use Lucene's MemoryIndex and as each tuple is read out of the underlying 
> stream creating an instance of MemoryIndex and apply the query to it. If the 
> result of that is >0 then the tuple should be returned from the HavingStream.
> 2. Create an in-memory solr index via something like RamDirectory, read all 
> tuples into that in-memory index using the UpdateStream, and then stream out 
> of that all the matching tuples from the query.
> There are benefits to each approach but I think the easiest and most direct 
> one is the MemoryIndex approach. With MemoryIndex it isn't necessary to read 
> all incoming tuples before returning a single tuple. With a MemoryIndex there 
> is a need to parse the solr query parameters and create a valid Lucene query 
> but I suspect that can be done using existing QParser implementations.



--
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-8500) Allow the number of threads ConcurrentUpdateSolrClient StreamingSolrClients configurable by a system property

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-8500:
-
Summary: Allow the number of threads ConcurrentUpdateSolrClient 
StreamingSolrClients configurable by a system property  (was: Allow the number 
of threds ConcurrentUpdateSolrClient StreamingSolrClients configurable by a 
system property)

> Allow the number of threads ConcurrentUpdateSolrClient StreamingSolrClients 
> configurable by a system property
> -
>
> Key: SOLR-8500
> URL: https://issues.apache.org/jira/browse/SOLR-8500
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Priority: Minor
> Attachments: SOLR-8500.patch
>
>
> Despite the warning in that code, in extremely high throughput situations 
> where there are guaranteed to be no updates to existing documents, it can be 
> useful to have more than one runner.
> I envision this as an "expert" kind of thing, used only in situations where 
> the a-priori knowledge is that there are no updates to existing documents.



--
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-6966) Contribution: Codec for index-level encryption

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089614#comment-15089614
 ] 

Robert Muir commented on LUCENE-6966:
-

https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2009/july/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/

I am not sure where some of these ideas like "postings lists don't need to be 
encrypted" came from, but most of the design presented on this issue is 
completely insecure. Please, if you want to do this stuff in lucene, it needs 
to be a standardized scheme (like XTS or ESSIV) with all the known tradeoffs 
already computed. You can be 100% sure that if "crypto is invented here" that 
I'm gonna make comments on the issue, because it is the right thing to do.

The many justifications for doing it in a complicated way in the codec level 
seems to revolve around limitations in solrcloud, rather than from good design. 
Because you really can put different indexes in different directories and let 
the operating system do it for "multitenancy". Because Lucene has stuff like 
ParallelReader and different fields can be in different indexes if you really 
need that, etc, etc. Alternative everywhere which would allow you to still "let 
the OS do it", be secure, and have a working filesystem cache (be fast).



> Contribution: Codec for index-level encryption
> --
>
> Key: LUCENE-6966
> URL: https://issues.apache.org/jira/browse/LUCENE-6966
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/other
>Reporter: Renaud Delbru
>  Labels: codec, contrib
>
> We would like to contribute a codec that enables the encryption of sensitive 
> data in the index that has been developed as part of an engagement with a 
> customer. We think that this could be of interest for the community.
> Below is a description of the project.
> h1. Introduction
> In comparison with approaches where all data is encrypted (e.g., file system 
> encryption, index output / directory encryption), encryption at a codec level 
> enables more fine-grained control on which block of data is encrypted. This 
> is more efficient since less data has to be encrypted. This also gives more 
> flexibility such as the ability to select which field to encrypt.
> Some of the requirements for this project were:
> * The performance impact of the encryption should be reasonable.
> * The user can choose which field to encrypt.
> * Key management: During the life cycle of the index, the user can provide a 
> new version of his encryption key. Multiple key versions should co-exist in 
> one index.
> h1. What is supported ?
> - Block tree terms index and dictionary
> - Compressed stored fields format
> - Compressed term vectors format
> - Doc values format (prototype based on an encrypted index output) - this 
> will be submitted as a separated patch
> - Index upgrader: command to upgrade all the index segments with the latest 
> key version available.
> h1. How it is implemented ?
> h2. Key Management
> One index segment is encrypted with a single key version. An index can have 
> multiple segments, each one encrypted using a different key version. The key 
> version for a segment is stored in the segment info.
> The provided codec is abstract, and a subclass is responsible in providing an 
> implementation of the cipher factory. The cipher factory is responsible of 
> the creation of a cipher instance based on a given key version.
> h2. Encryption Model
> The encryption model is based on AES/CBC with padding. Initialisation vector 
> (IV) is reused for performance reason, but only on a per format and per 
> segment basis.
> While IV reuse is usually considered a bad practice, the CBC mode is somehow 
> resilient to IV reuse. The only "leak" of information that this could lead to 
> is being able to know that two encrypted blocks of data starts with the same 
> prefix. However, it is unlikely that two data blocks in an index segment will 
> start with the same data:
> - Stored Fields Format: Each encrypted data block is a compressed block 
> (~4kb) of one or more documents. It is unlikely that two compressed blocks 
> start with the same data prefix.
> - Term Vectors: Each encrypted data block is a compressed block (~4kb) of 
> terms and payloads from one or more documents. It is unlikely that two 
> compressed blocks start with the same data prefix.
> - Term Dictionary Index: The term dictionary index is encoded and encrypted 
> in one single data block.
> - Term Dictionary Data: Each data block of the term dictionary encodes a set 
> of suffixes. It is unlikely to have two dictionary data blocks sharing the 
> same prefix within the same segment.
> - DocValues: A DocValues file will be composed of multiple encrypted data 
> blocks. It is unlikely 

filter documents from solr index

[liviuchristian]

Hi everyone, I'm working on a search engine based on solr which indexes 
documents from a large variety of websites. 
The engine is focused on cook recipes. However, one problem is that these 
websites provide not only content related to cooking recipes but also content 
related to: fashion, travel, politics, liberty rights etc etc which are not 
what the user expects to find on a cooking recipes dedicated search engine. 
Is there any way to filter out content which is not related to the core 
business of the search engine?
Something like parental control software maybe?
Kind regards,Christian Christian Fotache Tel: 0728.297.207 Fax: 0351.411.570

[jira] [Commented] (LUCENE-6962) Add per-dimension min/max to dimensional values

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089050#comment-15089050
 ] 

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

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

LUCENE-6962: add min/max per dimension to dimensional values

> Add per-dimension min/max to dimensional values
> ---
>
> Key: LUCENE-6962
> URL: https://issues.apache.org/jira/browse/LUCENE-6962
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk
>
> Attachments: LUCENE-6962.patch
>
>
> It can be useful for apps to know the min/max value for a given field
> for each dimension, to give the global bounding box.  E.g. an app can
> know that a given range filter excludes all documents in a
> segment/index and skip searching it.



--
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-6962) Add per-dimension min/max to dimensional values

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-6962.

Resolution: Fixed

> Add per-dimension min/max to dimensional values
> ---
>
> Key: LUCENE-6962
> URL: https://issues.apache.org/jira/browse/LUCENE-6962
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk
>
> Attachments: LUCENE-6962.patch
>
>
> It can be useful for apps to know the min/max value for a given field
> for each dimension, to give the global bounding box.  E.g. an app can
> know that a given range filter excludes all documents in a
> segment/index and skip searching it.



--
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-8504) (IndexSchema|SolrIndexConfig)Test: private static finals for solrconfig.xml and schema.xml String literals

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089069#comment-15089069
 ] 

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

Commit 1723687 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1723687 ]

SOLR-8504: (IndexSchema|SolrIndexConfig)Test: private static finals for 
solrconfig.xml and schema.xml String literals

> (IndexSchema|SolrIndexConfig)Test: private static finals for solrconfig.xml 
> and schema.xml String literals
> --
>
> Key: SOLR-8504
> URL: https://issues.apache.org/jira/browse/SOLR-8504
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8504.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

[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_66) - Build # 15184 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15184/
Java: 64bit/jdk1.8.0_66 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
Error from server at http://127.0.0.1:41079/lxa/routeFieldColl: non ok status: 
500, message:Server Error

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:41079/lxa/routeFieldColl: non ok status: 500, 
message:Server Error
at 
__randomizedtesting.SeedInfo.seed([44C57313AFCAC55C:CC914CC90136A8A4]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:509)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:174)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:139)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:153)
at 
org.apache.solr.cloud.ShardSplitTest.splitByRouteFieldTest(ShardSplitTest.java:263)
at org.apache.solr.cloud.ShardSplitTest.test(ShardSplitTest.java:83)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS] Lucene-Solr-NightlyTests-5.3 - Build # 8 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.3/8/

4 tests failed.
FAILED:  
org.apache.lucene.codecs.asserting.TestAssertingStoredFieldsFormat.testRamBytesUsed

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([C27A75535BA21309]:0)


FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.asserting.TestAssertingStoredFieldsFormat

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

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


FAILED:  
org.apache.lucene.codecs.asserting.TestAssertingTermVectorsFormat.testRamBytesUsed

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([C27A75535BA21309]:0)


FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.asserting.TestAssertingTermVectorsFormat

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

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




Build Log:
[...truncated 2756 lines...]
   [junit4] Suite: 
org.apache.lucene.codecs.asserting.TestAssertingStoredFieldsFormat
   [junit4]   2> NOTE: download the large Jenkins line-docs file by running 
'ant get-jenkins-line-docs' in the lucene directory.
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestAssertingStoredFieldsFormat -Dtests.method=testRamBytesUsed 
-Dtests.seed=C27A75535BA21309 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/x1/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=sr_RS -Dtests.timezone=America/Indiana/Knox -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   7200s J2 | TestAssertingStoredFieldsFormat.testRamBytesUsed 
<<<
   [junit4]> Throwable #1: java.lang.Exception: Test abandoned because 
suite timeout was reached.
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([C27A75535BA21309]:0)
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene53): {}, 
docValues:{}, sim=DefaultSimilarity, locale=sr_RS, timezone=America/Indiana/Knox
   [junit4]   2> NOTE: Linux 3.13.0-52-generic amd64/Oracle Corporation 
1.7.0_80 (64-bit)/cpus=4,threads=2,free=223203152,total=408420352
   [junit4]   2> NOTE: All tests run in this JVM: [Nested, Nested, Nested, 
Nested, Nested, Nested, Nested, Nested, Nested, Nested, Nested, Nested, Nested, 
Nested, Nested, Nested, Nested, Nested, Nested, Nested, Nested, 
TestLookaheadTokenFilter, Nested2, Nested, TestShuffleFS, 
TestAssertingNormsFormat, TestGroupFiltering, Nested1, 
TestAssertingStoredFieldsFormat]
   [junit4]   2> NOTE: download the large Jenkins line-docs file by running 
'ant get-jenkins-line-docs' in the lucene directory.
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestAssertingStoredFieldsFormat -Dtests.seed=C27A75535BA21309 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/x1/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=sr_RS -Dtests.timezone=America/Indiana/Knox -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.00s J2 | TestAssertingStoredFieldsFormat (suite) <<<
   [junit4]> Throwable #1: java.lang.Exception: Suite timeout exceeded (>= 
720 msec).
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([C27A75535BA21309]:0)
   [junit4] Completed [37/38] on J2 in 7223.39s, 6 tests, 2 errors <<< FAILURES!

[...truncated 17 lines...]
   [junit4] Suite: 
org.apache.lucene.codecs.asserting.TestAssertingTermVectorsFormat
   [junit4]   2> ?.?. 08, 2016 11:32:54 ?? 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
   [junit4]   2> WARNING: Suite execution timed out: 
org.apache.lucene.codecs.asserting.TestAssertingTermVectorsFormat
   [junit4]   2>1) Thread[id=9, name=JUnit4-serializer-daemon, 
state=TIMED_WAITING, group=main]
   [junit4]   2> at java.lang.Thread.sleep(Native Method)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.events.Serializer$1.run(Serializer.java:47)
   [junit4]   2>2) Thread[id=236, 
name=TEST-TestAssertingTermVectorsFormat.testRamBytesUsed-seed#[C27A75535BA21309],
 state=RUNNABLE, group=TGRP-TestAssertingTermVectorsFormat]
   [junit4]   2> at 
org.apache.lucene.store.MockIndexInputWrapper.readByte(MockIndexInputWrapper.java:132)
   [junit4]   2> at 
org.apache.lucene.util.packed.BlockPackedReaderIterator.skip(BlockPackedReaderIterator.java:126)
   [junit4]   2> at 
org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.readPositions(CompressingTermVectorsReader.java:637)
   [junit4]   2> at 

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica2","base_url":"http://127.0.0.1:45030/n_/hp","node_name":"127.0.0.1:45030_n_%2Fhp","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={   "replicationFactor":"3",   
"shards":{"shard1":{   "range":"8000-7fff",   "state":"active", 
  "replicas":{ "core_node1":{   "state":"down",   
"base_url":"http://127.0.0.1:51924/n_/hp;,   
"core":"c8n_1x3_lf_shard1_replica3",   
"node_name":"127.0.0.1:51924_n_%2Fhp"}, "core_node2":{   
"core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:64073/n_/hp;,   
"node_name":"127.0.0.1:64073_n_%2Fhp",   "state":"down"}, 
"core_node3":{   "core":"c8n_1x3_lf_shard1_replica2",   
"base_url":"http://127.0.0.1:45030/n_/hp;,   
"node_name":"127.0.0.1:45030_n_%2Fhp",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica2","base_url":"http://127.0.0.1:45030/n_/hp","node_name":"127.0.0.1:45030_n_%2Fhp","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "state":"down",
  "base_url":"http://127.0.0.1:51924/n_/hp;,
  "core":"c8n_1x3_lf_shard1_replica3",
  "node_name":"127.0.0.1:51924_n_%2Fhp"},
"core_node2":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:64073/n_/hp;,
  "node_name":"127.0.0.1:64073_n_%2Fhp",
  "state":"down"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica2",
  "base_url":"http://127.0.0.1:45030/n_/hp;,
  "node_name":"127.0.0.1:45030_n_%2Fhp",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([6F91588C79C30CE:8EAD2A5269605D36]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:171)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:56)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+95) - Build # 15491 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15491/
Java: 32bit/jdk-9-ea+95 -server -XX:+UseG1GC -XX:-CompactStrings

1 tests failed.
FAILED:  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:44615;, 
"node_name":"127.0.0.1:44615_", "state":"active", 
"leader":"true"}}},   "shard2":{ "range":"0-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"collection1", "base_url":"http://127.0.0.1:57383;,  
   "node_name":"127.0.0.1:57383_", "state":"active", 
"leader":"true"},   "core_node3":{ "core":"collection1",
 "base_url":"http://127.0.0.1:54432;, 
"node_name":"127.0.0.1:54432_", "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:37655;, 
"node_name":"127.0.0.1:37655_", "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_replica1", 
"base_url":"http://127.0.0.1:57383;, 
"node_name":"127.0.0.1:57383_", "state":"active", 
"leader":"true"},   "core_node2":{ 
"core":"c8n_1x2_shard1_replica2", 
"base_url":"http://127.0.0.1:37655;, 
"node_name":"127.0.0.1:37655_", "state":"recovering", 
"router":{"name":"compositeId"}, "maxShardsPerNode":"1", 
"autoAddReplicas":"false"},   "collMinRf_1x3":{ "replicationFactor":"3",
 "shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"collMinRf_1x3_shard1_replica1", 
"base_url":"http://127.0.0.1:44615;, 
"node_name":"127.0.0.1:44615_", "state":"active"},   
"core_node2":{ "core":"collMinRf_1x3_shard1_replica2", 
"base_url":"http://127.0.0.1:37655;, 
"node_name":"127.0.0.1:37655_", "state":"active"},   
"core_node3":{ "core":"collMinRf_1x3_shard1_replica3", 
"base_url":"http://127.0.0.1:57383;, 
"node_name":"127.0.0.1:57383_", "state":"active", 
"leader":"true", "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:44615;,
"node_name":"127.0.0.1:44615_",
"state":"active",
"leader":"true"}}},
  "shard2":{
"range":"0-7fff",
"state":"active",
"replicas":{
  "core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:57383;,
"node_name":"127.0.0.1:57383_",
"state":"active",
"leader":"true"},
  "core_node3":{
"core":"collection1",
"base_url":"http://127.0.0.1:54432;,
"node_name":"127.0.0.1:54432_",
"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:37655;,
"node_name":"127.0.0.1:37655_",
"state":"active",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",

[JENKINS] Lucene-Solr-SmokeRelease-5.3 - Build # 10 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.3/10/

No tests ran.

Build Log:
[...truncated 53068 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (13.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.3.2-src.tgz...
   [smoker] 28.5 MB in 0.03 sec (814.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.3.2.tgz...
   [smoker] 65.7 MB in 0.08 sec (804.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.3.2.zip...
   [smoker] 75.9 MB in 0.09 sec (806.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.3.2.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6059 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6059 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.3.2.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6059 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6059 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.3.2-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker]   5.4.0
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/dev-tools/scripts/smokeTestRelease.py",
 line 1449, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/dev-tools/scripts/smokeTestRelease.py",
 line 1394, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/dev-tools/scripts/smokeTestRelease.py",
 line 1432, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, svnRevision, version, testArgs, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/dev-tools/scripts/smokeTestRelease.py",
 line 583, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
svnRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/dev-tools/scripts/smokeTestRelease.py",
 line 762, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.3/dev-tools/scripts/smokeTestRelease.py",
 line 1387, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 

[jira] [Comment Edited] (SOLR-8530) Add HavingStream to Streaming API and StreamingExpressions

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090073#comment-15090073
 ] 

Joel Bernstein edited comment on SOLR-8530 at 1/8/16 10:31 PM:
---

Is there a specific reason to use an index for the comparison logic? We could 
also add a ComparisonOperator interface and implement the basic comparison 
logic. 

{code}

having(reduce(), gt("x", 100))

{code}

And with boolean operators

{code}
having(reduce(), or(gt("x", 100), lt("x", 500)))
{code}


was (Author: joel.bernstein):
Is there a specific reason to use an index for the comparison logic? We could 
also add a ComparisonOperator interface and implement the basic comparison 
logic. 

{code}

having(reduce(), gt("x", 100))

{code}

> Add HavingStream to Streaming API and StreamingExpressions
> --
>
> Key: SOLR-8530
> URL: https://issues.apache.org/jira/browse/SOLR-8530
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
>
> The goal here is to support something similar to SQL's HAVING clause where 
> one can filter documents based on data that is not available in the index. 
> For example, filter the output of a reduce() based on the calculated 
> metrics.
> {code}
> having(
>   reduce(
> search(.),
> sum(cost),
> on=customerId
>   ),
>   q="sum(cost):[500 TO *]"
> )
> {code}
> This example would return all where the total spent by each distinct customer 
> is >= 500. The total spent is calculated via the sum(cost) metric in the 
> reduce stream.
> The intent is to support as the filters in the having(...) clause the full 
> query syntax of a search(...) clause. I see this being possible in one of two 
> ways. 
> 1. Use Lucene's MemoryIndex and as each tuple is read out of the underlying 
> stream creating an instance of MemoryIndex and apply the query to it. If the 
> result of that is >0 then the tuple should be returned from the HavingStream.
> 2. Create an in-memory solr index via something like RamDirectory, read all 
> tuples into that in-memory index using the UpdateStream, and then stream out 
> of that all the matching tuples from the query.
> There are benefits to each approach but I think the easiest and most direct 
> one is the MemoryIndex approach. With MemoryIndex it isn't necessary to read 
> all incoming tuples before returning a single tuple. With a MemoryIndex there 
> is a need to parse the solr query parameters and create a valid Lucene query 
> but I suspect that can be done using existing QParser implementations.



--
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-8530) Add HavingStream to Streaming API and StreamingExpressions

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090073#comment-15090073
 ] 

Joel Bernstein edited comment on SOLR-8530 at 1/8/16 10:29 PM:
---

Is there a specific reason to use an index for the comparison logic? We could 
also add a ComparisonOperator interface and implement the basic comparison 
logic. 

{code}

having(reduce(), gt("x", 100))

{code}


was (Author: joel.bernstein):
Is there a specific reason to use an index for the comparison logic? We could 
also add a ComparisonOperator interface and implement the basic comparison 
logic. 

> Add HavingStream to Streaming API and StreamingExpressions
> --
>
> Key: SOLR-8530
> URL: https://issues.apache.org/jira/browse/SOLR-8530
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
>
> The goal here is to support something similar to SQL's HAVING clause where 
> one can filter documents based on data that is not available in the index. 
> For example, filter the output of a reduce() based on the calculated 
> metrics.
> {code}
> having(
>   reduce(
> search(.),
> sum(cost),
> on=customerId
>   ),
>   q="sum(cost):[500 TO *]"
> )
> {code}
> This example would return all where the total spent by each distinct customer 
> is >= 500. The total spent is calculated via the sum(cost) metric in the 
> reduce stream.
> The intent is to support as the filters in the having(...) clause the full 
> query syntax of a search(...) clause. I see this being possible in one of two 
> ways. 
> 1. Use Lucene's MemoryIndex and as each tuple is read out of the underlying 
> stream creating an instance of MemoryIndex and apply the query to it. If the 
> result of that is >0 then the tuple should be returned from the HavingStream.
> 2. Create an in-memory solr index via something like RamDirectory, read all 
> tuples into that in-memory index using the UpdateStream, and then stream out 
> of that all the matching tuples from the query.
> There are benefits to each approach but I think the easiest and most direct 
> one is the MemoryIndex approach. With MemoryIndex it isn't necessary to read 
> all incoming tuples before returning a single tuple. With a MemoryIndex there 
> is a need to parse the solr query parameters and create a valid Lucene query 
> but I suspect that can be done using existing QParser implementations.



--
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-8530) Add HavingStream to Streaming API and StreamingExpressions

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15090089#comment-15090089
 ] 

Joel Bernstein commented on SOLR-8530:
--

Then I could also throw away the HavingStream that comes with the SQLHandler 
which relies on Presto classes. 

> Add HavingStream to Streaming API and StreamingExpressions
> --
>
> Key: SOLR-8530
> URL: https://issues.apache.org/jira/browse/SOLR-8530
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
>
> The goal here is to support something similar to SQL's HAVING clause where 
> one can filter documents based on data that is not available in the index. 
> For example, filter the output of a reduce() based on the calculated 
> metrics.
> {code}
> having(
>   reduce(
> search(.),
> sum(cost),
> on=customerId
>   ),
>   q="sum(cost):[500 TO *]"
> )
> {code}
> This example would return all where the total spent by each distinct customer 
> is >= 500. The total spent is calculated via the sum(cost) metric in the 
> reduce stream.
> The intent is to support as the filters in the having(...) clause the full 
> query syntax of a search(...) clause. I see this being possible in one of two 
> ways. 
> 1. Use Lucene's MemoryIndex and as each tuple is read out of the underlying 
> stream creating an instance of MemoryIndex and apply the query to it. If the 
> result of that is >0 then the tuple should be returned from the HavingStream.
> 2. Create an in-memory solr index via something like RamDirectory, read all 
> tuples into that in-memory index using the UpdateStream, and then stream out 
> of that all the matching tuples from the query.
> There are benefits to each approach but I think the easiest and most direct 
> one is the MemoryIndex approach. With MemoryIndex it isn't necessary to read 
> all incoming tuples before returning a single tuple. With a MemoryIndex there 
> is a need to parse the solr query parameters and create a valid Lucene query 
> but I suspect that can be done using existing QParser implementations.



--
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-EA] Lucene-Solr-5.x-Linux (64bit/jdk-9-ea+95) - Build # 15193 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15193/
Java: 64bit/jdk-9-ea+95 -XX:+UseCompressedOops -XX:+UseG1GC -XX:-CompactStrings

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.SaslZkACLProviderTest

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=10975, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)2) Thread[id=10974, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)3) Thread[id=10973, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)4) Thread[id=10972, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)5) Thread[id=10976, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=10975, name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at jdk.internal.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
at 

[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 2950 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2950/
Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
Mutual exclusion failed. Found more than one task running for the same 
collection

Stack Trace:
java.lang.AssertionError: Mutual exclusion failed. Found more than one task 
running for the same collection
at 
__randomizedtesting.SeedInfo.seed([3B170988B382A39:8BE54F4225C447C1]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.testTaskExclusivity(MultiThreadedOCPTest.java:136)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.test(MultiThreadedOCPTest.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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 

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

[Policeman Jenkins Server]

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

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

Error Message:
There are still nodes recoverying - waited for 30 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 30 
seconds
at 
__randomizedtesting.SeedInfo.seed([B74FFF96A9771418:3F1BC04C078B79E0]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:175)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:837)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1393)
at 
org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.test(DistribDocExpirationUpdateProcessorTest.java:73)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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] (LUCENE-6966) Contribution: Codec for index-level encryption

[Renaud Delbru (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089007#comment-15089007
 ] 

Renaud Delbru commented on LUCENE-6966:
---

I agree with you that if we add encryption to Lucene, it should always be 
secure. That's why I opened up the discussion with the commnunity in order to 
review and agree on which approach to adopt. 
With respect to IV reuse with CBC mode, a potential leak of information occurs 
when two messages share a common prefix, as it will reveal the presence and 
length of that prefix.
Now if we look at each format separately and at what type of messages is 
encrypted in each one, we can assess the risk:
- Term Dictionary Index: the entire term dictionary index in a segment will be 
encrypted as one single message - risk is null
- Term Dictionary Data: each suffixes bytes blob is encrypted as one message - 
I would assume that the probability of having two suffixes bytes blobs sharing 
the same prefix or being identical is pretty low. But I might be wrong.
- Stored Fields Format: each compressed doc chunk is encrypted as one message - 
a doc chunk can contain the exact same data (e.g., if multiple documents 
contain the same exact fields and values). This is more likely to happen but it 
sounds like more an edge case.
- Terms Vector: each compress terms and payloads bytes blob of doc chunk is 
encrypted as one message - same issue than with Stored Fields Format

The risk of reusing IV seems to reside in Stored Fields / Terms Vector is not 
acceptable, one solution is to add a random generated header to each compressed 
doc chunk that will serve as a unique IV. What do you think ?

> Contribution: Codec for index-level encryption
> --
>
> Key: LUCENE-6966
> URL: https://issues.apache.org/jira/browse/LUCENE-6966
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/other
>Reporter: Renaud Delbru
>  Labels: codec, contrib
>
> We would like to contribute a codec that enables the encryption of sensitive 
> data in the index that has been developed as part of an engagement with a 
> customer. We think that this could be of interest for the community.
> Below is a description of the project.
> h1. Introduction
> In comparison with approaches where all data is encrypted (e.g., file system 
> encryption, index output / directory encryption), encryption at a codec level 
> enables more fine-grained control on which block of data is encrypted. This 
> is more efficient since less data has to be encrypted. This also gives more 
> flexibility such as the ability to select which field to encrypt.
> Some of the requirements for this project were:
> * The performance impact of the encryption should be reasonable.
> * The user can choose which field to encrypt.
> * Key management: During the life cycle of the index, the user can provide a 
> new version of his encryption key. Multiple key versions should co-exist in 
> one index.
> h1. What is supported ?
> - Block tree terms index and dictionary
> - Compressed stored fields format
> - Compressed term vectors format
> - Doc values format (prototype based on an encrypted index output) - this 
> will be submitted as a separated patch
> - Index upgrader: command to upgrade all the index segments with the latest 
> key version available.
> h1. How it is implemented ?
> h2. Key Management
> One index segment is encrypted with a single key version. An index can have 
> multiple segments, each one encrypted using a different key version. The key 
> version for a segment is stored in the segment info.
> The provided codec is abstract, and a subclass is responsible in providing an 
> implementation of the cipher factory. The cipher factory is responsible of 
> the creation of a cipher instance based on a given key version.
> h2. Encryption Model
> The encryption model is based on AES/CBC with padding. Initialisation vector 
> (IV) is reused for performance reason, but only on a per format and per 
> segment basis.
> While IV reuse is usually considered a bad practice, the CBC mode is somehow 
> resilient to IV reuse. The only "leak" of information that this could lead to 
> is being able to know that two encrypted blocks of data starts with the same 
> prefix. However, it is unlikely that two data blocks in an index segment will 
> start with the same data:
> - Stored Fields Format: Each encrypted data block is a compressed block 
> (~4kb) of one or more documents. It is unlikely that two compressed blocks 
> start with the same data prefix.
> - Term Vectors: Each encrypted data block is a compressed block (~4kb) of 
> terms and payloads from one or more documents. It is unlikely that two 
> compressed blocks start with the same data prefix.
> - Term Dictionary Index: The term dictionary index is encoded and 

[jira] [Commented] (SOLR-8504) (IndexSchema|SolrIndexConfig)Test: private static finals for solrconfig.xml and schema.xml String literals

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089094#comment-15089094
 ] 

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

Commit 1723706 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1723706 ]

SOLR-8504: (IndexSchema|SolrIndexConfig)Test: private static finals for 
solrconfig.xml and schema.xml String literals (merge in revision 1723687 from 
trunk)

> (IndexSchema|SolrIndexConfig)Test: private static finals for solrconfig.xml 
> and schema.xml String literals
> --
>
> Key: SOLR-8504
> URL: https://issues.apache.org/jira/browse/SOLR-8504
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8504.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] [Updated] (SOLR-8522) ImplicitSnitch to support IPv4 based tags

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou updated SOLR-8522:
-
Attachment: SOLR-8522.patch

Initial patch for IPv4 tag support

> ImplicitSnitch to support IPv4 based tags
> -
>
> Key: SOLR-8522
> URL: https://issues.apache.org/jira/browse/SOLR-8522
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4
>Reporter: Arcadius Ahouansou
>Priority: Minor
> Attachments: SOLR-8522.patch
>
>
> This is a description from [~noble.paul]'s comment on SOLR-8146
> Lets assume a Solr node IPv4 address is 192.93.255.255 .
> This is about enhancing the current {{ImplicitSnitch}}  to support IP based 
> tags like:
> - {{ip_1 = 192}}
> - {{ip_2 = 93}}
> - {{ip_3 = 255}}
> - {{ip_4 = 255}}
> Note that IPv6 support will be implemented by a separate ticket



--
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-8492) Add LogisticRegressionQuery and LogitStream

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089149#comment-15089149
 ] 

Joel Bernstein commented on SOLR-8492:
--

I should have a chance to review the latest patch on this ticket over the next 
couple days.

> Add LogisticRegressionQuery and LogitStream
> ---
>
> Key: SOLR-8492
> URL: https://issues.apache.org/jira/browse/SOLR-8492
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
> Attachments: SOLR-8492.patch, SOLR-8492.patch, SOLR-8492.patch
>
>
> This ticket is to add a new query called a LogisticRegressionQuery (LRQ).
> The LRQ extends AnalyticsQuery 
> (http://joelsolr.blogspot.com/2015/12/understanding-solrs-analyticsquery.html)
>  and returns a DelegatingCollector that implements a Stochastic Gradient 
> Descent (SGD) optimizer for Logistic Regression.
> This ticket also adds the LogitStream which leverages Streaming Expressions 
> to provide iteration over the shards. Each call to LogitStream.read() calls 
> down to the shards and executes the LogisticRegressionQuery. The model data 
> is collected from the shards and the weights are averaged and sent back to 
> the shards with the next iteration. Each call to read() returns a Tuple with 
> the averaged weights and error from the shards. With this approach the 
> LogitStream streams the changing model back to the client after each 
> iteration.
> The LogitStream will return the EOF Tuple when it reaches the defined 
> maxIterations. When sent as a Streaming Expression to the Stream handler this 
> provides parallel iterative behavior. This same approach can be used to 
> implement other parallel iterative algorithms.
> The initial patch has  a test which simply tests the mechanics of the 
> iteration. More work will need to be done to ensure the SGD is properly 
> implemented. The distributed approach of the SGD will also need to be 
> reviewed.  
> This implementation is designed for use cases with a small number of features 
> because each feature is it's own discreet field.
> An implementation which supports a higher number of features would be 
> possible by packing features into a byte array and storing as binary 
> DocValues.
> This implementation is designed to support a large sample set. With a large 
> number of shards, a sample set into the billions may be possible.
> sample Streaming Expression Syntax:
> {code}
> logit(collection1, features="a,b,c,d,e,f" outcome="x" maxIterations="80")
> {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

Re: svn commit: r1723682 - in /lucene/dev/trunk/lucene: ./ codecs/src/java/org/apache/lucene/codecs/simpletext/ core/src/java/org/apache/lucene/codecs/ core/src/java/org/apache/lucene/codecs/lucene60/

[Michael McCandless]

Yes indeed, thanks for catching this Christine!  I'll fix ...

Mike McCandless

http://blog.mikemccandless.com


On Fri, Jan 8, 2016 at 8:22 AM, Christine Poerschke (BLOOMBERG/
LONDON)  wrote:
> Hello.
>
> Might there be a min-versus-max copy/paste mistake in getMaxPackedValue?
>
> I will try next to see if that fixes recent
> org.apache.lucene.index.TestDuelingCodecs test failures.
>
> Christine
>
> - Original Message -
> From: dev@lucene.apache.org
> To: comm...@lucene.apache.org
> At: Jan  8 2016 10:52:29
>
> Author: mikemccand
> Date: Fri Jan  8 10:52:15 2016
> New Revision: 1723682
>
> URL: http://svn.apache.org/viewvc?rev=1723682=rev
> Log:
> LUCENE-6962: add min/max per dimension to dimensional values
>
> Modified:
> lucene/dev/trunk/lucene/CHANGES.txt
> 
> lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextBKDReader.java
> 
> lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextDimensionalReader.java
> 
> lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextDimensionalWriter.java
> 
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/codecs/DimensionalFormat.java
> 
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/codecs/DimensionalWriter.java
> 
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/codecs/lucene60/Lucene60DimensionalReader.java
> 
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/DimensionalValues.java
> 
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/DimensionalValuesWriter.java
> 
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/MultiDimensionalValues.java
> 
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/ParallelLeafReader.java
> 
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/SlowCodecReaderWrapper.java
> 
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/util/bkd/BKDReader.java
> 
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/util/bkd/BKDWriter.java
> 
> lucene/dev/trunk/lucene/core/src/test/org/apache/lucene/index/TestDimensionalValues.java
> 
> lucene/dev/trunk/lucene/core/src/test/org/apache/lucene/util/bkd/TestBKD.java
> 
> lucene/dev/trunk/lucene/misc/src/java/org/apache/lucene/index/SortingLeafReader.java
> 
> lucene/dev/trunk/lucene/test-framework/src/java/org/apache/lucene/codecs/asserting/AssertingDimensionalFormat.java
>
> Modified: lucene/dev/trunk/lucene/CHANGES.txt
> URL: 
> http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/CHANGES.txt?rev=1723682=1723681=1723682=diff
> ==
> --- lucene/dev/trunk/lucene/CHANGES.txt (original)
> +++ lucene/dev/trunk/lucene/CHANGES.txt Fri Jan  8 10:52:15 2016
> @@ -55,6 +55,9 @@ New Features
>  * LUCENE-6837: Add N-best output support to JapaneseTokenizer.
>(Hiroharu Konno via Christian Moen)
>
> +* LUCENE-6962: Add per-dimension min/max to dimensional values
> +  (Mike McCandless)
> +
>  API Changes
>
>  * LUCENE-3312: The API of oal.document was restructured to
>
> Modified: 
> lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextBKDReader.java
> URL: 
> http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextBKDReader.java?rev=1723682=1723681=1723682=diff
> ==
> --- 
> lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextBKDReader.java
>  (original)
> +++ 
> lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextBKDReader.java
>  Fri Jan  8 10:52:15 2016
> @@ -33,8 +33,9 @@ import static org.apache.lucene.codecs.s
>
>  class SimpleTextBKDReader extends BKDReader {
>
> -  public SimpleTextBKDReader(IndexInput datIn, int numDims, int 
> maxPointsInLeafNode, int bytesPerDim, long[] leafBlockFPs, byte[] 
> splitPackedValues) throws IOException {
> -super(datIn, numDims, maxPointsInLeafNode, bytesPerDim, leafBlockFPs, 
> splitPackedValues);
> +  public SimpleTextBKDReader(IndexInput datIn, int numDims, int 
> maxPointsInLeafNode, int bytesPerDim, long[] leafBlockFPs, byte[] 
> splitPackedValues,
> + byte[] minPackedValue, byte[] maxPackedValue) 
> throws IOException {
> +super(datIn, numDims, maxPointsInLeafNode, bytesPerDim, leafBlockFPs, 
> splitPackedValues, minPackedValue, maxPackedValue);
>}
>
>@Override
>
> Modified: 
> lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextDimensionalReader.java
> URL: 
> http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextDimensionalReader.java?rev=1723682=1723681=1723682=diff
> 

[JENKINS] Lucene-Solr-5.x-Solaris (64bit/jdk1.8.0) - Build # 317 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Solaris/317/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.StressHdfsTest.test

Error Message:
Could not load collection from ZK: delete_data_dir

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
delete_data_dir
at 
__randomizedtesting.SeedInfo.seed([376832A856FD205D:BF3C0D72F8014DA5]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:962)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:523)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:190)
at 
org.apache.solr.common.cloud.ClusterState.hasCollection(ClusterState.java:120)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:834)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:896)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:859)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:874)
at 
org.apache.solr.cloud.hdfs.StressHdfsTest.createAndDeleteCollection(StressHdfsTest.java:191)
at 
org.apache.solr.cloud.hdfs.StressHdfsTest.test(StressHdfsTest.java:100)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:40)
at 

Re: Lucene/Solr 6.0.0 release

[Upayavira]

I'd like to see some visible improvements to the Solr UI before then.
Notably a "nodes" pane and a couple of others, so a timescale of "a few
months" would be great.

Upayavira

On Fri, Jan 8, 2016, at 02:34 PM, Noble Paul wrote:
> deprecating old API is not yet planned. both will co-exist.
> 
> 
> On Fri, Jan 8, 2016 at 7:33 PM, Jan Høydahl 
> wrote:
> > +1 for getting the ball rolling and decide a date for branch cutting...
> >
> > Regarding /v2/ api, isn’t the plan that the new api will co-exist with the 
> > old for some time?
> > If so, it would be acceptible to add the /v2/ API in 6.x and deprecate old 
> > api in 6.y?
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> >> 8. jan. 2016 kl. 14.38 skrev Noble Paul :
> >>
> >> I was planning to add SOLR-8029 ( Modernize and standardize Solr APIs) to 
> >> 6.0
> >>
> >> it is at least 2-3 months away. If the release is planned after
> >> march I would like to get that in.
> >>
> >> On Fri, Jan 8, 2016 at 1:10 PM, Dawid Weiss  wrote:
>  I think we should get the ball rolling for our next major release 
>  (6.0.0)?
> >>>
> >>> I'd love it to be the first git-based release. :)
> >>> It'd be a nice milestone change (from infrastructural point of view).
> >>> Not a blocker, of course.
> >>>
> >>> Dawid
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> -
> >> Noble Paul
> >>
> >> -
> >> 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
> >
> 
> 
> 
> -- 
> -
> Noble Paul
> 
> -
> 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] [Comment Edited] (SOLR-8522) ImplicitSnitch to support IPv4 based tags

[Arcadius Ahouansou (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089147#comment-15089147
 ] 

Arcadius Ahouansou edited comment on SOLR-8522 at 1/8/16 12:38 PM:
---

Hello [~noble.paul].
This is the initial patch for IPv4 tag support.
Please, let me know of any comment or suggestion you may have.

Thank you very much.


was (Author: arcadius):
Initial patch for IPv4 tag support

> ImplicitSnitch to support IPv4 based tags
> -
>
> Key: SOLR-8522
> URL: https://issues.apache.org/jira/browse/SOLR-8522
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4
>Reporter: Arcadius Ahouansou
>Priority: Minor
> Attachments: SOLR-8522.patch
>
>
> This is a description from [~noble.paul]'s comment on SOLR-8146
> Lets assume a Solr node IPv4 address is 192.93.255.255 .
> This is about enhancing the current {{ImplicitSnitch}}  to support IP based 
> tags like:
> - {{ip_1 = 192}}
> - {{ip_2 = 93}}
> - {{ip_3 = 255}}
> - {{ip_4 = 255}}
> Note that IPv6 support will be implemented by a separate ticket



--
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:[jira] [Updated] (LUCENE-6962) Add per-dimension min/max to dimensional values

[Christine Poerschke (BLOOMBERG/ LONDON)]

Apologies, meant to reply to the commits mailing list.

- Original Message -
From: dev@lucene.apache.org
To: dev@lucene.apache.org
At: Jan  8 2016 13:19:51

Hello.

Might there be a min-versus-max copy/paste mistake in getMaxPackedValue?

I will try next to see if that fixes recent 
org.apache.lucene.index.TestDuelingCodecs test failures.

Christine

- Original Message -
From: dev@lucene.apache.org
To: dev@lucene.apache.org
At: Jan  6 2016 09:31:49


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

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

Patch, adding APIs to get min/max values, and also getters for number
of dimensions and bytes per dimension, to {{DimensionalValues}}.


> Add per-dimension min/max to dimensional values
> ---
>
> Key: LUCENE-6962
> URL: https://issues.apache.org/jira/browse/LUCENE-6962
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk
>
> Attachments: LUCENE-6962.patch
>
>
> It can be useful for apps to know the min/max value for a given field
> for each dimension, to give the global bounding box.  E.g. an app can
> know that a given range filter excludes all documents in a
> segment/index and skip searching it.



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



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



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

[jira] [Commented] (LUCENE-6962) Add per-dimension min/max to dimensional values

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089244#comment-15089244
 ] 

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

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

LUCENE-6962: fix simple text dim values: writer was missing newlines, and max 
was incorrectly returning min

> Add per-dimension min/max to dimensional values
> ---
>
> Key: LUCENE-6962
> URL: https://issues.apache.org/jira/browse/LUCENE-6962
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk
>
> Attachments: LUCENE-6962.patch
>
>
> It can be useful for apps to know the min/max value for a given field
> for each dimension, to give the global bounding box.  E.g. an app can
> know that a given range filter excludes all documents in a
> segment/index and skip searching it.



--
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-6854) Provide extraction of more metrics from confusion matrix

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili resolved LUCENE-6854.
-
Resolution: Fixed

> Provide extraction of more metrics from confusion matrix
> 
>
> Key: LUCENE-6854
> URL: https://issues.apache.org/jira/browse/LUCENE-6854
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/classification
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Trunk
>
>
> {{ConfusionMatrix}} only provides a general accuracy measure while it'd be 
> good to be able to extract more metrics from it, for specific classes, like 
> precision, recall, f-measure, etc.



--
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: Lucene/Solr 6.0.0 release

[Anshum Gupta]

+1 to that ! Do you have a planned timeline for this?

I would want some time to clean up code and also have a deprecation release
(5.5 or 5.6) out so we don't have to carry all the cruft through the 6x
series.

On Fri, Jan 8, 2016 at 4:37 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> I think we should get the ball rolling for our next major release (6.0.0)?
>
> E.g., dimensional values is a big new feature for 6.x, and I think
> it's nearly ready except maybe fixing up the API so it's easier for
> the 1D case.
>
> I think we should maybe remove StorableField before releasing?  I.e.,
> go back to what we have in 5.x.  This change also caused challenges in
> the 5.0 release, and we just kicked the can down the road, but I think
> now we should just kick the can off the road...
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Anshum Gupta

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk-9-ea+95) - Build # 15481 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15481/
Java: 64bit/jdk-9-ea+95 -XX:-UseCompressedOops -XX:+UseG1GC -XX:-CompactStrings

2 tests failed.
FAILED:  org.apache.lucene.index.TestDuelingCodecs.testCrazyReaderEquals

Error Message:
string [80 0 1 1b]max value [80 0 1 83]  block fp 0 was not created from 
BytesRef.toString?

Stack Trace:
java.lang.IllegalArgumentException: string [80 0 1 1b]max value [80 0 1 83]  
block fp 0 was not created from BytesRef.toString?
at 
org.apache.lucene.codecs.simpletext.SimpleTextUtil.fromBytesRefString(SimpleTextUtil.java:106)
at 
org.apache.lucene.codecs.simpletext.SimpleTextDimensionalReader.initReader(SimpleTextDimensionalReader.java:97)
at 
org.apache.lucene.codecs.simpletext.SimpleTextDimensionalReader.(SimpleTextDimensionalReader.java:73)
at 
org.apache.lucene.codecs.simpletext.SimpleTextDimensionalFormat.fieldsReader(SimpleTextDimensionalFormat.java:45)
at 
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:128)
at org.apache.lucene.index.SegmentReader.(SegmentReader.java:66)
at 
org.apache.lucene.index.StandardDirectoryReader$1.doBody(StandardDirectoryReader.java:58)
at 
org.apache.lucene.index.StandardDirectoryReader$1.doBody(StandardDirectoryReader.java:50)
at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:671)
at 
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:73)
at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:63)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:375)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:305)
at 
org.apache.lucene.index.TestDuelingCodecs.testCrazyReaderEquals(TestDuelingCodecs.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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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 

Re:[jira] [Updated] (LUCENE-6962) Add per-dimension min/max to dimensional values

[Christine Poerschke (BLOOMBERG/ LONDON)]

Hello.

Might there be a min-versus-max copy/paste mistake in getMaxPackedValue?

I will try next to see if that fixes recent 
org.apache.lucene.index.TestDuelingCodecs test failures.

Christine

- Original Message -
From: dev@lucene.apache.org
To: dev@lucene.apache.org
At: Jan  6 2016 09:31:49


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

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

Patch, adding APIs to get min/max values, and also getters for number
of dimensions and bytes per dimension, to {{DimensionalValues}}.


> Add per-dimension min/max to dimensional values
> ---
>
> Key: LUCENE-6962
> URL: https://issues.apache.org/jira/browse/LUCENE-6962
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk
>
> Attachments: LUCENE-6962.patch
>
>
> It can be useful for apps to know the min/max value for a given field
> for each dimension, to give the global bounding box.  E.g. an app can
> know that a given range filter excludes all documents in a
> segment/index and skip searching it.



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



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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15482/
Java: 64bit/jdk1.8.0_66 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.lucene.index.TestDuelingCodecs.testCrazyReaderEquals

Error Message:
string [80 0 1 26]max value [80 0 1 3d]  block fp 0 was not created from 
BytesRef.toString?

Stack Trace:
java.lang.IllegalArgumentException: string [80 0 1 26]max value [80 0 1 3d]  
block fp 0 was not created from BytesRef.toString?
at 
org.apache.lucene.codecs.simpletext.SimpleTextUtil.fromBytesRefString(SimpleTextUtil.java:106)
at 
org.apache.lucene.codecs.simpletext.SimpleTextDimensionalReader.initReader(SimpleTextDimensionalReader.java:97)
at 
org.apache.lucene.codecs.simpletext.SimpleTextDimensionalReader.(SimpleTextDimensionalReader.java:73)
at 
org.apache.lucene.codecs.simpletext.SimpleTextDimensionalFormat.fieldsReader(SimpleTextDimensionalFormat.java:45)
at 
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:128)
at org.apache.lucene.index.SegmentReader.(SegmentReader.java:66)
at 
org.apache.lucene.index.StandardDirectoryReader$1.doBody(StandardDirectoryReader.java:58)
at 
org.apache.lucene.index.StandardDirectoryReader$1.doBody(StandardDirectoryReader.java:50)
at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:671)
at 
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:73)
at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:63)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:375)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:305)
at 
org.apache.lucene.index.TestDuelingCodecs.testCrazyReaderEquals(TestDuelingCodecs.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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  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:49452/d_bw/h;, 
"node_name":"127.0.0.1:49452_d_bw%2Fh", "state":"active",   
  "leader":"true"}}},   "shard2":{ "range":"0-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"collection1", "base_url":"http://127.0.0.1:49447/d_bw/h;,   
  "node_name":"127.0.0.1:49447_d_bw%2Fh", "state":"active", 
"leader":"true"},   "core_node3":{ 
"core":"collection1", "base_url":"http://127.0.0.1:49461/d_bw/h;,   
  "node_name":"127.0.0.1:49461_d_bw%2Fh", 
"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:49437/d_bw/h;,   
  "node_name":"127.0.0.1:49437_d_bw%2Fh", "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:49447/d_bw/h;, 
"node_name":"127.0.0.1:49447_d_bw%2Fh", "state":"recovering"},  
 "core_node2":{ "core":"c8n_1x2_shard1_replica1", 
"base_url":"http://127.0.0.1:49437/d_bw/h;, 
"node_name":"127.0.0.1:49437_d_bw%2Fh", "state":"active",   
  "leader":"true", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false"},   "collMinRf_1x3":{ 
"replicationFactor":"3", "shards":{"shard1":{ 
"range":"8000-7fff", "state":"active", "replicas":{ 
  "core_node1":{ "core":"collMinRf_1x3_shard1_replica1",
 "base_url":"http://127.0.0.1:49452/d_bw/h;, 
"node_name":"127.0.0.1:49452_d_bw%2Fh", "state":"active"},  
 "core_node2":{ "core":"collMinRf_1x3_shard1_replica3", 
"base_url":"http://127.0.0.1:49437/d_bw/h;, 
"node_name":"127.0.0.1:49437_d_bw%2Fh", "state":"active"},  
 "core_node3":{ "core":"collMinRf_1x3_shard1_replica2", 
"base_url":"http://127.0.0.1:49461/d_bw/h;, 
"node_name":"127.0.0.1:49461_d_bw%2Fh", "state":"active",   
  "leader":"true", "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:49452/d_bw/h;,
"node_name":"127.0.0.1:49452_d_bw%2Fh",
"state":"active",
"leader":"true"}}},
  "shard2":{
"range":"0-7fff",
"state":"active",
"replicas":{
  "core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:49447/d_bw/h;,
"node_name":"127.0.0.1:49447_d_bw%2Fh",
"state":"active",
"leader":"true"},
  "core_node3":{
"core":"collection1",
"base_url":"http://127.0.0.1:49461/d_bw/h;,
"node_name":"127.0.0.1:49461_d_bw%2Fh",
"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:49437/d_bw/h;,

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.lucene.index.TestDuelingCodecs.testCrazyReaderEquals

Error Message:
string [80 0 0 0]max value [80 0 0 6e]  block fp 0 was not created from 
BytesRef.toString?

Stack Trace:
java.lang.IllegalArgumentException: string [80 0 0 0]max value [80 0 0 6e]  
block fp 0 was not created from BytesRef.toString?
at 
org.apache.lucene.codecs.simpletext.SimpleTextUtil.fromBytesRefString(SimpleTextUtil.java:106)
at 
org.apache.lucene.codecs.simpletext.SimpleTextDimensionalReader.initReader(SimpleTextDimensionalReader.java:97)
at 
org.apache.lucene.codecs.simpletext.SimpleTextDimensionalReader.(SimpleTextDimensionalReader.java:73)
at 
org.apache.lucene.codecs.simpletext.SimpleTextDimensionalFormat.fieldsReader(SimpleTextDimensionalFormat.java:45)
at 
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:128)
at org.apache.lucene.index.SegmentReader.(SegmentReader.java:66)
at 
org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:145)
at 
org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:197)
at 
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:99)
at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:434)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:377)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:305)
at 
org.apache.lucene.index.TestDuelingCodecs.testCrazyReaderEquals(TestDuelingCodecs.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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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] (LUCENE-6854) Provide extraction of more metrics from confusion matrix

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089257#comment-15089257
 ] 

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

Commit 1723729 from [~teofili] in branch 'dev/trunk'
[ https://svn.apache.org/r1723729 ]

LUCENE-6854 - global confusion matrix precision and recall metrics

> Provide extraction of more metrics from confusion matrix
> 
>
> Key: LUCENE-6854
> URL: https://issues.apache.org/jira/browse/LUCENE-6854
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/classification
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Trunk
>
>
> {{ConfusionMatrix}} only provides a general accuracy measure while it'd be 
> good to be able to extract more metrics from it, for specific classes, like 
> precision, recall, f-measure, etc.



--
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: Lucene/Solr 6.0.0 release

[Noble Paul]

deprecating old API is not yet planned. both will co-exist.


On Fri, Jan 8, 2016 at 7:33 PM, Jan Høydahl  wrote:
> +1 for getting the ball rolling and decide a date for branch cutting...
>
> Regarding /v2/ api, isn’t the plan that the new api will co-exist with the 
> old for some time?
> If so, it would be acceptible to add the /v2/ API in 6.x and deprecate old 
> api in 6.y?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>> 8. jan. 2016 kl. 14.38 skrev Noble Paul :
>>
>> I was planning to add SOLR-8029 ( Modernize and standardize Solr APIs) to 6.0
>>
>> it is at least 2-3 months away. If the release is planned after
>> march I would like to get that in.
>>
>> On Fri, Jan 8, 2016 at 1:10 PM, Dawid Weiss  wrote:
 I think we should get the ball rolling for our next major release (6.0.0)?
>>>
>>> I'd love it to be the first git-based release. :)
>>> It'd be a nice milestone change (from infrastructural point of view).
>>> Not a blocker, of course.
>>>
>>> Dawid
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>>
>>
>> --
>> -
>> Noble Paul
>>
>> -
>> 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
>



-- 
-
Noble Paul

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

[jira] [Created] (SOLR-8522) ImplicitSnitch to support IP based tags

[Arcadius Ahouansou (JIRA)]

Arcadius Ahouansou created SOLR-8522:


 Summary: ImplicitSnitch to support IP based tags
 Key: SOLR-8522
 URL: https://issues.apache.org/jira/browse/SOLR-8522
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 5.4
Reporter: Arcadius Ahouansou
Priority: Minor


This is a description from [~noble.paul]'s comment on SOLR-8146

Lets assume a Solr node IPv4 address is 192.93.255.255 .

This is about enhancing the current {{ImplicitSnitch}}  to support IP based 
tags like:

- {{ip_1 = 192}}
- {{ip_2 = 93}}
- {{ip_3 = 255}}
- {{ip_4 = 255}}

Note that IPv6 support will be implemented by a separate ticket




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