[jira] [Commented] (LUCENE-7337) MultiTermQuery are sometimes rewritten into an empty boolean query

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7337:
--

bq. I do really like your idea of having an empty clause BQ rewrite to 
MatchNoDocsQuery: I think we should have one, unambiguous query class that's 
used for this "matches nothing" rewrite case, if we can get the scoring to work 
out correctly!

+1 !   Empty BQ is weird.

> MultiTermQuery are sometimes rewritten into an empty boolean query
> --
>
> Key: LUCENE-7337
> URL: https://issues.apache.org/jira/browse/LUCENE-7337
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Reporter: Ferenczi Jim
>Priority: Minor
>
> MultiTermQuery are sometimes rewritten to an empty boolean query (depending 
> on the rewrite method), it can happen when no expansions are found on a fuzzy 
> query for instance.
> It can be problematic when the multi term query is boosted. 
> For instance consider the following query:
> `((title:bar~1)^100 text:bar)`
> This is a boolean query with two optional clauses. The first one is a fuzzy 
> query on the field title with a boost of 100. 
> If there is no expansion for "title:bar~1" the query is rewritten into:
> `(()^100 text:bar)`
> ... and when expansions are found:
> `((title:bars | title:bar)^100 text:bar)`
> The scoring of those two queries will differ because the normalization factor 
> and the norm for the first query will be equal to 1 (the boost is ignored 
> because the empty boolean query is not taken into account for the computation 
> of the normalization factor) whereas the second query will have a 
> normalization factor of 10,000 (100*100) and a norm equal to 0.01. 
> This kind of discrepancy can happen in a single index because the expansions 
> for the fuzzy query are done at the segment level. It can also happen when 
> multiple indices are requested (Solr/ElasticSearch case).
> A simple fix would be to replace the empty boolean query produced by the 
> multi term query with a MatchNoDocsQuery but I am not sure that it's the best 
> way to fix. WDYT ?
>  



--
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-master-MacOSX (64bit/jdk1.8.0) - Build # 3346 - Failure!

[Policeman Jenkins Server]

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

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

Error Message:
Timeout occured while waiting response from server at: https://127.0.0.1:55021

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:55021
at 
__randomizedtesting.SeedInfo.seed([7CEC55EDA2CDFB13:F4B86A370C3196EB]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:617)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:400)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:898)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:178)
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:498)
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:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
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-5.5-Linux (32bit/jdk1.7.0_80) - Build # 301 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/301/
Java: 32bit/jdk1.7.0_80 -server -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.BasicAuthIntegrationTest

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

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


FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

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




Build Log:
[...truncated 12363 lines...]
   [junit4] Suite: org.apache.solr.security.BasicAuthIntegrationTest
   [junit4]   2> 765132 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[995253744E9FA0EF]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 765132 INFO  (Thread-1761) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 765132 INFO  (Thread-1761) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 765232 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[995253744E9FA0EF]) [] 
o.a.s.c.ZkTestServer start zk server on port:37916
   [junit4]   2> 765232 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[995253744E9FA0EF]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 765233 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[995253744E9FA0EF]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 765255 INFO  (zkCallback-538-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@a21aa0 name:ZooKeeperConnection 
Watcher:127.0.0.1:37916 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2> 765255 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[995253744E9FA0EF]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 765255 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[995253744E9FA0EF]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 765255 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[995253744E9FA0EF]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
   [junit4]   2> 765264 INFO  (jetty-launcher-537-thread-1) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 765270 INFO  (jetty-launcher-537-thread-2) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 765270 INFO  (jetty-launcher-537-thread-1) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@12d1e91{/solr,null,AVAILABLE}
   [junit4]   2> 765270 INFO  (jetty-launcher-537-thread-3) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 765271 INFO  (jetty-launcher-537-thread-4) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 765272 INFO  (jetty-launcher-537-thread-2) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@7180ef{/solr,null,AVAILABLE}
   [junit4]   2> 765273 INFO  (jetty-launcher-537-thread-5) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 765273 INFO  (jetty-launcher-537-thread-1) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@e953a1{HTTP/1.1}{127.0.0.1:45665}
   [junit4]   2> 765273 INFO  (jetty-launcher-537-thread-1) [] 
o.e.j.s.Server Started @767526ms
   [junit4]   2> 765273 INFO  (jetty-launcher-537-thread-1) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr, 
hostPort=45665}
   [junit4]   2> 765273 INFO  (jetty-launcher-537-thread-1) [] 
o.a.s.s.SolrDispatchFilter SolrDispatchFilter.init(): 
sun.misc.Launcher$AppClassLoader@327236
   [junit4]   2> 765273 INFO  (jetty-launcher-537-thread-1) [] 
o.a.s.c.SolrResourceLoader new SolrResourceLoader for directory: 
'/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/solr-core/test/J1/temp/solr.security.BasicAuthIntegrationTest_995253744E9FA0EF-001/tempDir-001/node1'
   [junit4]   2> 765273 INFO  (jetty-launcher-537-thread-1) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 765273 INFO  (jetty-launcher-537-thread-1) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 765274 INFO  (jetty-launcher-537-thread-1) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 765274 INFO  (jetty-launcher-537-thread-5) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@31f7e8{/solr,null,AVAILABLE}
   [junit4]   2> 765274 INFO  (jetty-launcher-537-thread-1) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 765275 INFO  (jetty-launcher-537-thread-2) [] 
o.e.j.s.ServerConnector Started 

Re: Lucene/Solr 5.5.2

[Steve Rowe]

Progress update:

I finished backporting issues to 5.5.2 (and 5.6/6.0.2 where applicable).  
Thanks Hoss and Mike for investigating and fixing the test bug uncovered by the 
LUCENE-7132 backport!

Since 6.1 has been released, I plan on cutting the first RC on Monday the 20th.

--
Steve
www.lucidworks.com

> On Jun 13, 2016, at 1:25 PM, Steve Rowe  wrote:
> 
> I’d like to make a 5.5.2 release, and I volunteer to be RM.
> 
> I propose to cut the first RC no sooner than one week from today: Monday June 
> 20th.  I plan on delaying cutting the RC until after 6.1.0 has been released; 
> I’d rather avoid two RMs trying to do release work at the same time.
> 
> I’ll start looking now at backporting bugfixes I’ve worked on to the 5.5 
> branch, and I encourage others to do the same.
> 
> I’ll go enable the 5.5 branch Jenkins jobs now.
> 
> --
> Steve
> www.lucidworks.com
> 


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

[jira] [Resolved] (SOLR-8445) fix line separator in log4j.properties files

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-8445.
--
   Resolution: Fixed
Fix Version/s: 6.0.2
   5.5.2
   5.6

> fix line separator in log4j.properties files
> 
>
> Key: SOLR-8445
> URL: https://issues.apache.org/jira/browse/SOLR-8445
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.4, 6.0
>Reporter: Ahmet Arslan
>Assignee: Mikhail Khludnev
>Priority: Trivial
>  Labels: log4j, logging
> Fix For: 5.6, 5.5.2, master (7.0), 6.0.2, 6.1
>
> Attachments: SOLR-8445.patch, SOLR-8445.patch
>
>
> new line is mistyped in conversion pattern 



--
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-8445) fix line separator in log4j.properties files

[ASF subversion and git services (JIRA)]

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

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

Commit 7f644688ab6ec7d441b4cbe1daa6f810bf229312 in lucene-solr's branch 
refs/heads/branch_5x from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7f64468 ]

SOLR-8445: fix line separator in log4j.properties files


> fix line separator in log4j.properties files
> 
>
> Key: SOLR-8445
> URL: https://issues.apache.org/jira/browse/SOLR-8445
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.4, 6.0
>Reporter: Ahmet Arslan
>Assignee: Mikhail Khludnev
>Priority: Trivial
>  Labels: log4j, logging
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-8445.patch, SOLR-8445.patch
>
>
> new line is mistyped in conversion pattern 



--
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-8445) fix line separator in log4j.properties files

[ASF subversion and git services (JIRA)]

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

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

Commit 215f3d954747ed823f63b306033c2f16a12bb3aa in lucene-solr's branch 
refs/heads/branch_6_0 from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=215f3d9 ]

SOLR-8445: fix line separator in log4j.properties files


> fix line separator in log4j.properties files
> 
>
> Key: SOLR-8445
> URL: https://issues.apache.org/jira/browse/SOLR-8445
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.4, 6.0
>Reporter: Ahmet Arslan
>Assignee: Mikhail Khludnev
>Priority: Trivial
>  Labels: log4j, logging
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-8445.patch, SOLR-8445.patch
>
>
> new line is mistyped in conversion pattern 



--
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-8445) fix line separator in log4j.properties files

[ASF subversion and git services (JIRA)]

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

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

Commit c6b9ac065571718e7e92174fa7e2a927583012fa in lucene-solr's branch 
refs/heads/branch_5_5 from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c6b9ac0 ]

SOLR-8445: fix line separator in log4j.properties files


> fix line separator in log4j.properties files
> 
>
> Key: SOLR-8445
> URL: https://issues.apache.org/jira/browse/SOLR-8445
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.4, 6.0
>Reporter: Ahmet Arslan
>Assignee: Mikhail Khludnev
>Priority: Trivial
>  Labels: log4j, logging
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-8445.patch, SOLR-8445.patch
>
>
> new line is mistyped in conversion pattern 



--
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] [Reopened] (SOLR-8445) fix line separator in log4j.properties files

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-8445:
--

Reopening to backport to 6.0.2, 5.6 and 5.5.2.

> fix line separator in log4j.properties files
> 
>
> Key: SOLR-8445
> URL: https://issues.apache.org/jira/browse/SOLR-8445
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.4, 6.0
>Reporter: Ahmet Arslan
>Assignee: Mikhail Khludnev
>Priority: Trivial
>  Labels: log4j, logging
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8445.patch, SOLR-8445.patch
>
>
> new line is mistyped in conversion pattern 



--
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-9105) Fix typos in solr core module

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9105.
--
   Resolution: Fixed
Fix Version/s: 6.0.2
   5.5.2
   5.6

> Fix typos in solr core module
> -
>
> Key: SOLR-9105
> URL: https://issues.apache.org/jira/browse/SOLR-9105
> Project: Solr
>  Issue Type: Bug
>Reporter: Bartosz Krasiński
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 5.6, 5.5.2, master (7.0), 6.0.2, 6.1
>
>
> Hello,
> I wanted to fix one typo that I've found while reading the code, then I 
> decided to fix some more and that escalated a bit...
> https://github.com/apache/lucene-solr/pull/39



--
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-9105) Fix typos in solr core module

[ASF subversion and git services (JIRA)]

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

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

Commit b83f82ddf022d84d4da8beee1d189b42bfa075c6 in lucene-solr's branch 
refs/heads/branch_5x from [~krasinski]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b83f82d ]

SOLR-9105: Fix some typos in solr core module
(cherry picked from commit 1609406)


> Fix typos in solr core module
> -
>
> Key: SOLR-9105
> URL: https://issues.apache.org/jira/browse/SOLR-9105
> Project: Solr
>  Issue Type: Bug
>Reporter: Bartosz Krasiński
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 6.1, master (7.0)
>
>
> Hello,
> I wanted to fix one typo that I've found while reading the code, then I 
> decided to fix some more and that escalated a bit...
> https://github.com/apache/lucene-solr/pull/39



--
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-9105) Fix typos in solr core module

[ASF subversion and git services (JIRA)]

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

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

Commit 385d4f5f47ef5f2995aa7ee085e51b6087b4acba in lucene-solr's branch 
refs/heads/branch_5_5 from [~krasinski]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=385d4f5 ]

SOLR-9105: Fix some typos in solr core module
(cherry picked from commit 1609406)


> Fix typos in solr core module
> -
>
> Key: SOLR-9105
> URL: https://issues.apache.org/jira/browse/SOLR-9105
> Project: Solr
>  Issue Type: Bug
>Reporter: Bartosz Krasiński
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 6.1, master (7.0)
>
>
> Hello,
> I wanted to fix one typo that I've found while reading the code, then I 
> decided to fix some more and that escalated a bit...
> https://github.com/apache/lucene-solr/pull/39



--
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-9105) Fix typos in solr core module

[ASF subversion and git services (JIRA)]

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

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

Commit 2d1a88b2b89fbf848a5ec5b6aa2f287564fb4c62 in lucene-solr's branch 
refs/heads/branch_6_0 from [~krasinski]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2d1a88b ]

SOLR-9105: Fix some typos in solr core module
(cherry picked from commit 1609406)


> Fix typos in solr core module
> -
>
> Key: SOLR-9105
> URL: https://issues.apache.org/jira/browse/SOLR-9105
> Project: Solr
>  Issue Type: Bug
>Reporter: Bartosz Krasiński
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 6.1, master (7.0)
>
>
> Hello,
> I wanted to fix one typo that I've found while reading the code, then I 
> decided to fix some more and that escalated a bit...
> https://github.com/apache/lucene-solr/pull/39



--
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-9105) Fix typos in solr core module

[ASF subversion and git services (JIRA)]

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

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

Commit a4469911fd7802864310a3edfc3e673e041293aa in lucene-solr's branch 
refs/heads/branch_5_5 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a446991 ]

SOLR-9105: Add 5.5.2 CHANGES entry


> Fix typos in solr core module
> -
>
> Key: SOLR-9105
> URL: https://issues.apache.org/jira/browse/SOLR-9105
> Project: Solr
>  Issue Type: Bug
>Reporter: Bartosz Krasiński
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 6.1, master (7.0)
>
>
> Hello,
> I wanted to fix one typo that I've found while reading the code, then I 
> decided to fix some more and that escalated a bit...
> https://github.com/apache/lucene-solr/pull/39



--
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-9037) replace multiple "/replication" strings with one static constant

[ASF subversion and git services (JIRA)]

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

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

Commit b187e4c66206503e3551456a2b5df98cbaacdcab in lucene-solr's branch 
refs/heads/branch_6_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b187e4c ]

SOLR-9037: add required package import


> replace multiple "/replication" strings with one static constant
> 
>
> Key: SOLR-9037
> URL: https://issues.apache.org/jira/browse/SOLR-9037
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-9037.patch
>
>
> proposed patch to follow



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

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

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_92) - Build # 255 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/255/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseParallelGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
ObjectTracker found 8 object(s) that were not released!!! 
[MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper, 
MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor, MDCAwareThreadPoolExecutor]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 8 object(s) that were not 
released!!! [MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper, 
MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor, MDCAwareThreadPoolExecutor]
at __randomizedtesting.SeedInfo.seed([FDDAC5C51582F473]: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.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
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:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_FDDAC5C51582F473-001\tempDir-001\node1\testschemaapi_shard1_replica2\data\tlog\tlog.001:
 java.nio.file.FileSystemException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_FDDAC5C51582F473-001\tempDir-001\node1\testschemaapi_shard1_replica2\data\tlog\tlog.001:
 The process cannot access the file because it is being used by another 
process. 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_FDDAC5C51582F473-001\tempDir-001\node1\testschemaapi_shard1_replica2\data\tlog:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_FDDAC5C51582F473-001\tempDir-001\node1\testschemaapi_shard1_replica2\data\tlog

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_FDDAC5C51582F473-001\tempDir-001\node1\testschemaapi_shard1_replica2\data:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.schema.TestManagedSchemaAPI_FDDAC5C51582F473-001\tempDir-001\node1\testschemaapi_shard1_replica2\data

[jira] [Reopened] (SOLR-9105) Fix typos in solr core module

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-9105:
--

Reopening to backport to 6.0.2, 5.6 and 5.5.2.

> Fix typos in solr core module
> -
>
> Key: SOLR-9105
> URL: https://issues.apache.org/jira/browse/SOLR-9105
> Project: Solr
>  Issue Type: Bug
>Reporter: Bartosz Krasiński
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 6.1, master (7.0)
>
>
> Hello,
> I wanted to fix one typo that I've found while reading the code, then I 
> decided to fix some more and that escalated a bit...
> https://github.com/apache/lucene-solr/pull/39



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

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

[JENKINS] Lucene-Solr-Tests-5.5-Java8 - Build # 33 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.5-Java8/33/

1 tests failed.
FAILED:  
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithTimeDelay

Error Message:
Could not find collection : c1

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : c1
at 
__randomizedtesting.SeedInfo.seed([81784B636650FE63:FEE6FCE60F32D3E9]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:170)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdate(ZkStateReaderTest.java:129)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithTimeDelay(ZkStateReaderTest.java:52)
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:498)
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:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
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 11611 lines...]
   [junit4] Suite: org.apache.solr.cloud.overseer.ZkStateReaderTest
   [junit4]   2> Creating dataDir: 

[jira] [Resolved] (SOLR-9047) zkcli should allow alternative locations for log4j configuration

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9047.
--
   Resolution: Fixed
Fix Version/s: 6.0.2
   5.5.2
   5.6

> zkcli should allow alternative locations for log4j configuration
> 
>
> Key: SOLR-9047
> URL: https://issues.apache.org/jira/browse/SOLR-9047
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools, SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>Priority: Minor
> Fix For: 5.6, 5.5.2, master (7.0), 6.0.2, 6.1
>
> Attachments: SOLR-9047.patch, SOLR-9047.patch
>
>
> zkcli uses the log4j configuration in the local directory:
> {code}
> sdir="`dirname \"$0\"`"
> PATH=$JAVA_HOME/bin:$PATH $JVM 
> -Dlog4j.configuration=file:$sdir/log4j.properties -classpath 
> "$sdir/../../solr-webapp/webapp/WEB-INF/lib/*:$sdir/../../lib/ext/*" 
> org.apache.solr.cloud.ZkCLI ${1+"$@"}
> {code}
> which is a reasonable default, but often people want to use a "global" log4j 
> configuration.  For example, one may define a log4j configuration that writes 
> to an external log directory and want to point to this rather than copying it 
> to each source checkout.



--
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] [Reopened] (SOLR-9047) zkcli should allow alternative locations for log4j configuration

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-9047:
--

Reopening to backport to 6.0.2, 5.6 and 5.5.2.

> zkcli should allow alternative locations for log4j configuration
> 
>
> Key: SOLR-9047
> URL: https://issues.apache.org/jira/browse/SOLR-9047
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools, SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>Priority: Minor
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9047.patch, SOLR-9047.patch
>
>
> zkcli uses the log4j configuration in the local directory:
> {code}
> sdir="`dirname \"$0\"`"
> PATH=$JAVA_HOME/bin:$PATH $JVM 
> -Dlog4j.configuration=file:$sdir/log4j.properties -classpath 
> "$sdir/../../solr-webapp/webapp/WEB-INF/lib/*:$sdir/../../lib/ext/*" 
> org.apache.solr.cloud.ZkCLI ${1+"$@"}
> {code}
> which is a reasonable default, but often people want to use a "global" log4j 
> configuration.  For example, one may define a log4j configuration that writes 
> to an external log directory and want to point to this rather than copying it 
> to each source checkout.



--
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-9047) zkcli should allow alternative locations for log4j configuration

[ASF subversion and git services (JIRA)]

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

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

Commit c64b1194af9328c4da7bc5f5f08cbac93db3e7bf in lucene-solr's branch 
refs/heads/branch_5x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c64b119 ]

SOLR-9047: Remove misplaced CHANGES entry


> zkcli should allow alternative locations for log4j configuration
> 
>
> Key: SOLR-9047
> URL: https://issues.apache.org/jira/browse/SOLR-9047
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools, SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>Priority: Minor
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9047.patch, SOLR-9047.patch
>
>
> zkcli uses the log4j configuration in the local directory:
> {code}
> sdir="`dirname \"$0\"`"
> PATH=$JAVA_HOME/bin:$PATH $JVM 
> -Dlog4j.configuration=file:$sdir/log4j.properties -classpath 
> "$sdir/../../solr-webapp/webapp/WEB-INF/lib/*:$sdir/../../lib/ext/*" 
> org.apache.solr.cloud.ZkCLI ${1+"$@"}
> {code}
> which is a reasonable default, but often people want to use a "global" log4j 
> configuration.  For example, one may define a log4j configuration that writes 
> to an external log directory and want to point to this rather than copying it 
> to each source checkout.



--
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-9047) zkcli should allow alternative locations for log4j configuration

[ASF subversion and git services (JIRA)]

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

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

Commit 1eb3093311682a2db108dd5e6d6f4aea52bee973 in lucene-solr's branch 
refs/heads/branch_5x from [~gchanan]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1eb3093 ]

SOLR-9047: zkcli should allow alternative locations for log4j configuration


> zkcli should allow alternative locations for log4j configuration
> 
>
> Key: SOLR-9047
> URL: https://issues.apache.org/jira/browse/SOLR-9047
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools, SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>Priority: Minor
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9047.patch, SOLR-9047.patch
>
>
> zkcli uses the log4j configuration in the local directory:
> {code}
> sdir="`dirname \"$0\"`"
> PATH=$JAVA_HOME/bin:$PATH $JVM 
> -Dlog4j.configuration=file:$sdir/log4j.properties -classpath 
> "$sdir/../../solr-webapp/webapp/WEB-INF/lib/*:$sdir/../../lib/ext/*" 
> org.apache.solr.cloud.ZkCLI ${1+"$@"}
> {code}
> which is a reasonable default, but often people want to use a "global" log4j 
> configuration.  For example, one may define a log4j configuration that writes 
> to an external log directory and want to point to this rather than copying it 
> to each source checkout.



--
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-9047) zkcli should allow alternative locations for log4j configuration

[ASF subversion and git services (JIRA)]

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

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

Commit 66c16651baa88a2dcdef392e2f76870334136821 in lucene-solr's branch 
refs/heads/branch_5_5 from [~gchanan]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=66c1665 ]

SOLR-9047: zkcli should allow alternative locations for log4j configuration


> zkcli should allow alternative locations for log4j configuration
> 
>
> Key: SOLR-9047
> URL: https://issues.apache.org/jira/browse/SOLR-9047
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools, SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>Priority: Minor
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9047.patch, SOLR-9047.patch
>
>
> zkcli uses the log4j configuration in the local directory:
> {code}
> sdir="`dirname \"$0\"`"
> PATH=$JAVA_HOME/bin:$PATH $JVM 
> -Dlog4j.configuration=file:$sdir/log4j.properties -classpath 
> "$sdir/../../solr-webapp/webapp/WEB-INF/lib/*:$sdir/../../lib/ext/*" 
> org.apache.solr.cloud.ZkCLI ${1+"$@"}
> {code}
> which is a reasonable default, but often people want to use a "global" log4j 
> configuration.  For example, one may define a log4j configuration that writes 
> to an external log directory and want to point to this rather than copying it 
> to each source checkout.



--
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-8792) ZooKeeper ACL support broken

[ASF subversion and git services (JIRA)]

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

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

Commit 7f721752eef8560c9c3e03b7680599d7cbb2c7fa in lucene-solr's branch 
refs/heads/branch_5x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7f72175 ]

SOLR-8792: Remove misplaced CHANGES entry


> ZooKeeper ACL support broken
> 
>
> Key: SOLR-8792
> URL: https://issues.apache.org/jira/browse/SOLR-8792
> Project: Solr
>  Issue Type: Bug
>  Components: Authentication, documentation
>Affects Versions: 5.0
>Reporter: Esther Quansah
>Assignee: Steve Rowe
>  Labels: acl, authentication, security, zkcli, zkcli.sh, zookeeper
> Fix For: 5.6, 6.0.1, 6.1, 5.5.2
>
> Attachments: SOLR-8792.patch, SOLR-8792.patch, SOLR-8792.patch, 
> SOLR-8792.patch
>
>
> The documentation presented here: 
> https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control
> details the process of securing Solr content in ZooKeeper using ACLs. In the 
> example usages, it is mentioned that access to zkcli can be restricted by 
> adding credentials to the zkcli.sh script in addition to adding the 
> appropriate classnames to solr.xml. With the scripts in zkcli.sh, another 
> machine should not be able to read or write from the host ZK without the 
> necessary credentials. At this time, machines are able to read/write from the 
> host ZK with or without these credentials.



--
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-8792) ZooKeeper ACL support broken

[ASF subversion and git services (JIRA)]

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

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

Commit 9a30f091b657c9775738f3df29a5f6cc37495bc2 in lucene-solr's branch 
refs/heads/branch_5x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9a30f09 ]

SOLR-8792: ZooKeeper ACL support fixed


> ZooKeeper ACL support broken
> 
>
> Key: SOLR-8792
> URL: https://issues.apache.org/jira/browse/SOLR-8792
> Project: Solr
>  Issue Type: Bug
>  Components: Authentication, documentation
>Affects Versions: 5.0
>Reporter: Esther Quansah
>Assignee: Steve Rowe
>  Labels: acl, authentication, security, zkcli, zkcli.sh, zookeeper
> Fix For: 5.6, 6.0.1, 6.1, 5.5.2
>
> Attachments: SOLR-8792.patch, SOLR-8792.patch, SOLR-8792.patch, 
> SOLR-8792.patch
>
>
> The documentation presented here: 
> https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control
> details the process of securing Solr content in ZooKeeper using ACLs. In the 
> example usages, it is mentioned that access to zkcli can be restricted by 
> adding credentials to the zkcli.sh script in addition to adding the 
> appropriate classnames to solr.xml. With the scripts in zkcli.sh, another 
> machine should not be able to read or write from the host ZK without the 
> necessary credentials. At this time, machines are able to read/write from the 
> host ZK with or without these credentials.



--
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-9037) replace multiple "/replication" strings with one static constant

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9037.
--
   Resolution: Fixed
Fix Version/s: 6.0.2
   5.5.2

> replace multiple "/replication" strings with one static constant
> 
>
> Key: SOLR-9037
> URL: https://issues.apache.org/jira/browse/SOLR-9037
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.6, 5.5.2, master (7.0), 6.0.2, 6.1
>
> Attachments: SOLR-9037.patch
>
>
> proposed patch to follow



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

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

[jira] [Commented] (SOLR-9037) replace multiple "/replication" strings with one static constant

[ASF subversion and git services (JIRA)]

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

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

Commit 4c080207f27d1c4a44a90f763054ca1db4921bab in lucene-solr's branch 
refs/heads/branch_6_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4c08020 ]

SOLR-9037: Remove misplaced CHANGES entry


> replace multiple "/replication" strings with one static constant
> 
>
> Key: SOLR-9037
> URL: https://issues.apache.org/jira/browse/SOLR-9037
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.6, 6.1, master (7.0)
>
> Attachments: SOLR-9037.patch
>
>
> proposed patch to follow



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

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

[jira] [Commented] (SOLR-9037) replace multiple "/replication" strings with one static constant

[ASF subversion and git services (JIRA)]

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

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

Commit 48c8e1923f46abaec133a332ec573b4c560148d1 in lucene-solr's branch 
refs/heads/branch_6_0 from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=48c8e19 ]

SOLR-9037: replace multiple "/replication" strings with one static constant


> replace multiple "/replication" strings with one static constant
> 
>
> Key: SOLR-9037
> URL: https://issues.apache.org/jira/browse/SOLR-9037
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.6, 6.1, master (7.0)
>
> Attachments: SOLR-9037.patch
>
>
> proposed patch to follow



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

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

[jira] [Commented] (SOLR-9037) replace multiple "/replication" strings with one static constant

[ASF subversion and git services (JIRA)]

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

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

Commit 190069c8480063a53b27bf7ad7ef4df4963575b0 in lucene-solr's branch 
refs/heads/branch_5_5 from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=190069c ]

SOLR-9037: replace multiple "/replication" strings with one static constant


> replace multiple "/replication" strings with one static constant
> 
>
> Key: SOLR-9037
> URL: https://issues.apache.org/jira/browse/SOLR-9037
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.6, 6.1, master (7.0)
>
> Attachments: SOLR-9037.patch
>
>
> proposed patch to follow



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

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

[jira] [Commented] (SOLR-9037) replace multiple "/replication" strings with one static constant

[ASF subversion and git services (JIRA)]

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

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

Commit 55fe69018001506286477aa5f67c20a38a7cd01c in lucene-solr's branch 
refs/heads/branch_5_5 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=55fe690 ]

SOLR-9037: Add 5.5.2 CHANGES entry


> replace multiple "/replication" strings with one static constant
> 
>
> Key: SOLR-9037
> URL: https://issues.apache.org/jira/browse/SOLR-9037
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.6, 6.1, master (7.0)
>
> Attachments: SOLR-9037.patch
>
>
> proposed patch to follow



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

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

[jira] [Commented] (SOLR-9025) add SolrCoreTest.testImplicitPlugins test

[ASF subversion and git services (JIRA)]

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

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

Commit 4639a29b62afd48b175a33ac2d3d1e5a81b123d1 in lucene-solr's branch 
refs/heads/branch_6_0 from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4639a29 ]

SOLR-9025: Add SolrCoreTest.testImplicitPlugins test.


> add SolrCoreTest.testImplicitPlugins test
> -
>
> Key: SOLR-9025
> URL: https://issues.apache.org/jira/browse/SOLR-9025
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-9025.patch
>
>
> Various places in the code assume that certain implicit handlers are 
> configured on certain paths (e.g. {{/replication}} is referenced by 
> {{RecoveryStrategy}} and {{IndexFetcher}}). This test tests that the 
> {{ImplicitPlugins.json}} content configures the expected paths and class 
> names.



--
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-9025) add SolrCoreTest.testImplicitPlugins test

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9025.
--
   Resolution: Fixed
Fix Version/s: 6.0.2
   5.5.2

> add SolrCoreTest.testImplicitPlugins test
> -
>
> Key: SOLR-9025
> URL: https://issues.apache.org/jira/browse/SOLR-9025
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.6, 5.5.2, master (7.0), 6.0.2, 6.1
>
> Attachments: SOLR-9025.patch
>
>
> Various places in the code assume that certain implicit handlers are 
> configured on certain paths (e.g. {{/replication}} is referenced by 
> {{RecoveryStrategy}} and {{IndexFetcher}}). This test tests that the 
> {{ImplicitPlugins.json}} content configures the expected paths and class 
> names.



--
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-9025) add SolrCoreTest.testImplicitPlugins test

[ASF subversion and git services (JIRA)]

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

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

Commit 1da8709f950c88b7365e8fe263d46dedafdc300f in lucene-solr's branch 
refs/heads/branch_5_5 from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1da8709 ]

SOLR-9025: Add SolrCoreTest.testImplicitPlugins test.


> add SolrCoreTest.testImplicitPlugins test
> -
>
> Key: SOLR-9025
> URL: https://issues.apache.org/jira/browse/SOLR-9025
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-9025.patch
>
>
> Various places in the code assume that certain implicit handlers are 
> configured on certain paths (e.g. {{/replication}} is referenced by 
> {{RecoveryStrategy}} and {{IndexFetcher}}). This test tests that the 
> {{ImplicitPlugins.json}} content configures the expected paths and class 
> names.



--
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] [Reopened] (SOLR-9025) add SolrCoreTest.testImplicitPlugins test

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-9025:
--

Reopening to backport to 6.0.2 and 5.5.2.

> add SolrCoreTest.testImplicitPlugins test
> -
>
> Key: SOLR-9025
> URL: https://issues.apache.org/jira/browse/SOLR-9025
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.6, 6.1, master (7.0)
>
> Attachments: SOLR-9025.patch
>
>
> Various places in the code assume that certain implicit handlers are 
> configured on certain paths (e.g. {{/replication}} is referenced by 
> {{RecoveryStrategy}} and {{IndexFetcher}}). This test tests that the 
> {{ImplicitPlugins.json}} content configures the expected paths and class 
> names.



--
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] [Reopened] (SOLR-9037) replace multiple "/replication" strings with one static constant

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-9037:
--

Reopening to backport to 6.0.2 and 5.5.2.

> replace multiple "/replication" strings with one static constant
> 
>
> Key: SOLR-9037
> URL: https://issues.apache.org/jira/browse/SOLR-9037
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.6, 6.1, master (7.0)
>
> Attachments: SOLR-9037.patch
>
>
> proposed patch to follow



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

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

[jira] [Commented] (SOLR-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[ASF subversion and git services (JIRA)]

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

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

Commit 6f8d306ea8ca96c4c6edfffcfed7c300d328716a in lucene-solr's branch 
refs/heads/branch_6_0 from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6f8d306 ]

SOLR-8933: Solr should not close container streams.


> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



--
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-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[ASF subversion and git services (JIRA)]

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

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

Commit 9c81c77baec53fd60163a3e1d2a4489e081f2eaa in lucene-solr's branch 
refs/heads/branch_5x from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9c81c77 ]

SOLR-8933: Solr should not close container streams.


> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



--
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-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[ASF subversion and git services (JIRA)]

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

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

Commit f6d40e3e668a0c5cd4f11493f11afeaf1a45d267 in lucene-solr's branch 
refs/heads/branch_5x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f6d40e3 ]

SOLR-8933: Remove misplaced CHANGES entry


> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



--
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-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-8933.
--
   Resolution: Fixed
Fix Version/s: 6.0.2
   5.5.2
   5.6

> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Fix For: 5.6, 5.5.2, master (7.0), 6.0.2, 6.1
>
> Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



--
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-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[ASF subversion and git services (JIRA)]

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

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

Commit 2049471579db8775dd3df01fd1386c7f43ed4b0e in lucene-solr's branch 
refs/heads/branch_5_5 from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2049471 ]

SOLR-8933: Solr should not close container streams.


> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



--
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] [Reopened] (SOLR-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-8933:
--

Reopening to backport to 6.0.2, 5.6 and 5.5.2.

> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



--
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-8866) UpdateLog should throw an exception when serializing unknown types

[ASF subversion and git services (JIRA)]

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

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

Commit e04c11f2af087eb2b321a34fa0dd5c4866c02fac in lucene-solr's branch 
refs/heads/branch_5x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e04c11f ]

SOLR-8866: UpdateLog now throws an error if it can't serialize a field value
(cherry picked from commit a22099a)


> UpdateLog should throw an exception when serializing unknown types
> --
>
> Key: SOLR-8866
> URL: https://issues.apache.org/jira/browse/SOLR-8866
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.1
>
> Attachments: SOLR_8866_UpdateLog_show_throw_for_unknown_types.patch
>
>
> When JavaBinCodec encounters a class it doesn't have explicit knowledge of 
> how to serialize, nor does it implement the {{ObjectResolver}} interface, it 
> currently serializes the object as the classname, colon, then toString() of 
> the object.
> This may appear innocent but _not_ throwing an exception hides bugs.  One 
> example is that the UpdateLog, which uses JavaBinCodec, to save a document.  
> The result is that this bad value winds up there, gets deserialized as a 
> String in PeerSync (which uses /get) and then this value pretends to be a 
> suitable value to the final document in the leader.  But of course it isn't.



--
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-8866) UpdateLog should throw an exception when serializing unknown types

[ASF subversion and git services (JIRA)]

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

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

Commit d2597ecace3da64397c5417905d1b439dbb2f675 in lucene-solr's branch 
refs/heads/branch_6_0 from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d2597ec ]

SOLR-8866: UpdateLog now throws an error if it can't serialize a field value
(cherry picked from commit a22099a)


> UpdateLog should throw an exception when serializing unknown types
> --
>
> Key: SOLR-8866
> URL: https://issues.apache.org/jira/browse/SOLR-8866
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.1
>
> Attachments: SOLR_8866_UpdateLog_show_throw_for_unknown_types.patch
>
>
> When JavaBinCodec encounters a class it doesn't have explicit knowledge of 
> how to serialize, nor does it implement the {{ObjectResolver}} interface, it 
> currently serializes the object as the classname, colon, then toString() of 
> the object.
> This may appear innocent but _not_ throwing an exception hides bugs.  One 
> example is that the UpdateLog, which uses JavaBinCodec, to save a document.  
> The result is that this bad value winds up there, gets deserialized as a 
> String in PeerSync (which uses /get) and then this value pretends to be a 
> suitable value to the final document in the leader.  But of course it isn't.



--
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-master-Linux (64bit/jdk1.8.0_92) - Build # 17006 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17006/
Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:45257/solr within 1 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:45257/solr within 1 ms
at 
__randomizedtesting.SeedInfo.seed([82ED2FD3D6DF749A:AB9100978231962]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:180)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:114)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:104)
at 
org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:227)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:502)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:951)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1599)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1620)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:176)
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:498)
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:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)

[jira] [Commented] (SOLR-8866) UpdateLog should throw an exception when serializing unknown types

[ASF subversion and git services (JIRA)]

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

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

Commit 8f64b63a0a47ba6d28984555956465600d9cd416 in lucene-solr's branch 
refs/heads/branch_5_5 from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8f64b63 ]

SOLR-8866: UpdateLog now throws an error if it can't serialize a field value
(cherry picked from commit a22099a)


> UpdateLog should throw an exception when serializing unknown types
> --
>
> Key: SOLR-8866
> URL: https://issues.apache.org/jira/browse/SOLR-8866
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.1
>
> Attachments: SOLR_8866_UpdateLog_show_throw_for_unknown_types.patch
>
>
> When JavaBinCodec encounters a class it doesn't have explicit knowledge of 
> how to serialize, nor does it implement the {{ObjectResolver}} interface, it 
> currently serializes the object as the classname, colon, then toString() of 
> the object.
> This may appear innocent but _not_ throwing an exception hides bugs.  One 
> example is that the UpdateLog, which uses JavaBinCodec, to save a document.  
> The result is that this bad value winds up there, gets deserialized as a 
> String in PeerSync (which uses /get) and then this value pretends to be a 
> suitable value to the final document in the leader.  But of course it isn't.



--
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] [Reopened] (SOLR-8866) UpdateLog should throw an exception when serializing unknown types

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-8866:
--

Reopening to backport to 6.0.2, 5.6 and 5.5.2.

> UpdateLog should throw an exception when serializing unknown types
> --
>
> Key: SOLR-8866
> URL: https://issues.apache.org/jira/browse/SOLR-8866
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.1
>
> Attachments: SOLR_8866_UpdateLog_show_throw_for_unknown_types.patch
>
>
> When JavaBinCodec encounters a class it doesn't have explicit knowledge of 
> how to serialize, nor does it implement the {{ObjectResolver}} interface, it 
> currently serializes the object as the classname, colon, then toString() of 
> the object.
> This may appear innocent but _not_ throwing an exception hides bugs.  One 
> example is that the UpdateLog, which uses JavaBinCodec, to save a document.  
> The result is that this bad value winds up there, gets deserialized as a 
> String in PeerSync (which uses /get) and then this value pretends to be a 
> suitable value to the final document in the leader.  But of course it isn't.



--
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-9176) Legacy Faceting Term Enum Method Regression

[ASF subversion and git services (JIRA)]

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

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

Commit 3ad19fecee2f4b0280208787e29e2b73db2dbe49 in lucene-solr's branch 
refs/heads/branch_5_5 from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3ad19fe ]

SOLR-9176: Fix facet method fallback selection


> Legacy Faceting Term Enum Method Regression
> ---
>
> Key: SOLR-9176
> URL: https://issues.apache.org/jira/browse/SOLR-9176
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1, 5.3.2, 5.4, 5.4.1, 5.5, 5.5.1, 
> 6.0, 6.0.1
>Reporter: Alessandro Benedetti
>Assignee: Alan Woodward
> Fix For: 5.6, 6.1, 5.5.2, 6.0.2
>
> Attachments: SOLR-9176.patch, SOLR-9176.patch
>
>
> Starting from this commit :
> LUCENE-5666: get solr started
> git-svn-id: 
> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene5666@1594254 
> 13f79535-47bb-0310-9956-ffa450edef68
> https://github.com/apache/lucene-solr/commit/1489085807cb10981a7ea5b5663ada4e3f85953e#diff-5ac9dc7b128b4dd99b764060759222b2
> It is not possible to use Term Enum as a faceting method, for numeric and 
> single valued fields ( org.apache.solr.request.SimpleFacets ) .
> We personally verified that there are use cases when this is bringing a quite 
> big performance regression  ( even with DocValues enabled) .
> In the mailing list from time to time people complain about a regression 
> happening with the term enum method, but actually it is more likely to be the 
>   automatic forcing of FCS.
> Forcing FCS in co-op with the famous regression that happened in SOLR-8096 
> could be confused as a term Enum regression.



--
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-9176) Legacy Faceting Term Enum Method Regression

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9176.
--
   Resolution: Fixed
Fix Version/s: 6.0.2
   5.5.2
   5.6

> Legacy Faceting Term Enum Method Regression
> ---
>
> Key: SOLR-9176
> URL: https://issues.apache.org/jira/browse/SOLR-9176
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1, 5.3.2, 5.4, 5.4.1, 5.5, 5.5.1, 
> 6.0, 6.0.1
>Reporter: Alessandro Benedetti
>Assignee: Alan Woodward
> Fix For: 5.6, 5.5.2, 6.0.2, 6.1
>
> Attachments: SOLR-9176.patch, SOLR-9176.patch
>
>
> Starting from this commit :
> LUCENE-5666: get solr started
> git-svn-id: 
> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene5666@1594254 
> 13f79535-47bb-0310-9956-ffa450edef68
> https://github.com/apache/lucene-solr/commit/1489085807cb10981a7ea5b5663ada4e3f85953e#diff-5ac9dc7b128b4dd99b764060759222b2
> It is not possible to use Term Enum as a faceting method, for numeric and 
> single valued fields ( org.apache.solr.request.SimpleFacets ) .
> We personally verified that there are use cases when this is bringing a quite 
> big performance regression  ( even with DocValues enabled) .
> In the mailing list from time to time people complain about a regression 
> happening with the term enum method, but actually it is more likely to be the 
>   automatic forcing of FCS.
> Forcing FCS in co-op with the famous regression that happened in SOLR-8096 
> could be confused as a term Enum regression.



--
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-9176) Legacy Faceting Term Enum Method Regression

[ASF subversion and git services (JIRA)]

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

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

Commit 3344d21dc812d1890c935c800e0715355f993975 in lucene-solr's branch 
refs/heads/branch_5x from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3344d21 ]

SOLR-9176: Fix facet method fallback selection


> Legacy Faceting Term Enum Method Regression
> ---
>
> Key: SOLR-9176
> URL: https://issues.apache.org/jira/browse/SOLR-9176
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1, 5.3.2, 5.4, 5.4.1, 5.5, 5.5.1, 
> 6.0, 6.0.1
>Reporter: Alessandro Benedetti
>Assignee: Alan Woodward
> Fix For: 5.6, 6.1, 5.5.2, 6.0.2
>
> Attachments: SOLR-9176.patch, SOLR-9176.patch
>
>
> Starting from this commit :
> LUCENE-5666: get solr started
> git-svn-id: 
> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene5666@1594254 
> 13f79535-47bb-0310-9956-ffa450edef68
> https://github.com/apache/lucene-solr/commit/1489085807cb10981a7ea5b5663ada4e3f85953e#diff-5ac9dc7b128b4dd99b764060759222b2
> It is not possible to use Term Enum as a faceting method, for numeric and 
> single valued fields ( org.apache.solr.request.SimpleFacets ) .
> We personally verified that there are use cases when this is bringing a quite 
> big performance regression  ( even with DocValues enabled) .
> In the mailing list from time to time people complain about a regression 
> happening with the term enum method, but actually it is more likely to be the 
>   automatic forcing of FCS.
> Forcing FCS in co-op with the famous regression that happened in SOLR-8096 
> could be confused as a term Enum regression.



--
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-9176) Legacy Faceting Term Enum Method Regression

[ASF subversion and git services (JIRA)]

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

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

Commit eb28958e1275bef7b5dd8c1a8b7268bc29dc5663 in lucene-solr's branch 
refs/heads/branch_6_0 from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eb28958 ]

SOLR-9176: Fix facet method fallback selection


> Legacy Faceting Term Enum Method Regression
> ---
>
> Key: SOLR-9176
> URL: https://issues.apache.org/jira/browse/SOLR-9176
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1, 5.3.2, 5.4, 5.4.1, 5.5, 5.5.1, 
> 6.0, 6.0.1
>Reporter: Alessandro Benedetti
>Assignee: Alan Woodward
> Fix For: 5.6, 6.1, 5.5.2, 6.0.2
>
> Attachments: SOLR-9176.patch, SOLR-9176.patch
>
>
> Starting from this commit :
> LUCENE-5666: get solr started
> git-svn-id: 
> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene5666@1594254 
> 13f79535-47bb-0310-9956-ffa450edef68
> https://github.com/apache/lucene-solr/commit/1489085807cb10981a7ea5b5663ada4e3f85953e#diff-5ac9dc7b128b4dd99b764060759222b2
> It is not possible to use Term Enum as a faceting method, for numeric and 
> single valued fields ( org.apache.solr.request.SimpleFacets ) .
> We personally verified that there are use cases when this is bringing a quite 
> big performance regression  ( even with DocValues enabled) .
> In the mailing list from time to time people complain about a regression 
> happening with the term enum method, but actually it is more likely to be the 
>   automatic forcing of FCS.
> Forcing FCS in co-op with the famous regression that happened in SOLR-8096 
> could be confused as a term Enum regression.



--
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] [Reopened] (SOLR-9176) Legacy Faceting Term Enum Method Regression

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-9176:
--

Reopening to backport to 6.0.2, 5.6 and 5.5.2.

> Legacy Faceting Term Enum Method Regression
> ---
>
> Key: SOLR-9176
> URL: https://issues.apache.org/jira/browse/SOLR-9176
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.2, 5.2.1, 5.3, 5.3.1, 5.3.2, 5.4, 5.4.1, 5.5, 5.5.1, 
> 6.0, 6.0.1
>Reporter: Alessandro Benedetti
>Assignee: Alan Woodward
> Fix For: 6.1
>
> Attachments: SOLR-9176.patch, SOLR-9176.patch
>
>
> Starting from this commit :
> LUCENE-5666: get solr started
> git-svn-id: 
> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene5666@1594254 
> 13f79535-47bb-0310-9956-ffa450edef68
> https://github.com/apache/lucene-solr/commit/1489085807cb10981a7ea5b5663ada4e3f85953e#diff-5ac9dc7b128b4dd99b764060759222b2
> It is not possible to use Term Enum as a faceting method, for numeric and 
> single valued fields ( org.apache.solr.request.SimpleFacets ) .
> We personally verified that there are use cases when this is bringing a quite 
> big performance regression  ( even with DocValues enabled) .
> In the mailing list from time to time people complain about a regression 
> happening with the term enum method, but actually it is more likely to be the 
>   automatic forcing of FCS.
> Forcing FCS in co-op with the famous regression that happened in SOLR-8096 
> could be confused as a term Enum regression.



--
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-8676) It's not possible to use a different log4.properties file on windows

[ASF subversion and git services (JIRA)]

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

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

Commit c20b41fe6b1d023a5bdf30e39afa1b470597bcc5 in lucene-solr's branch 
refs/heads/branch_5x from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c20b41f ]

SOLR-8676: keep LOG4J_CONFIG in solr.cmd


> It's not possible to use a different log4.properties file on windows
> 
>
> Key: SOLR-8676
> URL: https://issues.apache.org/jira/browse/SOLR-8676
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-8676.patch, SOLR-8676.patch, verifying SOLR-8676.txt
>
>
> It's currently not possible to change the location of the log4j.properties 
> file on windows. The value of {{LOG4J_CONFIG}} always gets replaced with the 
> default value {{server\resources\log4j.properties}}. Thus, this file inside 
> the server directory needs to be changed after every update.
> See attached patch for a fix. Unfortunately, I couldn't figure out why 
> {{LOG4J_CONFIG}} was set to empty. I tested manually that logging still works 
> when running an example so I hope that this line is really just obsolete.



--
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-8676) It's not possible to use a different log4.properties file on windows

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-8676.
--
   Resolution: Fixed
Fix Version/s: 6.0.2
   5.5.2
   5.6

> It's not possible to use a different log4.properties file on windows
> 
>
> Key: SOLR-8676
> URL: https://issues.apache.org/jira/browse/SOLR-8676
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 5.6, 5.5.2, master (7.0), 6.0.2, 6.1
>
> Attachments: SOLR-8676.patch, SOLR-8676.patch, verifying SOLR-8676.txt
>
>
> It's currently not possible to change the location of the log4j.properties 
> file on windows. The value of {{LOG4J_CONFIG}} always gets replaced with the 
> default value {{server\resources\log4j.properties}}. Thus, this file inside 
> the server directory needs to be changed after every update.
> See attached patch for a fix. Unfortunately, I couldn't figure out why 
> {{LOG4J_CONFIG}} was set to empty. I tested manually that logging still works 
> when running an example so I hope that this line is really just obsolete.



--
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-8676) It's not possible to use a different log4.properties file on windows

[ASF subversion and git services (JIRA)]

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

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

Commit 60c140c244c4f93bbd3af2fe1b6244101a8db971 in lucene-solr's branch 
refs/heads/branch_6_0 from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=60c140c ]

SOLR-8676: keep LOG4J_CONFIG in solr.cmd


> It's not possible to use a different log4.properties file on windows
> 
>
> Key: SOLR-8676
> URL: https://issues.apache.org/jira/browse/SOLR-8676
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-8676.patch, SOLR-8676.patch, verifying SOLR-8676.txt
>
>
> It's currently not possible to change the location of the log4j.properties 
> file on windows. The value of {{LOG4J_CONFIG}} always gets replaced with the 
> default value {{server\resources\log4j.properties}}. Thus, this file inside 
> the server directory needs to be changed after every update.
> See attached patch for a fix. Unfortunately, I couldn't figure out why 
> {{LOG4J_CONFIG}} was set to empty. I tested manually that logging still works 
> when running an example so I hope that this line is really just obsolete.



--
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-8676) It's not possible to use a different log4.properties file on windows

[ASF subversion and git services (JIRA)]

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

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

Commit 3d8a6b0cb8be7c5e7fc683d13034d74d46238c44 in lucene-solr's branch 
refs/heads/branch_5_5 from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3d8a6b0 ]

SOLR-8676: keep LOG4J_CONFIG in solr.cmd


> It's not possible to use a different log4.properties file on windows
> 
>
> Key: SOLR-8676
> URL: https://issues.apache.org/jira/browse/SOLR-8676
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-8676.patch, SOLR-8676.patch, verifying SOLR-8676.txt
>
>
> It's currently not possible to change the location of the log4j.properties 
> file on windows. The value of {{LOG4J_CONFIG}} always gets replaced with the 
> default value {{server\resources\log4j.properties}}. Thus, this file inside 
> the server directory needs to be changed after every update.
> See attached patch for a fix. Unfortunately, I couldn't figure out why 
> {{LOG4J_CONFIG}} was set to empty. I tested manually that logging still works 
> when running an example so I hope that this line is really just obsolete.



--
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] [Reopened] (SOLR-8676) It's not possible to use a different log4.properties file on windows

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-8676:
--

Reopening to backport to 6.0.2, 5.6 and 5.5.2.

> It's not possible to use a different log4.properties file on windows
> 
>
> Key: SOLR-8676
> URL: https://issues.apache.org/jira/browse/SOLR-8676
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8676.patch, SOLR-8676.patch, verifying SOLR-8676.txt
>
>
> It's currently not possible to change the location of the log4j.properties 
> file on windows. The value of {{LOG4J_CONFIG}} always gets replaced with the 
> default value {{server\resources\log4j.properties}}. Thus, this file inside 
> the server directory needs to be changed after every update.
> See attached patch for a fix. Unfortunately, I couldn't figure out why 
> {{LOG4J_CONFIG}} was set to empty. I tested manually that logging still works 
> when running an example so I hope that this line is really just obsolete.



--
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-8612) DIH JdbcDataSource - statement not always closed

[ASF subversion and git services (JIRA)]

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

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

Commit 66dd9bc63b0492a00bd55a9cc986818ef81afb95 in lucene-solr's branch 
refs/heads/branch_5x from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=66dd9bc ]

SOLR-8612: closing JDBC Statement on exceptions from JdbcDataSource in 
DataImportHandler aka DIH (Kristine Jetzke via Mikhail Khludnev)


> DIH JdbcDataSource - statement not always closed
> 
>
> Key: SOLR-8612
> URL: https://issues.apache.org/jira/browse/SOLR-8612
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-8612.patch, SOLR-8612.patch, SOLR-8612.patch, 
> SOLR-8612.patch, SOLR-8612.patch
>
>
> There are several cases where the Statement used by JdbcDataSource is not 
> closed, potentially resulting in too many open connections:
> - an exception is throw in the {{ResultSetIterator}} constructor
> - the result set is null in the {{ResultSetIterator}} constructor
> - an exception is thrown during import and the import is aborted (onError 
> flag set to abort)



--
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-8612) DIH JdbcDataSource - statement not always closed

[ASF subversion and git services (JIRA)]

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

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

Commit 0cd5356a7305be90f7817bd00906e09a5ef2d736 in lucene-solr's branch 
refs/heads/branch_5_5 from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0cd5356 ]

SOLR-8612: closing JDBC Statement on exceptions from JdbcDataSource in 
DataImportHandler aka DIH (Kristine Jetzke via Mikhail Khludnev)


> DIH JdbcDataSource - statement not always closed
> 
>
> Key: SOLR-8612
> URL: https://issues.apache.org/jira/browse/SOLR-8612
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-8612.patch, SOLR-8612.patch, SOLR-8612.patch, 
> SOLR-8612.patch, SOLR-8612.patch
>
>
> There are several cases where the Statement used by JdbcDataSource is not 
> closed, potentially resulting in too many open connections:
> - an exception is throw in the {{ResultSetIterator}} constructor
> - the result set is null in the {{ResultSetIterator}} constructor
> - an exception is thrown during import and the import is aborted (onError 
> flag set to abort)



--
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-8612) DIH JdbcDataSource - statement not always closed

[ASF subversion and git services (JIRA)]

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

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

Commit 7e2252cbc0b0783b442d0f76d5312ec6f379f0ae in lucene-solr's branch 
refs/heads/branch_6_0 from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7e2252c ]

SOLR-8612: closing JDBC Statement on exceptions from JdbcDataSource in 
DataImportHandler aka DIH (Kristine Jetzke via Mikhail Khludnev)


> DIH JdbcDataSource - statement not always closed
> 
>
> Key: SOLR-8612
> URL: https://issues.apache.org/jira/browse/SOLR-8612
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-8612.patch, SOLR-8612.patch, SOLR-8612.patch, 
> SOLR-8612.patch, SOLR-8612.patch
>
>
> There are several cases where the Statement used by JdbcDataSource is not 
> closed, potentially resulting in too many open connections:
> - an exception is throw in the {{ResultSetIterator}} constructor
> - the result set is null in the {{ResultSetIterator}} constructor
> - an exception is thrown during import and the import is aborted (onError 
> flag set to abort)



--
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-8612) DIH JdbcDataSource - statement not always closed

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-8612.
--
   Resolution: Fixed
Fix Version/s: 6.0.2
   5.5.2
   5.6

> DIH JdbcDataSource - statement not always closed
> 
>
> Key: SOLR-8612
> URL: https://issues.apache.org/jira/browse/SOLR-8612
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 5.6, 5.5.2, master (7.0), 6.0.2, 6.1
>
> Attachments: SOLR-8612.patch, SOLR-8612.patch, SOLR-8612.patch, 
> SOLR-8612.patch, SOLR-8612.patch
>
>
> There are several cases where the Statement used by JdbcDataSource is not 
> closed, potentially resulting in too many open connections:
> - an exception is throw in the {{ResultSetIterator}} constructor
> - the result set is null in the {{ResultSetIterator}} constructor
> - an exception is thrown during import and the import is aborted (onError 
> flag set to abort)



--
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] [Reopened] (SOLR-8612) DIH JdbcDataSource - statement not always closed

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-8612:
--

Reopening to backport to 6.0.2, 5.6 and 5.5.2.

> DIH JdbcDataSource - statement not always closed
> 
>
> Key: SOLR-8612
> URL: https://issues.apache.org/jira/browse/SOLR-8612
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8612.patch, SOLR-8612.patch, SOLR-8612.patch, 
> SOLR-8612.patch, SOLR-8612.patch
>
>
> There are several cases where the Statement used by JdbcDataSource is not 
> closed, potentially resulting in too many open connections:
> - an exception is throw in the {{ResultSetIterator}} constructor
> - the result set is null in the {{ResultSetIterator}} constructor
> - an exception is thrown during import and the import is aborted (onError 
> flag set to abort)



--
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-9165) Problems with the spellcheck component running search with cursor

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9165.
--
   Resolution: Fixed
Fix Version/s: 6.0.2
   5.5.2
   5.6

> Problems with the spellcheck component  running search with cursor
> --
>
> Key: SOLR-9165
> URL: https://issues.apache.org/jira/browse/SOLR-9165
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 5.2
>Reporter: Yamileydis Veranes
>Assignee: James Dyer
> Fix For: 5.6, 5.5.2, 6.0.2, 6.1
>
> Attachments: SOLR-9165.patch, SOLR-9165.patch
>
>
> I'm having some problems with the spellcheck component, specifically, running 
> a search with cursors.  
> When I run the following query:
> http://192.1.1.13:8983/solr/docs/search?q=insendio=/search=192.1.1.14:8983/solr/docs,192.1.1.15:8983/solr/docs=id=true=score
>  desc,id asc
> the following collations are returned
> 
> 
> incendio
> 485
> 
> incendio
> 
> 
> 
> Instead, when I try to run the same query but this time using cursors
> http://192.1.1.13:8983/solr/docs/search?q=insendio=/search=192.1.1.14:8983/solr/docs,192.1.1.15:8983/solr/docs=id=true=score
>  desc,id asc=*
> no collations are returned
> false
> and the server trace the following exception message.
> WARN  - 2016-05-26 14:14:58.472; [docs shard2 core_node4 
> docs_shard2_replica1] org.apache.solr.spelling.SpellCheckCollator; Exception 
> trying to re-query to check if a spell check possibility would return any 
> hits.
> org.apache.solr.common.SolrException: Cursor functionality requires a sort 
> containing a uniqueKey field tie breaker
>   at org.apache.solr.search.CursorMark.(CursorMark.java:93)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:189)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:141)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:237)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:202)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   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.eclipseInstead.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:497)
>   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)



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

-
To unsubscribe, e-mail: 

[jira] [Commented] (SOLR-9165) Problems with the spellcheck component running search with cursor

[ASF subversion and git services (JIRA)]

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

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

Commit 7b79571d948365658e00f0bb431c082dedca1aaf in lucene-solr's branch 
refs/heads/branch_6_0 from jdyer1
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7b79571 ]

SOLR-9165: disable "cursorMark" when testing for valid SpellCheck Collations


> Problems with the spellcheck component  running search with cursor
> --
>
> Key: SOLR-9165
> URL: https://issues.apache.org/jira/browse/SOLR-9165
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 5.2
>Reporter: Yamileydis Veranes
>Assignee: James Dyer
> Fix For: 5.6, 6.1, 5.5.2, 6.0.2
>
> Attachments: SOLR-9165.patch, SOLR-9165.patch
>
>
> I'm having some problems with the spellcheck component, specifically, running 
> a search with cursors.  
> When I run the following query:
> http://192.1.1.13:8983/solr/docs/search?q=insendio=/search=192.1.1.14:8983/solr/docs,192.1.1.15:8983/solr/docs=id=true=score
>  desc,id asc
> the following collations are returned
> 
> 
> incendio
> 485
> 
> incendio
> 
> 
> 
> Instead, when I try to run the same query but this time using cursors
> http://192.1.1.13:8983/solr/docs/search?q=insendio=/search=192.1.1.14:8983/solr/docs,192.1.1.15:8983/solr/docs=id=true=score
>  desc,id asc=*
> no collations are returned
> false
> and the server trace the following exception message.
> WARN  - 2016-05-26 14:14:58.472; [docs shard2 core_node4 
> docs_shard2_replica1] org.apache.solr.spelling.SpellCheckCollator; Exception 
> trying to re-query to check if a spell check possibility would return any 
> hits.
> org.apache.solr.common.SolrException: Cursor functionality requires a sort 
> containing a uniqueKey field tie breaker
>   at org.apache.solr.search.CursorMark.(CursorMark.java:93)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:189)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:141)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:237)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:202)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   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.eclipseInstead.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:497)
>   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 
> 

[jira] [Commented] (SOLR-9165) Problems with the spellcheck component running search with cursor

[ASF subversion and git services (JIRA)]

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

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

Commit 845f57d16ad1b9f6b499d8597f2fb1edbd571474 in lucene-solr's branch 
refs/heads/branch_5_5 from jdyer1
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=845f57d ]

SOLR-9165: disable "cursorMark" when testing for valid SpellCheck Collations


> Problems with the spellcheck component  running search with cursor
> --
>
> Key: SOLR-9165
> URL: https://issues.apache.org/jira/browse/SOLR-9165
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 5.2
>Reporter: Yamileydis Veranes
>Assignee: James Dyer
> Fix For: 5.6, 6.1, 5.5.2, 6.0.2
>
> Attachments: SOLR-9165.patch, SOLR-9165.patch
>
>
> I'm having some problems with the spellcheck component, specifically, running 
> a search with cursors.  
> When I run the following query:
> http://192.1.1.13:8983/solr/docs/search?q=insendio=/search=192.1.1.14:8983/solr/docs,192.1.1.15:8983/solr/docs=id=true=score
>  desc,id asc
> the following collations are returned
> 
> 
> incendio
> 485
> 
> incendio
> 
> 
> 
> Instead, when I try to run the same query but this time using cursors
> http://192.1.1.13:8983/solr/docs/search?q=insendio=/search=192.1.1.14:8983/solr/docs,192.1.1.15:8983/solr/docs=id=true=score
>  desc,id asc=*
> no collations are returned
> false
> and the server trace the following exception message.
> WARN  - 2016-05-26 14:14:58.472; [docs shard2 core_node4 
> docs_shard2_replica1] org.apache.solr.spelling.SpellCheckCollator; Exception 
> trying to re-query to check if a spell check possibility would return any 
> hits.
> org.apache.solr.common.SolrException: Cursor functionality requires a sort 
> containing a uniqueKey field tie breaker
>   at org.apache.solr.search.CursorMark.(CursorMark.java:93)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:189)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:141)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:237)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:202)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   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.eclipseInstead.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:497)
>   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 
> 

[jira] [Commented] (SOLR-9165) Problems with the spellcheck component running search with cursor

[ASF subversion and git services (JIRA)]

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

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

Commit b4d81f784136b6c3fd19940055b812862baa99ca in lucene-solr's branch 
refs/heads/branch_5x from jdyer1
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b4d81f7 ]

SOLR-9165: disable "cursorMark" when testing for valid SpellCheck Collations


> Problems with the spellcheck component  running search with cursor
> --
>
> Key: SOLR-9165
> URL: https://issues.apache.org/jira/browse/SOLR-9165
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 5.2
>Reporter: Yamileydis Veranes
>Assignee: James Dyer
> Fix For: 5.6, 6.1, 5.5.2, 6.0.2
>
> Attachments: SOLR-9165.patch, SOLR-9165.patch
>
>
> I'm having some problems with the spellcheck component, specifically, running 
> a search with cursors.  
> When I run the following query:
> http://192.1.1.13:8983/solr/docs/search?q=insendio=/search=192.1.1.14:8983/solr/docs,192.1.1.15:8983/solr/docs=id=true=score
>  desc,id asc
> the following collations are returned
> 
> 
> incendio
> 485
> 
> incendio
> 
> 
> 
> Instead, when I try to run the same query but this time using cursors
> http://192.1.1.13:8983/solr/docs/search?q=insendio=/search=192.1.1.14:8983/solr/docs,192.1.1.15:8983/solr/docs=id=true=score
>  desc,id asc=*
> no collations are returned
> false
> and the server trace the following exception message.
> WARN  - 2016-05-26 14:14:58.472; [docs shard2 core_node4 
> docs_shard2_replica1] org.apache.solr.spelling.SpellCheckCollator; Exception 
> trying to re-query to check if a spell check possibility would return any 
> hits.
> org.apache.solr.common.SolrException: Cursor functionality requires a sort 
> containing a uniqueKey field tie breaker
>   at org.apache.solr.search.CursorMark.(CursorMark.java:93)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:189)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:141)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:237)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:202)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   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.eclipseInstead.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:497)
>   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 
> 

[jira] [Reopened] (SOLR-9165) Problems with the spellcheck component running search with cursor

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-9165:
--

Reopening to backport to 6.0.2, 5.6 and 5.5.2.

> Problems with the spellcheck component  running search with cursor
> --
>
> Key: SOLR-9165
> URL: https://issues.apache.org/jira/browse/SOLR-9165
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 5.2
>Reporter: Yamileydis Veranes
>Assignee: James Dyer
> Fix For: 6.1
>
> Attachments: SOLR-9165.patch, SOLR-9165.patch
>
>
> I'm having some problems with the spellcheck component, specifically, running 
> a search with cursors.  
> When I run the following query:
> http://192.1.1.13:8983/solr/docs/search?q=insendio=/search=192.1.1.14:8983/solr/docs,192.1.1.15:8983/solr/docs=id=true=score
>  desc,id asc
> the following collations are returned
> 
> 
> incendio
> 485
> 
> incendio
> 
> 
> 
> Instead, when I try to run the same query but this time using cursors
> http://192.1.1.13:8983/solr/docs/search?q=insendio=/search=192.1.1.14:8983/solr/docs,192.1.1.15:8983/solr/docs=id=true=score
>  desc,id asc=*
> no collations are returned
> false
> and the server trace the following exception message.
> WARN  - 2016-05-26 14:14:58.472; [docs shard2 core_node4 
> docs_shard2_replica1] org.apache.solr.spelling.SpellCheckCollator; Exception 
> trying to re-query to check if a spell check possibility would return any 
> hits.
> org.apache.solr.common.SolrException: Cursor functionality requires a sort 
> containing a uniqueKey field tie breaker
>   at org.apache.solr.search.CursorMark.(CursorMark.java:93)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:189)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:141)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:237)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:202)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   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.eclipseInstead.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:497)
>   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)



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

[jira] [Updated] (SOLR-9165) Problems with the spellcheck component running search with cursor

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-9165:
-
Fix Version/s: 6.1

> Problems with the spellcheck component  running search with cursor
> --
>
> Key: SOLR-9165
> URL: https://issues.apache.org/jira/browse/SOLR-9165
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 5.2
>Reporter: Yamileydis Veranes
>Assignee: James Dyer
> Fix For: 6.1
>
> Attachments: SOLR-9165.patch, SOLR-9165.patch
>
>
> I'm having some problems with the spellcheck component, specifically, running 
> a search with cursors.  
> When I run the following query:
> http://192.1.1.13:8983/solr/docs/search?q=insendio=/search=192.1.1.14:8983/solr/docs,192.1.1.15:8983/solr/docs=id=true=score
>  desc,id asc
> the following collations are returned
> 
> 
> incendio
> 485
> 
> incendio
> 
> 
> 
> Instead, when I try to run the same query but this time using cursors
> http://192.1.1.13:8983/solr/docs/search?q=insendio=/search=192.1.1.14:8983/solr/docs,192.1.1.15:8983/solr/docs=id=true=score
>  desc,id asc=*
> no collations are returned
> false
> and the server trace the following exception message.
> WARN  - 2016-05-26 14:14:58.472; [docs shard2 core_node4 
> docs_shard2_replica1] org.apache.solr.spelling.SpellCheckCollator; Exception 
> trying to re-query to check if a spell check possibility would return any 
> hits.
> org.apache.solr.common.SolrException: Cursor functionality requires a sort 
> containing a uniqueKey field tie breaker
>   at org.apache.solr.search.CursorMark.(CursorMark.java:93)
>   at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:189)
>   at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:141)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:237)
>   at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:202)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   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.eclipseInstead.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:497)
>   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)



--
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-9151) solr -e cloud broken if $PWD is / on Linux

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9151.
--
   Resolution: Fixed
Fix Version/s: 6.0.2
   5.5.2
   5.6

> solr -e cloud broken if $PWD is / on Linux
> --
>
> Key: SOLR-9151
> URL: https://issues.apache.org/jira/browse/SOLR-9151
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, 6.0
> Environment: Solr Docker Container
>Reporter: Hari Sekhon
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 5.6, 5.5.2, master (7.0), 6.0.2, 6.1
>
> Attachments: SOLR-9151.patch
>
>
> Solr scripts for cloud example break if called from a directory other than 
> $SOLR_HOME, ie $PWD is not $SOLR_HOME: It always strips off the beginning of 
> the path. This used to work regardless in Solr 4.x as I used to use it quite 
> a lot and my custom solr 4.x docker containers it still works regardless of 
> $PWD - it's only broken in 5x/6.0.
> Here is an example of the issue:
> {code}docker run -ti solr bash
> solr@5083b8e59d49:/opt/solr$ cd /
> solr@5083b8e59d49:/$ solr -e cloud
> Welcome to the SolrCloud example!
> This interactive session will help you launch a SolrCloud cluster on your 
> local workstation.
> To begin, how many Solr nodes would you like to run in your local cluster? 
> (specify 1-4 nodes) [2]: 
> Ok, let's start up 2 Solr nodes for your example SolrCloud cluster.
> Please enter the port for node1 [8983]: 
> Please enter the port for node2 [7574]: 
> Creating Solr home directory /opt/solr/example/cloud/node1/solr
> Cloning /opt/solr/example/cloud/node1 into
>/opt/solr/example/cloud/node2
> Starting up Solr on port 8983 using command:
> /opt/solr/bin/solr start -cloud -p 8983 -s "pt/solr/example/cloud/node1/solr"
> Solr home directory pt/solr/example/cloud/node1/solr not found!
> ERROR: Process exited with an error: 1 (Exit value: 1)
>  {code}



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

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

[jira] [Commented] (SOLR-9151) solr -e cloud broken if $PWD is / on Linux

[ASF subversion and git services (JIRA)]

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

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

Commit 1850d9bbb0e27a6a1229c59cc76cf4dc4afe8862 in lucene-solr's branch 
refs/heads/branch_5x from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1850d9b ]

SOLR-9151: Fix SolrCLI so that bin/solr -e cloud example can be run from any CWD
(cherry picked from commit 50c4f58)


> solr -e cloud broken if $PWD is / on Linux
> --
>
> Key: SOLR-9151
> URL: https://issues.apache.org/jira/browse/SOLR-9151
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, 6.0
> Environment: Solr Docker Container
>Reporter: Hari Sekhon
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-9151.patch
>
>
> Solr scripts for cloud example break if called from a directory other than 
> $SOLR_HOME, ie $PWD is not $SOLR_HOME: It always strips off the beginning of 
> the path. This used to work regardless in Solr 4.x as I used to use it quite 
> a lot and my custom solr 4.x docker containers it still works regardless of 
> $PWD - it's only broken in 5x/6.0.
> Here is an example of the issue:
> {code}docker run -ti solr bash
> solr@5083b8e59d49:/opt/solr$ cd /
> solr@5083b8e59d49:/$ solr -e cloud
> Welcome to the SolrCloud example!
> This interactive session will help you launch a SolrCloud cluster on your 
> local workstation.
> To begin, how many Solr nodes would you like to run in your local cluster? 
> (specify 1-4 nodes) [2]: 
> Ok, let's start up 2 Solr nodes for your example SolrCloud cluster.
> Please enter the port for node1 [8983]: 
> Please enter the port for node2 [7574]: 
> Creating Solr home directory /opt/solr/example/cloud/node1/solr
> Cloning /opt/solr/example/cloud/node1 into
>/opt/solr/example/cloud/node2
> Starting up Solr on port 8983 using command:
> /opt/solr/bin/solr start -cloud -p 8983 -s "pt/solr/example/cloud/node1/solr"
> Solr home directory pt/solr/example/cloud/node1/solr not found!
> ERROR: Process exited with an error: 1 (Exit value: 1)
>  {code}



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

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

[jira] [Commented] (SOLR-9151) solr -e cloud broken if $PWD is / on Linux

[ASF subversion and git services (JIRA)]

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

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

Commit 6d8fda0d606fc9add49202fee4c85a2c90412557 in lucene-solr's branch 
refs/heads/branch_5_5 from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6d8fda0 ]

SOLR-9151: Fix SolrCLI so that bin/solr -e cloud example can be run from any CWD
(cherry picked from commit 50c4f58)


> solr -e cloud broken if $PWD is / on Linux
> --
>
> Key: SOLR-9151
> URL: https://issues.apache.org/jira/browse/SOLR-9151
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, 6.0
> Environment: Solr Docker Container
>Reporter: Hari Sekhon
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-9151.patch
>
>
> Solr scripts for cloud example break if called from a directory other than 
> $SOLR_HOME, ie $PWD is not $SOLR_HOME: It always strips off the beginning of 
> the path. This used to work regardless in Solr 4.x as I used to use it quite 
> a lot and my custom solr 4.x docker containers it still works regardless of 
> $PWD - it's only broken in 5x/6.0.
> Here is an example of the issue:
> {code}docker run -ti solr bash
> solr@5083b8e59d49:/opt/solr$ cd /
> solr@5083b8e59d49:/$ solr -e cloud
> Welcome to the SolrCloud example!
> This interactive session will help you launch a SolrCloud cluster on your 
> local workstation.
> To begin, how many Solr nodes would you like to run in your local cluster? 
> (specify 1-4 nodes) [2]: 
> Ok, let's start up 2 Solr nodes for your example SolrCloud cluster.
> Please enter the port for node1 [8983]: 
> Please enter the port for node2 [7574]: 
> Creating Solr home directory /opt/solr/example/cloud/node1/solr
> Cloning /opt/solr/example/cloud/node1 into
>/opt/solr/example/cloud/node2
> Starting up Solr on port 8983 using command:
> /opt/solr/bin/solr start -cloud -p 8983 -s "pt/solr/example/cloud/node1/solr"
> Solr home directory pt/solr/example/cloud/node1/solr not found!
> ERROR: Process exited with an error: 1 (Exit value: 1)
>  {code}



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

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

[jira] [Commented] (SOLR-9151) solr -e cloud broken if $PWD is / on Linux

[ASF subversion and git services (JIRA)]

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

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

Commit b866e594d18ae47271b87e7dedd06ae26d622801 in lucene-solr's branch 
refs/heads/branch_6_0 from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b866e59 ]

SOLR-9151: Fix SolrCLI so that bin/solr -e cloud example can be run from any CWD
(cherry picked from commit 50c4f58)


> solr -e cloud broken if $PWD is / on Linux
> --
>
> Key: SOLR-9151
> URL: https://issues.apache.org/jira/browse/SOLR-9151
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, 6.0
> Environment: Solr Docker Container
>Reporter: Hari Sekhon
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 5.6, 6.1, 5.5.2, master (7.0), 6.0.2
>
> Attachments: SOLR-9151.patch
>
>
> Solr scripts for cloud example break if called from a directory other than 
> $SOLR_HOME, ie $PWD is not $SOLR_HOME: It always strips off the beginning of 
> the path. This used to work regardless in Solr 4.x as I used to use it quite 
> a lot and my custom solr 4.x docker containers it still works regardless of 
> $PWD - it's only broken in 5x/6.0.
> Here is an example of the issue:
> {code}docker run -ti solr bash
> solr@5083b8e59d49:/opt/solr$ cd /
> solr@5083b8e59d49:/$ solr -e cloud
> Welcome to the SolrCloud example!
> This interactive session will help you launch a SolrCloud cluster on your 
> local workstation.
> To begin, how many Solr nodes would you like to run in your local cluster? 
> (specify 1-4 nodes) [2]: 
> Ok, let's start up 2 Solr nodes for your example SolrCloud cluster.
> Please enter the port for node1 [8983]: 
> Please enter the port for node2 [7574]: 
> Creating Solr home directory /opt/solr/example/cloud/node1/solr
> Cloning /opt/solr/example/cloud/node1 into
>/opt/solr/example/cloud/node2
> Starting up Solr on port 8983 using command:
> /opt/solr/bin/solr start -cloud -p 8983 -s "pt/solr/example/cloud/node1/solr"
> Solr home directory pt/solr/example/cloud/node1/solr not found!
> ERROR: Process exited with an error: 1 (Exit value: 1)
>  {code}



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

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

[jira] [Reopened] (SOLR-9151) solr -e cloud broken if $PWD is / on Linux

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-9151:
--

Reopening to backport to 6.0.2, 5.6 and 5.5.2.

> solr -e cloud broken if $PWD is / on Linux
> --
>
> Key: SOLR-9151
> URL: https://issues.apache.org/jira/browse/SOLR-9151
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, 6.0
> Environment: Solr Docker Container
>Reporter: Hari Sekhon
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9151.patch
>
>
> Solr scripts for cloud example break if called from a directory other than 
> $SOLR_HOME, ie $PWD is not $SOLR_HOME: It always strips off the beginning of 
> the path. This used to work regardless in Solr 4.x as I used to use it quite 
> a lot and my custom solr 4.x docker containers it still works regardless of 
> $PWD - it's only broken in 5x/6.0.
> Here is an example of the issue:
> {code}docker run -ti solr bash
> solr@5083b8e59d49:/opt/solr$ cd /
> solr@5083b8e59d49:/$ solr -e cloud
> Welcome to the SolrCloud example!
> This interactive session will help you launch a SolrCloud cluster on your 
> local workstation.
> To begin, how many Solr nodes would you like to run in your local cluster? 
> (specify 1-4 nodes) [2]: 
> Ok, let's start up 2 Solr nodes for your example SolrCloud cluster.
> Please enter the port for node1 [8983]: 
> Please enter the port for node2 [7574]: 
> Creating Solr home directory /opt/solr/example/cloud/node1/solr
> Cloning /opt/solr/example/cloud/node1 into
>/opt/solr/example/cloud/node2
> Starting up Solr on port 8983 using command:
> /opt/solr/bin/solr start -cloud -p 8983 -s "pt/solr/example/cloud/node1/solr"
> Solr home directory pt/solr/example/cloud/node1/solr not found!
> ERROR: Process exited with an error: 1 (Exit value: 1)
>  {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

Accelerated Lucene Indexing

[Steve Casselman]

Hi Mike. I'm writing code for the Altera OpenCL SDK. I have a code base that
gives me a non-Lucene format index. I was wondering in your benchmark what
kind of data do you collect? Do you collect all the position and frequency
data? I'm also curious about what you see as the biggest bottleneck in
creating an index? Is it creating the index from the data or merging the
indexes?  Or something else? Do you feel the algorithm is CPU, memory or
disk bound? And finally do you think there is a market for accelerated
indexing? Say I could quadruple the price performance yet still make 100%
Lucene compatible indexes, would people pay for that? 

 

 

Thanks

 

Steve 

 

[jira] [Commented] (SOLR-9153) Update beanutils version to 1.9.2

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-9153:
-

Bump? This should be a relatively low risk change, if anybody has the cycles to 
look at it.

> Update beanutils version to 1.9.2
> -
>
> Key: SOLR-9153
> URL: https://issues.apache.org/jira/browse/SOLR-9153
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - Velocity
>Affects Versions: 6.0
>Reporter: Mike Drob
>Priority: Minor
> Attachments: SOLR-9153.patch
>
>
> See CVE-2014-0114 -- 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114
> {quote}
> Apache Commons BeanUtils, as distributed in lib/commons-beanutils-1.8.0.jar 
> in Apache Struts 1.x through 1.3.10 and in other products requiring 
> commons-beanutils through 1.9.2, does not suppress the class property, which 
> allows remote attackers to "manipulate" the ClassLoader and execute arbitrary 
> code via the class parameter, as demonstrated by the passing of this 
> parameter to the getClass method of the ActionForm object in Struts 1. 
> {quote}
> We transitively depend on BeanUtils through Velocity, but it doesn't look 
> like there is much movement on the project there. See BEANUTILS-463 and 
> VELTOOLS-170
> Also, this might have impact on SOLR-3736 but that issue also looks largely 
> abandoned.



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

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

Re: [JENKINS] Lucene-Solr-5.5-Linux (32bit/jdk1.7.0_80) - Build # 292 - Failure!

[Steve Rowe]

No problem, will do.

--
Steve
www.lucidworks.com

> On Jun 17, 2016, at 6:40 PM, Michael McCandless  
> wrote:
> 
> Ugh sorry I spaced out!  Can you cherry-pick?  Thanks.
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com
> 
> On Fri, Jun 17, 2016 at 4:44 PM, Steve Rowe  wrote:
> Thanks Mike!
> 
> I noticed you didn’t push to branch_5_5 - was that just an oversight, or am I 
> being too impatient?  (I can cherry-pick it if you’d like me to.)
> 
> --
> Steve
> www.lucidworks.com
> 
> > On Jun 17, 2016, at 2:56 PM, Michael McCandless  
> > wrote:
> >
> > Hi Steve,
> >
> > I dug some more, and I think this small change fixes the buggy test:
> >
> > diff --git 
> > a/lucene/core/src/test/org/apache/lucene/search/TestBoolean2.java 
> > b/lucene/core/src/test/org/apache/lucene/search/TestBoolean2.java
> > index d97d8d4..f4ead23 100644
> > --- a/lucene/core/src/test/org/apache/lucene/search/TestBoolean2.java
> > +++ b/lucene/core/src/test/org/apache/lucene/search/TestBoolean2.java
> > @@ -165,7 +165,7 @@ public class TestBoolean2 extends LuceneTestCase {
> >  "w1 w2 w3 w4 w5",
> >  "w1 w3 w2 w3",
> >  "w1 xx w2 yy w3",
> > -"w1 w3 xx w2 yy w3"
> > +"w1 w3 xx w2 yy mm"
> >};
> >
> >public void queriesTest(Query query, int[] expDocNrs) throws Exception {
> >
> >
> > Those strings are the documents that the test indexes, and the root cause 
> > of the failure is that w3 appears twice in the last document (tf=2), and 
> > the last document is longer.  The test assumed (illegally) that the last 
> > document would always get a worst score than the one before it, but that's 
> > up to the similarity and something changed here between 5.x and 6.x.
> >
> > I'll push this shortly to 5.x, 6.x, master...
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> > On Fri, Jun 17, 2016 at 11:08 AM, Steve Rowe  wrote:
> > Thanks for digging, Mike.
> >
> > These tests aren’t failing on 6.x (including the backport to branch_6_0: 
> > 0/100 TestBoolean2 beasting failures just nnw) - in your digging did you 
> > come across anything that would explain that?
> >
> > I’d rather not revert this bugfix backport just because it exposed other, 
> > possibly test-only?, bugs, but I understand that spending a bunch of time 
> > on an old patch release is non-optimal :).
> >
> > --
> > Steve
> > www.lucidworks.com
> >
> > > On Jun 17, 2016, at 9:45 AM, Michael McCandless 
> > >  wrote:
> > >
> > > OK I dug a bit, specifically on this test failure:
> > >
> > > ant test  -Dtestcase=TestBoolean2 -Dtests.method=testQueries01 
> > > -Dtests.seed=5787EE10A58E0A9C -Dtests.multiplier=3 -Dtests.slow=true 
> > > -Dtests.locale=nn-NO -Dtests.timezone=America/St_Vincent 
> > > -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> > >
> > > and something else is at play: this particular test case uses 
> > > ConjunctionScorer, not BooleanScorer (where the original bug was).
> > >
> > > What happens for this failing seed is the correct 2 documents match, but 
> > > the 2nd one unexpectedly gets a better score, possibly only when enough 
> > > filler docs were added.  I think it's a poor test because it seems to 
> > > rely on the ClassicSimilarity valuing shorter document (5 vs 6 tokens) 
> > > more than a higher tf for term w3 (2 vs 1), which is bad.  Really our 
> > > tests should not rely on specific scoring factors.
> > >
> > > Net/net this seems like a test bug, but I'm not sure how to fix it.
> > >
> > > Mike McCandless
> > >
> > > http://blog.mikemccandless.com
> > >
> > > On Fri, Jun 17, 2016 at 6:05 AM, Michael McCandless 
> > >  wrote:
> > > I'll dig.
> > >
> > > Mike McCandless
> > >
> > > http://blog.mikemccandless.com
> > >
> > > On Thu, Jun 16, 2016 at 10:55 PM, Steve Rowe  wrote:
> > > Thanks for looking Hoss.
> > >
> > > I compared files changed by the commits on branch_6x and on branch_5_5, 
> > > and I don’t see anything consequential, so I don’t think this is a case 
> > > of a misapplied backport.
> > >
> > > --
> > > Steve
> > > www.lucidworks.com
> > >
> > > > On Jun 16, 2016, at 6:25 PM, Chris Hostetter  
> > > > wrote:
> > > >
> > > >
> > > > : : I ran this test before I committed the backport, but it succeeded 
> > > > then.
> > > > : : I beasted it on current branch_5_5 and 49/100 seeds succeeded.
> > > > :
> > > > : one of the things that cahnged as part of LUCENE-7132 was that i made 
> > > > all
> > > > : the BQ related tests start randomizing setDisableCoord() ... so you 
> > > > might
> > > > : be seeing some previously unidentified coord related bug that is only 
> > > > in
> > > > : the 5.x line of code?
> > > > :
> > > > : that could probably jive with the roughtly 50% failure ratio you're
> > > > : seeing?
> > > >
> > > > Hmmm  nope.  Even with the setDisableCoord commented out 

Re: [JENKINS] Lucene-Solr-5.5-Linux (32bit/jdk1.7.0_80) - Build # 292 - Failure!

[Michael McCandless]

Ugh sorry I spaced out!  Can you cherry-pick?  Thanks.

Mike McCandless

http://blog.mikemccandless.com

On Fri, Jun 17, 2016 at 4:44 PM, Steve Rowe  wrote:

> Thanks Mike!
>
> I noticed you didn’t push to branch_5_5 - was that just an oversight, or
> am I being too impatient?  (I can cherry-pick it if you’d like me to.)
>
> --
> Steve
> www.lucidworks.com
>
> > On Jun 17, 2016, at 2:56 PM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
> >
> > Hi Steve,
> >
> > I dug some more, and I think this small change fixes the buggy test:
> >
> > diff --git
> a/lucene/core/src/test/org/apache/lucene/search/TestBoolean2.java
> b/lucene/core/src/test/org/apache/lucene/search/TestBoolean2.java
> > index d97d8d4..f4ead23 100644
> > --- a/lucene/core/src/test/org/apache/lucene/search/TestBoolean2.java
> > +++ b/lucene/core/src/test/org/apache/lucene/search/TestBoolean2.java
> > @@ -165,7 +165,7 @@ public class TestBoolean2 extends LuceneTestCase {
> >  "w1 w2 w3 w4 w5",
> >  "w1 w3 w2 w3",
> >  "w1 xx w2 yy w3",
> > -"w1 w3 xx w2 yy w3"
> > +"w1 w3 xx w2 yy mm"
> >};
> >
> >public void queriesTest(Query query, int[] expDocNrs) throws
> Exception {
> >
> >
> > Those strings are the documents that the test indexes, and the root
> cause of the failure is that w3 appears twice in the last document (tf=2),
> and the last document is longer.  The test assumed (illegally) that the
> last document would always get a worst score than the one before it, but
> that's up to the similarity and something changed here between 5.x and 6.x.
> >
> > I'll push this shortly to 5.x, 6.x, master...
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> > On Fri, Jun 17, 2016 at 11:08 AM, Steve Rowe  wrote:
> > Thanks for digging, Mike.
> >
> > These tests aren’t failing on 6.x (including the backport to branch_6_0:
> 0/100 TestBoolean2 beasting failures just nnw) - in your digging did you
> come across anything that would explain that?
> >
> > I’d rather not revert this bugfix backport just because it exposed
> other, possibly test-only?, bugs, but I understand that spending a bunch of
> time on an old patch release is non-optimal :).
> >
> > --
> > Steve
> > www.lucidworks.com
> >
> > > On Jun 17, 2016, at 9:45 AM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
> > >
> > > OK I dug a bit, specifically on this test failure:
> > >
> > > ant test  -Dtestcase=TestBoolean2 -Dtests.method=testQueries01
> -Dtests.seed=5787EE10A58E0A9C -Dtests.multiplier=3 -Dtests.slow=true
> -Dtests.locale=nn-NO -Dtests.timezone=America/St_Vincent
> -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> > >
> > > and something else is at play: this particular test case uses
> ConjunctionScorer, not BooleanScorer (where the original bug was).
> > >
> > > What happens for this failing seed is the correct 2 documents match,
> but the 2nd one unexpectedly gets a better score, possibly only when enough
> filler docs were added.  I think it's a poor test because it seems to rely
> on the ClassicSimilarity valuing shorter document (5 vs 6 tokens) more than
> a higher tf for term w3 (2 vs 1), which is bad.  Really our tests should
> not rely on specific scoring factors.
> > >
> > > Net/net this seems like a test bug, but I'm not sure how to fix it.
> > >
> > > Mike McCandless
> > >
> > > http://blog.mikemccandless.com
> > >
> > > On Fri, Jun 17, 2016 at 6:05 AM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
> > > I'll dig.
> > >
> > > Mike McCandless
> > >
> > > http://blog.mikemccandless.com
> > >
> > > On Thu, Jun 16, 2016 at 10:55 PM, Steve Rowe  wrote:
> > > Thanks for looking Hoss.
> > >
> > > I compared files changed by the commits on branch_6x and on
> branch_5_5, and I don’t see anything consequential, so I don’t think this
> is a case of a misapplied backport.
> > >
> > > --
> > > Steve
> > > www.lucidworks.com
> > >
> > > > On Jun 16, 2016, at 6:25 PM, Chris Hostetter <
> hossman_luc...@fucit.org> wrote:
> > > >
> > > >
> > > > : : I ran this test before I committed the backport, but it
> succeeded then.
> > > > : : I beasted it on current branch_5_5 and 49/100 seeds succeeded.
> > > > :
> > > > : one of the things that cahnged as part of LUCENE-7132 was that i
> made all
> > > > : the BQ related tests start randomizing setDisableCoord() ... so
> you might
> > > > : be seeing some previously unidentified coord related bug that is
> only in
> > > > : the 5.x line of code?
> > > > :
> > > > : that could probably jive with the roughtly 50% failure ratio you're
> > > > : seeing?
> > > >
> > > > Hmmm  nope.  Even with the setDisableCoord commented out (but
> still
> > > > consuming random().nextBoolean() consistently) the same seeds
> reliably
> > > > fail on branch_5_5
> > > >
> > > > Looks like the "~50%" comes from the "use filler docs or not?" bit
> of the
> > > > test?  with the patch below i can't find any seeds to fail -- which

[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling

[Shikha Somani (JIRA)]

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

Shikha Somani commented on SOLR-8297:
-

Sure, will rename *Any* to avoid confusion. And will start work on this 
suggested solution.

> Allow join query over 2 sharded collections: enhance functionality and 
> exception handling
> -
>
> Key: SOLR-8297
> URL: https://issues.apache.org/jira/browse/SOLR-8297
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Paul Blanchaert
>
> Enhancement based on SOLR-4905. New Jira issue raised as suggested by Mikhail 
> Khludnev.
> A) exception handling:
> The exception "SolrCloud join: multiple shards not yet supported" thrown in 
> the function findLocalReplicaForFromIndex of JoinQParserPlugin is not 
> triggered correctly: In my use-case, I've a join on a facet.query and when my 
> results are only found in 1 shard and the facet.query with the join is 
> querying the last replica of the last slice, then the exception is not thrown.
> I believe it's better to verify the nr of slices when we want to verify the  
> "multiple shards not yet supported" exception (so exception is thrown when 
> zkController.getClusterState().getSlices(fromIndex).size()>1).
> B) functional enhancement:
> I would expect that there is no problem to perform a cross-core join over 
> sharded collections when the following conditions are met:
> 1) both collections are sharded with the same replicationFactor and numShards
> 2) router.field of the collections is set to the same "key-field" (collection 
> of "fromindex" has router.field = "from" field and collection joined to has 
> router.field = "to" field)
> The router.field setup ensures that documents with the same "key-field" are 
> routed to the same node. 
> So the combination based on the "key-field" should always be available within 
> the same node.
> From a user perspective, I believe these assumptions seem to be a "normal" 
> use-case in the cross-core join in SolrCloud.
> Hope this helps



--
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-9053) Upgrade fileupload-commons to 1.3.1

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9053.
--
   Resolution: Fixed
Fix Version/s: 5.5.2
   5.6

> Upgrade fileupload-commons to 1.3.1
> ---
>
> Key: SOLR-9053
> URL: https://issues.apache.org/jira/browse/SOLR-9053
> Project: Solr
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 4.6, 5.5, 6.0
>Reporter: Jeff Field
>Assignee: Jan Høydahl
>  Labels: commons-file-upload
> Fix For: 5.6, 5.5.2, 6.1, 6.0.1
>
> Attachments: SOLR-9053.patch
>
>
> The project appears to pull in FileUpload 1.2.1. According to CVE-2014-0050:
> "MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in 
> Apache Tomcat, JBoss Web, and other products, allows remote attackers to 
> cause a denial of service (infinite loop and CPU consumption) via a crafted 
> Content-Type header that bypasses a loop's intended exit conditions."
> [Source|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0050]



--
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-9053) Upgrade fileupload-commons to 1.3.1

[ASF subversion and git services (JIRA)]

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

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

Commit fb5916c329745ea80cff600adab89269c8764f0e in lucene-solr's branch 
refs/heads/branch_5x from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fb5916c ]

SOLR-9053: Upgrade commons-fileupload to 1.3.1, fixing a potential vulnerability
(cherry picked from commit 0ebe6b0)


> Upgrade fileupload-commons to 1.3.1
> ---
>
> Key: SOLR-9053
> URL: https://issues.apache.org/jira/browse/SOLR-9053
> Project: Solr
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 4.6, 5.5, 6.0
>Reporter: Jeff Field
>Assignee: Jan Høydahl
>  Labels: commons-file-upload
> Fix For: 6.0.1, 6.1
>
> Attachments: SOLR-9053.patch
>
>
> The project appears to pull in FileUpload 1.2.1. According to CVE-2014-0050:
> "MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in 
> Apache Tomcat, JBoss Web, and other products, allows remote attackers to 
> cause a denial of service (infinite loop and CPU consumption) via a crafted 
> Content-Type header that bypasses a loop's intended exit conditions."
> [Source|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0050]



--
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-9053) Upgrade fileupload-commons to 1.3.1

[ASF subversion and git services (JIRA)]

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

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

Commit 931501ce6481080fbdb4c5470f7b532f394e7b96 in lucene-solr's branch 
refs/heads/branch_5_5 from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=931501c ]

SOLR-9053: Upgrade commons-fileupload to 1.3.1, fixing a potential vulnerability
(cherry picked from commit 0ebe6b0)


> Upgrade fileupload-commons to 1.3.1
> ---
>
> Key: SOLR-9053
> URL: https://issues.apache.org/jira/browse/SOLR-9053
> Project: Solr
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 4.6, 5.5, 6.0
>Reporter: Jeff Field
>Assignee: Jan Høydahl
>  Labels: commons-file-upload
> Fix For: 6.0.1, 6.1
>
> Attachments: SOLR-9053.patch
>
>
> The project appears to pull in FileUpload 1.2.1. According to CVE-2014-0050:
> "MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in 
> Apache Tomcat, JBoss Web, and other products, allows remote attackers to 
> cause a denial of service (infinite loop and CPU consumption) via a crafted 
> Content-Type header that bypasses a loop's intended exit conditions."
> [Source|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0050]



--
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-9053) Upgrade fileupload-commons to 1.3.1

[ASF subversion and git services (JIRA)]

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

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

Commit 9ebd60ceec6f7fa2242295467b0420ae807ecbb4 in lucene-solr's branch 
refs/heads/branch_5x from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9ebd60c ]

SOLR-9053: Fix attribution, apply the code refactor part from mdrob's patch
(cherry picked from commit b6f8c65)


> Upgrade fileupload-commons to 1.3.1
> ---
>
> Key: SOLR-9053
> URL: https://issues.apache.org/jira/browse/SOLR-9053
> Project: Solr
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 4.6, 5.5, 6.0
>Reporter: Jeff Field
>Assignee: Jan Høydahl
>  Labels: commons-file-upload
> Fix For: 6.0.1, 6.1
>
> Attachments: SOLR-9053.patch
>
>
> The project appears to pull in FileUpload 1.2.1. According to CVE-2014-0050:
> "MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in 
> Apache Tomcat, JBoss Web, and other products, allows remote attackers to 
> cause a denial of service (infinite loop and CPU consumption) via a crafted 
> Content-Type header that bypasses a loop's intended exit conditions."
> [Source|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0050]



--
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-9053) Upgrade fileupload-commons to 1.3.1

[ASF subversion and git services (JIRA)]

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

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

Commit dacb226a2be822abe7d46a6be7811c6eeb5f5e4c in lucene-solr's branch 
refs/heads/branch_5_5 from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=dacb226 ]

SOLR-9053: Fix attribution, apply the code refactor part from mdrob's patch
(cherry picked from commit b6f8c65)


> Upgrade fileupload-commons to 1.3.1
> ---
>
> Key: SOLR-9053
> URL: https://issues.apache.org/jira/browse/SOLR-9053
> Project: Solr
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 4.6, 5.5, 6.0
>Reporter: Jeff Field
>Assignee: Jan Høydahl
>  Labels: commons-file-upload
> Fix For: 6.0.1, 6.1
>
> Attachments: SOLR-9053.patch
>
>
> The project appears to pull in FileUpload 1.2.1. According to CVE-2014-0050:
> "MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in 
> Apache Tomcat, JBoss Web, and other products, allows remote attackers to 
> cause a denial of service (infinite loop and CPU consumption) via a crafted 
> Content-Type header that bypasses a loop's intended exit conditions."
> [Source|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0050]



--
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] [Reopened] (SOLR-9053) Upgrade fileupload-commons to 1.3.1

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-9053:
--

Reopening to backport to 5.6 and 5.5.2.

> Upgrade fileupload-commons to 1.3.1
> ---
>
> Key: SOLR-9053
> URL: https://issues.apache.org/jira/browse/SOLR-9053
> Project: Solr
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 4.6, 5.5, 6.0
>Reporter: Jeff Field
>Assignee: Jan Høydahl
>  Labels: commons-file-upload
> Fix For: 6.0.1, 6.1
>
> Attachments: SOLR-9053.patch
>
>
> The project appears to pull in FileUpload 1.2.1. According to CVE-2014-0050:
> "MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in 
> Apache Tomcat, JBoss Web, and other products, allows remote attackers to 
> cause a denial of service (infinite loop and CPU consumption) via a crafted 
> Content-Type header that bypasses a loop's intended exit conditions."
> [Source|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0050]



--
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-8981) Upgrade to Tika 1.13 when it is available

[Tim Allison (JIRA)]

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

Tim Allison commented on SOLR-8981:
---

Yes, please!

> Upgrade to Tika 1.13 when it is available
> -
>
> Key: SOLR-8981
> URL: https://issues.apache.org/jira/browse/SOLR-8981
> Project: Solr
>  Issue Type: Improvement
>Reporter: Tim Allison
>Assignee: Uwe Schindler
>Priority: Minor
>
> Tika 1.13 should be out within a month.  This includes PDFBox 2.0.0 and a 
> number of other upgrades and improvements.  
> If there are any showstoppers in 1.13 from Solr's side or requests before we 
> roll 1.13, let us know.



--
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-9131) Fix "start solr" text in cluster.vm Velocity template

[ASF subversion and git services (JIRA)]

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

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

Commit 41c77152b97425f6c6bd86b32ba635c045d37ed8 in lucene-solr's branch 
refs/heads/branch_5_5 from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=41c7715 ]

SOLR-9131: Fix "start solr" text in cluster.vm Velocity template
(cherry picked from commit 59e6e3b)


> Fix "start solr" text in cluster.vm Velocity template
> -
>
> Key: SOLR-9131
> URL: https://issues.apache.org/jira/browse/SOLR-9131
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - Velocity
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 5.6, 6.0.1, 5.5.2
>
> Attachments: SOLR-9131.patch
>
>
> In the sample techproducts config set, there is the following text under the 
> {{Clusters}} heading:
> {quote}
> Run Solr with java -Dsolr.clustering.enabled=true -jar start.jar to see 
> clustered search results.
> {quote}
> We no longer recommend starting Solr using {{java -jar start.jar}}, Change 
> the text into
> {noformat}
> Run Solr with option -Dsolr.clustering.enabled=true to see clustered search 
> results.
> {noformat}



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

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

[jira] [Commented] (SOLR-9131) Fix "start solr" text in cluster.vm Velocity template

[ASF subversion and git services (JIRA)]

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

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

Commit 04da75076bfb7afbb9b781e4b6f8e64060afadc7 in lucene-solr's branch 
refs/heads/branch_5x from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=04da750 ]

SOLR-9131: Fix "start solr" text in cluster.vm Velocity template
(cherry picked from commit 59e6e3b)


> Fix "start solr" text in cluster.vm Velocity template
> -
>
> Key: SOLR-9131
> URL: https://issues.apache.org/jira/browse/SOLR-9131
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - Velocity
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 5.6, 6.0.1, 5.5.2
>
> Attachments: SOLR-9131.patch
>
>
> In the sample techproducts config set, there is the following text under the 
> {{Clusters}} heading:
> {quote}
> Run Solr with java -Dsolr.clustering.enabled=true -jar start.jar to see 
> clustered search results.
> {quote}
> We no longer recommend starting Solr using {{java -jar start.jar}}, Change 
> the text into
> {noformat}
> Run Solr with option -Dsolr.clustering.enabled=true to see clustered search 
> results.
> {noformat}



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

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

[jira] [Resolved] (SOLR-9131) Fix "start solr" text in cluster.vm Velocity template

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9131.
--
   Resolution: Fixed
Fix Version/s: 5.5.2
   5.6

> Fix "start solr" text in cluster.vm Velocity template
> -
>
> Key: SOLR-9131
> URL: https://issues.apache.org/jira/browse/SOLR-9131
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - Velocity
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 5.6, 5.5.2, 6.0.1
>
> Attachments: SOLR-9131.patch
>
>
> In the sample techproducts config set, there is the following text under the 
> {{Clusters}} heading:
> {quote}
> Run Solr with java -Dsolr.clustering.enabled=true -jar start.jar to see 
> clustered search results.
> {quote}
> We no longer recommend starting Solr using {{java -jar start.jar}}, Change 
> the text into
> {noformat}
> Run Solr with option -Dsolr.clustering.enabled=true to see clustered search 
> results.
> {noformat}



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

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

[jira] [Reopened] (SOLR-9131) Fix "start solr" text in cluster.vm Velocity template

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-9131:
--

Reopening to backport to 5.6 and 5.5.2.

> Fix "start solr" text in cluster.vm Velocity template
> -
>
> Key: SOLR-9131
> URL: https://issues.apache.org/jira/browse/SOLR-9131
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - Velocity
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.0.1
>
> Attachments: SOLR-9131.patch
>
>
> In the sample techproducts config set, there is the following text under the 
> {{Clusters}} heading:
> {quote}
> Run Solr with java -Dsolr.clustering.enabled=true -jar start.jar to see 
> clustered search results.
> {quote}
> We no longer recommend starting Solr using {{java -jar start.jar}}, Change 
> the text into
> {noformat}
> Run Solr with option -Dsolr.clustering.enabled=true to see clustered search 
> results.
> {noformat}



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

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

[jira] [Commented] (SOLR-8967) UI should not show the replication tab in the core selector panel in cloud mode

[ASF subversion and git services (JIRA)]

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

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

Commit 889c15872d393c3218d868f49e8b605847982631 in lucene-solr's branch 
refs/heads/branch_5x from [~varunthacker]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=889c158 ]

SOLR-8967: UI should not show the replication tab in the core selector panel in 
cloud mode


> UI should not show the replication tab in the core selector panel in cloud 
> mode
> ---
>
> Key: SOLR-8967
> URL: https://issues.apache.org/jira/browse/SOLR-8967
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 5.6, 6.0.1, 6.1, 5.5.2, master (7.0)
>
> Attachments: SOLR-8967.patch
>
>
> When running Solr in cloud mode, the UI has a 'Replication' tab under 'Core 
> Selector' . 
> I think we should not display this when Solr is running in cloud mode. It 
> doesn't add any value as this is useful for master-slave setups. It could 
> also be harmful if someone accidentally clicks on 'Disable Replication' in 
> the UI. 



--
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-8967) UI should not show the replication tab in the core selector panel in cloud mode

[ASF subversion and git services (JIRA)]

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

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

Commit c8a460c7ca8b9908509fedcdcbcd40203d053f0f in lucene-solr's branch 
refs/heads/branch_5_5 from [~varunthacker]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c8a460c ]

SOLR-8967: UI should not show the replication tab in the core selector panel in 
cloud mode


> UI should not show the replication tab in the core selector panel in cloud 
> mode
> ---
>
> Key: SOLR-8967
> URL: https://issues.apache.org/jira/browse/SOLR-8967
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 5.6, 6.0.1, 6.1, 5.5.2, master (7.0)
>
> Attachments: SOLR-8967.patch
>
>
> When running Solr in cloud mode, the UI has a 'Replication' tab under 'Core 
> Selector' . 
> I think we should not display this when Solr is running in cloud mode. It 
> doesn't add any value as this is useful for master-slave setups. It could 
> also be harmful if someone accidentally clicks on 'Disable Replication' in 
> the UI. 



--
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-8967) UI should not show the replication tab in the core selector panel in cloud mode

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-8967.
--
   Resolution: Fixed
Fix Version/s: 5.5.2
   5.6

> UI should not show the replication tab in the core selector panel in cloud 
> mode
> ---
>
> Key: SOLR-8967
> URL: https://issues.apache.org/jira/browse/SOLR-8967
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 5.6, 5.5.2, master (7.0), 6.1, 6.0.1
>
> Attachments: SOLR-8967.patch
>
>
> When running Solr in cloud mode, the UI has a 'Replication' tab under 'Core 
> Selector' . 
> I think we should not display this when Solr is running in cloud mode. It 
> doesn't add any value as this is useful for master-slave setups. It could 
> also be harmful if someone accidentally clicks on 'Disable Replication' in 
> the UI. 



--
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] [Reopened] (SOLR-8967) UI should not show the replication tab in the core selector panel in cloud mode

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-8967:
--

Reopening to backport to 5.6 and 5.5.2.

> UI should not show the replication tab in the core selector panel in cloud 
> mode
> ---
>
> Key: SOLR-8967
> URL: https://issues.apache.org/jira/browse/SOLR-8967
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 6.0.1, 6.1, master (7.0)
>
> Attachments: SOLR-8967.patch
>
>
> When running Solr in cloud mode, the UI has a 'Replication' tab under 'Core 
> Selector' . 
> I think we should not display this when Solr is running in cloud mode. It 
> doesn't add any value as this is useful for master-slave setups. It could 
> also be harmful if someone accidentally clicks on 'Disable Replication' in 
> the UI. 



--
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-7516) Improve javadocs for JavaBinCodec, ObjectResolver and enforce the single-usage policy

[ASF subversion and git services (JIRA)]

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

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

Commit ca7c21a98d024af03c1f0309e850879b23b69e60 in lucene-solr's branch 
refs/heads/branch_5_5 from [~shalinmangar]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ca7c21a ]

* SOLR-7516: Improve javadocs for JavaBinCodec, ObjectResolver and enforce the 
single-usage policy

(cherry picked from commit d87d8da)


> Improve javadocs for JavaBinCodec, ObjectResolver and enforce the 
> single-usage policy
> -
>
> Key: SOLR-7516
> URL: https://issues.apache.org/jira/browse/SOLR-7516
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
>  Labels: difficulty-easy, newdev
> Fix For: 6.0.1, 6.1, master (7.0)
>
> Attachments: SOLR-7516.patch, SOLR-7516.patch, SOLR-7516.patch, 
> SOLR-7516.patch
>
>
> The Javadocs of this class can use some improvements. It doesn't adequately 
> describe the purpose of the ObjectResolver. Also, since it says that this 
> object should be used only once for marshalling or unmarshalling operation, 
> we should enforce it in code via asserts and/or exceptions.



--
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-7516) Improve javadocs for JavaBinCodec, ObjectResolver and enforce the single-usage policy

[ASF subversion and git services (JIRA)]

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

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

Commit 2d4d3f1a7fa1f1aaab6484d44839b4703ec4507f in lucene-solr's branch 
refs/heads/branch_5x from [~shalinmangar]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2d4d3f1 ]

* SOLR-7516: Improve javadocs for JavaBinCodec, ObjectResolver and enforce the 
single-usage policy

(cherry picked from commit d87d8da)


> Improve javadocs for JavaBinCodec, ObjectResolver and enforce the 
> single-usage policy
> -
>
> Key: SOLR-7516
> URL: https://issues.apache.org/jira/browse/SOLR-7516
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
>  Labels: difficulty-easy, newdev
> Fix For: 6.0.1, 6.1, master (7.0)
>
> Attachments: SOLR-7516.patch, SOLR-7516.patch, SOLR-7516.patch, 
> SOLR-7516.patch
>
>
> The Javadocs of this class can use some improvements. It doesn't adequately 
> describe the purpose of the ObjectResolver. Also, since it says that this 
> object should be used only once for marshalling or unmarshalling operation, 
> we should enforce it in code via asserts and/or exceptions.



--
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] [Reopened] (SOLR-7516) Improve javadocs for JavaBinCodec, ObjectResolver and enforce the single-usage policy

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-7516:
--

Reopening to backport to 5.6 and 5.5.2.

> Improve javadocs for JavaBinCodec, ObjectResolver and enforce the 
> single-usage policy
> -
>
> Key: SOLR-7516
> URL: https://issues.apache.org/jira/browse/SOLR-7516
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
>  Labels: difficulty-easy, newdev
> Fix For: 6.0.1, 6.1, master (7.0)
>
> Attachments: SOLR-7516.patch, SOLR-7516.patch, SOLR-7516.patch, 
> SOLR-7516.patch
>
>
> The Javadocs of this class can use some improvements. It doesn't adequately 
> describe the purpose of the ObjectResolver. Also, since it says that this 
> object should be used only once for marshalling or unmarshalling operation, 
> we should enforce it in code via asserts and/or exceptions.



--
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-9134) RestManager.addManagedResource returns null instead of newly created instance

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-9134 at 6/17/16 9:57 PM:
---

Reopening to backport to 5.5.2.


was (Author: steve_rowe):
Reopening to backport to 5.6 and 5.5.2.

> RestManager.addManagedResource returns null instead of newly created instance
> -
>
> Key: SOLR-9134
> URL: https://issues.apache.org/jira/browse/SOLR-9134
> Project: Solr
>  Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Trivial
> Fix For: 5.6, 6.0.1, 6.1, 5.5.2, master (7.0)
>
> Attachments: SOLR-9134.patch
>
>
> This seems unintended, or if it's intended shall we clarify the javadocs 
> w.r.t. when null/non-null is returned?



--
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-9134) RestManager.addManagedResource returns null instead of newly created instance

[ASF subversion and git services (JIRA)]

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

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

Commit bdd35e9de6ecfabf32368e7e4b78db02939a7543 in lucene-solr's branch 
refs/heads/branch_5_5 from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bdd35e9 ]

SOLR-9134: Fix RestManager.addManagedResource return value.


> RestManager.addManagedResource returns null instead of newly created instance
> -
>
> Key: SOLR-9134
> URL: https://issues.apache.org/jira/browse/SOLR-9134
> Project: Solr
>  Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Trivial
> Fix For: 5.6, 6.0.1, 6.1, 5.5.2, master (7.0)
>
> Attachments: SOLR-9134.patch
>
>
> This seems unintended, or if it's intended shall we clarify the javadocs 
> w.r.t. when null/non-null is returned?



--
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-9134) RestManager.addManagedResource returns null instead of newly created instance

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9134.
--
   Resolution: Fixed
Fix Version/s: 5.5.2

> RestManager.addManagedResource returns null instead of newly created instance
> -
>
> Key: SOLR-9134
> URL: https://issues.apache.org/jira/browse/SOLR-9134
> Project: Solr
>  Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Trivial
> Fix For: 5.6, 5.5.2, master (7.0), 6.1, 6.0.1
>
> Attachments: SOLR-9134.patch
>
>
> This seems unintended, or if it's intended shall we clarify the javadocs 
> w.r.t. when null/non-null is returned?



--
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] [Reopened] (SOLR-9134) RestManager.addManagedResource returns null instead of newly created instance

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-9134:
--

Reopening to backport to 5.6 and 5.5.2.

> RestManager.addManagedResource returns null instead of newly created instance
> -
>
> Key: SOLR-9134
> URL: https://issues.apache.org/jira/browse/SOLR-9134
> Project: Solr
>  Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Trivial
> Fix For: 5.6, 6.0.1, 6.1, master (7.0)
>
> Attachments: SOLR-9134.patch
>
>
> This seems unintended, or if it's intended shall we clarify the javadocs 
> w.r.t. when null/non-null is returned?



--
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-8801) /bin/solr create script always returns exit code 0

[ASF subversion and git services (JIRA)]

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

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

Commit 77e7fbbaa37223e91f2adae9829ef48c689286ea in lucene-solr's branch 
refs/heads/branch_5x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=77e7fbb ]

SOLR-8801: /bin/solr create script always returns exit code 0 when a 
collection/core already exists


> /bin/solr create script always returns exit code 0 
> ---
>
> Key: SOLR-8801
> URL: https://issues.apache.org/jira/browse/SOLR-8801
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools, SolrCloud
>Affects Versions: 5.4, 5.5
>Reporter: Khalid Alharbi
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 5.6, 6.0.1, 6.1, 5.5.2, master (7.0)
>
> Attachments: SOLR_8801.patch, SOLR_8801.patch
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> /bin/solr create collection script always returns exit code 0 when a 
> collection already exists (solrCloud mode).
> version 5.1 returns exit code 1 but I just noticed that versions 5.4.0 and 
> 5.5.0 returns 0
>  
> >$ solr create -c my-collection -p 8983
> Connecting to ZooKeeper at localhost:9983 ...
> Re-using existing configuration directory my-collection
> ERROR: 
> Collection 'my-collection' already exists!
> Checked collection existence using Collections API command:
> http://localhost:8983/solr/admin/collections?action=list
> >$ echo $?
> 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