[jira] [Updated] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6908:
---
Attachment: LUCENE-6908.patch

Updated patch includes the following:

* Pushes down approximation fixes to the Geo utility APIs
* Refactors relation logic from {{GeoUtils}} into separate {{GeoRelationUtils}} 
class
* Improves GeoDistance pole crossing by re-projecting to Earth Centered Earth 
Fixed (ECEF)
* Adds {{approx}} flag to bypass advanced relation logic (useful for 
{{GeoPointField}} since approximations are already handled at the grid level
* Removes {{AwaitsFix}} from {{TestGeoUtils.testGeoRelations}}

Next step is to test w/ BKD integration.

> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
> 
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch, LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of 
> GeoPoint*Query as its using the BKD split technique (instead of quad cell 
> division) to divide the space on each pass. For "large" distance queries this 
> can create a lot of irregular rectangles producing large radial distortion 
> error when using the cartesian approximation methods provided by 
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian 
> approximation methods on irregular rectangles without having to cut over to 
> an expensive oblate geometry approach.



--
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-6992) ShowFileRequestHandler is hiding dynamic schema file even in read-only mode

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-6992:
-

So, I guess we are not making this one into 5.4? We should at least fix the 
headers for the next time then.

> ShowFileRequestHandler is hiding dynamic schema file even in read-only mode
> ---
>
> Key: SOLR-6992
> URL: https://issues.apache.org/jira/browse/SOLR-6992
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0
>Reporter: Alexandre Rafalovitch
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 5.0
>
> Attachments: SOLR-6992.patch
>
>
> When using dynamic schema, the schema file is not shown in the admin UI 
> (Files tab) by default. It is hidden because (as per [the section 
> comment|https://github.com/apache/lucene-solr/blob/db33df44c037e04fea9ac3e391ef79c0d6ae04f4/solr/core/src/java/org/apache/solr/handler/admin/ShowFileRequestHandler.java#L279]):
> {quote}
>  // Make sure that if the schema is managed, we don't allow editing. 
> {quote}
> But we don't have editing interface for those files (SOLR-5287 was backed 
> out), so the reason is not valid and makes reviewing schema just that bit 
> harder.
> The fix is probably just editing out that section, unless there are tests 
> specifically for that.



--
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-7339) Upgrade Jetty from 9.2 to 9.3

[ASF subversion and git services (JIRA)]

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

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

Commit 1717512 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1717512 ]

SOLR-7339: Disabling testUpdateField until we can fix the underlying issue

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 6.0
>
> Attachments: SOLR-7339.patch, SOLR-7339.patch
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
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-7339) Upgrade Jetty from 9.2 to 9.3

[Gregg Donovan (JIRA)]

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

Gregg Donovan commented on SOLR-7339:
-

Thanks, [~shalinmangar]! 

Wireshark dumps of SolrExampleStreamingBinaryTest.testUpdateField show Jetty 
9.3 sends an RST after the expected "HTTP 409 Conflict" and Jetty 9.2 does not. 
I haven't figured out what's changed in 9.3 that leads to this, though.

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 6.0
>
> Attachments: SOLR-7339.patch, SOLR-7339.patch
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
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-8338) in OverseerTest replace strings such as "collection1" and "state"

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8338: in OverseerTest replace strings such as "collection1" and "state" 
with variable or enum equivalent

> in OverseerTest replace strings such as "collection1" and "state"
> -
>
> Key: SOLR-8338
> URL: https://issues.apache.org/jira/browse/SOLR-8338
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8338.patch
>
>
> replace with variable or enum equivalent.



--
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-8338) in OverseerTest replace strings such as "collection1" and "state"

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8338: in OverseerTest replace strings such as "collection1" and "state" 
with variable or enum equivalent (merge in revision 1717526 from trunk)

> in OverseerTest replace strings such as "collection1" and "state"
> -
>
> Key: SOLR-8338
> URL: https://issues.apache.org/jira/browse/SOLR-8338
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8338.patch
>
>
> replace with variable or enum equivalent.



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

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

[jira] [Updated] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3

[Gregg Donovan (JIRA)]

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

Gregg Donovan updated SOLR-7339:

Attachment: SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng

Attached are the Wireshark files for 9.2 (right before the 9.3 commits) and 
with the 9.3 commits. 

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 6.0
>
> Attachments: SOLR-7339.patch, SOLR-7339.patch, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



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

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

Re: LUCENE-5791 and LUCENE-6672 (BasicOperations#determinize() performance)

[Michael McCandless]

Hi Irfan,

LUCENE-6672 is not really an issue, because the maxDeterminizedStates
limit is still enforced, just at an earlier stage (determinize) that
that issue expected (after UTF8 conversion of the determinized
automaton).

Mike McCandless

http://blog.mikemccandless.com


On Tue, Dec 1, 2015 at 12:39 PM, Irfan Hamid
 wrote:
> Hi Michael,
>
> Is the functionality you're mentioning the same as the one pointed out by
> David Causse in LUCENE-6672? If so he is claiming that maxDeterminizedStates
> is not respected by UTF32ToUTF8 and can thus cause a problem. I'm looking at
> lucene trunk to try and figure it out. However, input from you would be much
> appreciated.
>
> TIA,
> Irfan.
>
> On Tue, Dec 1, 2015 at 3:19 AM, Dawid Weiss  wrote:
>>>
>>>
>>> I think it would be interesting to explore an NFA implementation for
>>> Lucene!
>>>
>>
>> It would be interesting and valuable to have an optimized non-DFA graph
>> engine in general. I'm thinking of something like re2.
>> https://github.com/google/re2
>>
>> Dawid
>>
>

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

[jira] [Commented] (SOLR-8338) in OverseerTest replace strings such as "collection1" and "state"

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8338:
---

[ https://svn.apache.org/r1717526 ] was the actual commit but I mistakenly put 
$\{message\} as a commit message for it.

> in OverseerTest replace strings such as "collection1" and "state"
> -
>
> Key: SOLR-8338
> URL: https://issues.apache.org/jira/browse/SOLR-8338
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8338.patch
>
>
> replace with variable or enum equivalent.



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

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

[jira] [Updated] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6908:
---
Description: The {{.testGeoRelations}} method doesn't exactly test the 
behavior of GeoPoint*Query as its using the BKD split technique (instead of 
quad cell division) to divide the space on each pass. For "large" distance 
queries this can create a lot of irregular rectangles producing large radial 
distortion error when using the cartesian approximation methods provided by 
{{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian 
approximation methods on irregular rectangles without having to cut over to an 
expensive oblate geometry approach.  (was: The {{.testGeoRelations}} method 
doesn't exactly test the behavior of GeoPoint*Query as its using the BKD split 
technique (instead of quad cell division) to divide the space on each pass. For 
"large" distance queries this can create a lot of irregular rectangles 
producing large radial distortion error when using the cartesian approximation 
methods provided by {{GeoUtils}}. This issue will better divide the space 
enabling use of the fast cartesian approximation methods instead of having to 
convert to an expensive oblate geometry approach.)

> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
> 
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of 
> GeoPoint*Query as its using the BKD split technique (instead of quad cell 
> division) to divide the space on each pass. For "large" distance queries this 
> can create a lot of irregular rectangles producing large radial distortion 
> error when using the cartesian approximation methods provided by 
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian 
> approximation methods on irregular rectangles without having to cut over to 
> an expensive oblate geometry approach.



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

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.lucene.replicator.http.HttpReplicatorTest.testServerErrors

Error Message:
127.0.0.1:51030 failed to respond

Stack Trace:
org.apache.http.NoHttpResponseException: 127.0.0.1:51030 failed to respond
at 
__randomizedtesting.SeedInfo.seed([968B70808A73F373:81E0DF3F1EF371E1]:0)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at 
org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at 
org.apache.lucene.replicator.http.HttpClientBase.executeGET(HttpClientBase.java:159)
at 
org.apache.lucene.replicator.http.HttpReplicator.checkForUpdate(HttpReplicator.java:51)
at 
org.apache.lucene.replicator.ReplicationClient.doUpdate(ReplicationClient.java:196)
at 
org.apache.lucene.replicator.ReplicationClient.updateNow(ReplicationClient.java:402)
at 
org.apache.lucene.replicator.http.HttpReplicatorTest.testServerErrors(HttpReplicatorTest.java:155)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Resolved] (SOLR-8175) Wordbreak spellchecker throws IOOBE with Occur.MUST term

[James Dyer (JIRA)]

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

James Dyer resolved SOLR-8175.
--
   Resolution: Fixed
Fix Version/s: 5.5

Thanks, Ryan.

> Wordbreak spellchecker throws IOOBE with Occur.MUST term
> 
>
> Key: SOLR-8175
> URL: https://issues.apache.org/jira/browse/SOLR-8175
> Project: Solr
>  Issue Type: Bug
>Reporter: Ryan Josal
>Assignee: James Dyer
> Fix For: 5.5
>
> Attachments: SOLR-8175.patch, solr8175.patch
>
>
> Using the WordBreakSolrSpellChecker, if a user queries for "+foo barbaz" and 
> "bar baz" is a suggestion for "barbaz", Solr will throw an 
> IndexOutOfBoundsException.  As a result, a server driven by user queries 
> might throw a certain percentage of HTTP 500 responses as users hit this.



--
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-6994) Implement Windows version of bin/post

[JIRA]

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

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

Suggest we move most of this to Java first, then create a thin {{.cmd}} wrapper 
for Windows.

Plan:
 # Create a {{PostCLI.java}} which handles proper cmdline parsing etc, and 
instantiates {{new SimplePostTool}}
 # Write a small {{bin/post.cmd}} wrapper around PostCLI
 # Simplify {{bin/post}} as well

> Implement Windows version of bin/post
> -
>
> Key: SOLR-6994
> URL: https://issues.apache.org/jira/browse/SOLR-6994
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.0
>Reporter: Erik Hatcher
>Priority: Minor
> Fix For: Trunk
>
>
> SOLR-6900 added a Unix bin/post tool.  A Windows equivalent would be nice to 
> have as well.



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b93) - Build # 15090 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15090/
Java: 64bit/jdk1.9.0-ea-b93 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 
-XX:-CompactStrings

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

Error Message:
commitWithin did not work on node: http://127.0.0.1:56589/zax/ff/collection1 
expected:<68> but was:<67>

Stack Trace:
java.lang.AssertionError: commitWithin did not work on node: 
http://127.0.0.1:56589/zax/ff/collection1 expected:<68> but was:<67>
at 
__randomizedtesting.SeedInfo.seed([46A6A22674D3261B:CEF29DFCDA2F4BE3]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:333)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 

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

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.hadoop.MorphlineBasicMiniMRTest.mrRun

Error Message:
Failed on local exception: java.io.IOException: Broken pipe; Host Details : 
local host is: "lucene1-us-west/10.41.0.5"; destination host is: 
"lucene1-us-west.apache.org":54009; 

Stack Trace:
java.io.IOException: Failed on local exception: java.io.IOException: Broken 
pipe; Host Details : local host is: "lucene1-us-west/10.41.0.5"; destination 
host is: "lucene1-us-west.apache.org":54009; 
at 
__randomizedtesting.SeedInfo.seed([95E0BA3EA72990BC:9BB20E30A6BFA2B3]:0)
at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:772)
at org.apache.hadoop.ipc.Client.call(Client.java:1472)
at org.apache.hadoop.ipc.Client.call(Client.java:1399)
at 
org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
at com.sun.proxy.$Proxy109.getClusterMetrics(Unknown Source)
at 
org.apache.hadoop.yarn.api.impl.pb.client.ApplicationClientProtocolPBClientImpl.getClusterMetrics(ApplicationClientProtocolPBClientImpl.java:202)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
at 
org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
at com.sun.proxy.$Proxy110.getClusterMetrics(Unknown Source)
at 
org.apache.hadoop.yarn.client.api.impl.YarnClientImpl.getYarnClusterMetrics(YarnClientImpl.java:461)
at 
org.apache.hadoop.mapred.ResourceMgrDelegate.getClusterMetrics(ResourceMgrDelegate.java:151)
at 
org.apache.hadoop.mapred.YARNRunner.getClusterMetrics(YARNRunner.java:179)
at 
org.apache.hadoop.mapreduce.Cluster.getClusterStatus(Cluster.java:246)
at org.apache.hadoop.mapred.JobClient$3.run(JobClient.java:719)
at org.apache.hadoop.mapred.JobClient$3.run(JobClient.java:717)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at 
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628)
at 
org.apache.hadoop.mapred.JobClient.getClusterStatus(JobClient.java:717)
at 
org.apache.solr.hadoop.MapReduceIndexerTool.run(MapReduceIndexerTool.java:644)
at 
org.apache.solr.hadoop.MapReduceIndexerTool.run(MapReduceIndexerTool.java:607)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
at 
org.apache.solr.hadoop.MorphlineBasicMiniMRTest.mrRun(MorphlineBasicMiniMRTest.java:363)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
  

[jira] [Updated] (SOLR-8353) Support regex for skipping license checksums

[Gregory Chanan (JIRA)]

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

Gregory Chanan updated SOLR-8353:
-
Attachment: SOLR-8353.patch

Here's a patch that implements regex skiping while leaving skipChecksum and 
skipSnapshotsChecksum intact.  I tested by changing the hadoop version and 
httpcore version (and passing -DskipChecksumRegex='hadoop.*') and verified that 
only httpcore complained.

> Support regex for skipping license checksums
> 
>
> Key: SOLR-8353
> URL: https://issues.apache.org/jira/browse/SOLR-8353
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Gregory Chanan
> Attachments: SOLR-8353.patch
>
>
> It would be useful to be able to specify a regex for license checksums to 
> skip in the build.  Currently there are only two supported values:
> 1) skipChecksum (i.e. regex=*)
> 2) skipSnapshotsChecksum (i.e. regex=*-SNAPSHOT-*)
> A regex would be more flexible and allow testing the entire build while 
> skipping a more limited set of checksums, e.g.:
> a) an individual library (i.e. regex=joda-time*)
> b) a suite of libraries (i.e. regex=hadoop*)
> We could make skipChecksum and skipSnapshotsChecksum continue to work for 
> backwards compatbility reasons.



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

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexWriterExceptions.testMergeExceptionIsTragic

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


FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestIndexWriterExceptions

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

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




Build Log:
[...truncated 1819 lines...]
   [junit4] Suite: org.apache.lucene.index.TestIndexWriterExceptions
   [junit4]   2> Noll 02, 2015 2:31:19 A.M. 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
   [junit4]   2> WARNING: Suite execution timed out: 
org.apache.lucene.index.TestIndexWriterExceptions
   [junit4]   2>1) Thread[id=1489, 
name=TEST-TestIndexWriterExceptions.testMergeExceptionIsTragic-seed#[8DA8EC6B89D77C2E],
 state=RUNNABLE, group=TGRP-TestIndexWriterExceptions]
   [junit4]   2> at java.util.HashMap.hash(HashMap.java:338)
   [junit4]   2> at java.util.HashMap.put(HashMap.java:611)
   [junit4]   2> at java.util.HashSet.add(HashSet.java:219)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter$ReaderPool.noDups(IndexWriter.java:679)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:668)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.numDeletedDocs(IndexWriter.java:694)
   [junit4]   2> at 
org.apache.lucene.index.MergePolicy.size(MergePolicy.java:451)
   [junit4]   2> at 
org.apache.lucene.index.TieredMergePolicy$SegmentByteSizeDescending.compare(TieredMergePolicy.java:249)
   [junit4]   2> at 
org.apache.lucene.index.TieredMergePolicy$SegmentByteSizeDescending.compare(TieredMergePolicy.java:238)
   [junit4]   2> at java.util.TimSort.mergeHi(TimSort.java:837)
   [junit4]   2> at java.util.TimSort.mergeAt(TimSort.java:516)
   [junit4]   2> at 
java.util.TimSort.mergeForceCollapse(TimSort.java:457)
   [junit4]   2> at java.util.TimSort.sort(TimSort.java:254)
   [junit4]   2> at java.util.Arrays.sort(Arrays.java:1512)
   [junit4]   2> at java.util.ArrayList.sort(ArrayList.java:1454)
   [junit4]   2> at java.util.Collections.sort(Collections.java:175)
   [junit4]   2> at 
org.apache.lucene.index.TieredMergePolicy.findMerges(TieredMergePolicy.java:292)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.updatePendingMerges(IndexWriter.java:1952)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1916)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:454)
   [junit4]   2> at 
org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:86)
   [junit4]   2> at 
org.apache.lucene.index.TestIndexWriterExceptions.testMergeExceptionIsTragic(TestIndexWriterExceptions.java:2340)
   [junit4]   2> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
   [junit4]   2> at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   [junit4]   2> at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]   2> at java.lang.reflect.Method.invoke(Method.java:497)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
   [junit4]   2> at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4]   2> at 

[jira] [Commented] (SOLR-8333) fix public methods that take/return private/package-private arguments/results

[ASF subversion and git services (JIRA)]

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

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

Commit 1717554 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1717554 ]

SOLR-8333: Several API tweaks so that public APIs were no longer refering to 
private classes

> fix public methods that take/return private/package-private arguments/results
> -
>
> Key: SOLR-8333
> URL: https://issues.apache.org/jira/browse/SOLR-8333
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8333-ConcurrentLFUCache-protected.patch, 
> SOLR-8333.patch
>
>
> background info: 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201511.mbox/%3Calpine.DEB.2.11.1511231128450.24330@tray%3E
> A commit that added a package to solrj which already existed in solr-core 
> caused the javadoc link checker to uncover at least 4 instances of private or 
> package-private classes being neccessary to use public APIs.
> we should fix these instances and any other instances of APIs with similar 
> problems that we can find.



--
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-8333) fix public methods that take/return private/package-private arguments/results

[ASF subversion and git services (JIRA)]

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

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

Commit 1717556 from hoss...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1717556 ]

SOLR-8333: Several API tweaks so that public APIs were no longer refering to 
private classes (merge r1717554)

> fix public methods that take/return private/package-private arguments/results
> -
>
> Key: SOLR-8333
> URL: https://issues.apache.org/jira/browse/SOLR-8333
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8333-ConcurrentLFUCache-protected.patch, 
> SOLR-8333.patch
>
>
> background info: 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201511.mbox/%3Calpine.DEB.2.11.1511231128450.24330@tray%3E
> A commit that added a package to solrj which already existed in solr-core 
> caused the javadoc link checker to uncover at least 4 instances of private or 
> package-private classes being neccessary to use public APIs.
> we should fix these instances and any other instances of APIs with similar 
> problems that we can find.



--
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-8333) fix public methods that take/return private/package-private arguments/results

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-8333.

   Resolution: Fixed
 Assignee: Hoss Man
Fix Version/s: 5.5
   Trunk

fixed as described.

NOTE: I didn't see a compelling reason to risk backporting to the 5_4 branch 
giving the impending RC.

> fix public methods that take/return private/package-private arguments/results
> -
>
> Key: SOLR-8333
> URL: https://issues.apache.org/jira/browse/SOLR-8333
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: Trunk, 5.5
>
> Attachments: SOLR-8333-ConcurrentLFUCache-protected.patch, 
> SOLR-8333.patch
>
>
> background info: 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201511.mbox/%3Calpine.DEB.2.11.1511231128450.24330@tray%3E
> A commit that added a package to solrj which already existed in solr-core 
> caused the javadoc link checker to uncover at least 4 instances of private or 
> package-private classes being neccessary to use public APIs.
> we should fix these instances and any other instances of APIs with similar 
> problems that we can find.



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

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

[jira] [Updated] (SOLR-8308) XSS vulnerability

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-8308:
---
Attachment: SOLR-8308.patch

Here's an updated patch that is more lenient: {code}^[\._A-Za-z0-9]*${code}

> XSS vulnerability
> -
>
> Key: SOLR-8308
> URL: https://issues.apache.org/jira/browse/SOLR-8308
> Project: Solr
>  Issue Type: Bug
>Reporter: Adam Johnson
> Attachments: SOLR-8308.patch, SOLR-8308.patch
>
>
> You can rename a core using the following modified URL 
> https://SOLR:PORT/solr/admin/cores?wt=json=false=RENAME=test_app_shared2_replica2=%3Csvg+onload%3Dalert(1)%3E&_=1445468005152.
>  The core becomes inaccessible / unusable.  There should be more form 
> validation to the core name assignment



--
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-8059) NPE distributed DebugComponent

[Mani (JIRA)]

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

Mani commented on SOLR-8059:


In addition to the above this can be narrowed down to without looking at the 
source code *fl=id,score* & *debug=results* NPE is thrown. 

*Steps to reproduce*
./bin/solr start -e cloud #2 shards, 1 replica
./bin/solr status
./bin/post -c techproducts example/exampledocs/*.xml
{noformat}
curl 
"http://localhost:8983/solr/techproducts/select?q=*%3A*=json=true=true=id,score;
 => NPE thrown
curl 
"http://localhost:8983/solr/techproducts/select?q=*%3A*=ruby=true=results=id,score;
 => NPE thrown
{noformat}

Following curl examples works fine
curl 
"http://localhost:8983/solr/techproducts/select?q=*%3A*=ruby=true=query=id,score;
curl 
"http://localhost:8983/solr/techproducts/select?q=*%3A*=ruby=true=timing=id,score;
curl 
"http://localhost:8983/solr/techproducts/select?q=*%3A*=ruby=true=track=id,score;

> NPE distributed DebugComponent
> --
>
> Key: SOLR-8059
> URL: https://issues.apache.org/jira/browse/SOLR-8059
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.4
>
>
> The following URL select?debug=true=*:*=id,score yields
> {code}
> java.lang.NullPointerException
>   at 
> org.apache.solr.handler.component.DebugComponent.finishStage(DebugComponent.java:229)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:416)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:210)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:499)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> I can reproduce it everytime. Strange enough fl=*,score, or any other content 
> field does not! I have seen this happening in Highlighter as well on the same 
> code path. It makes little sense, how would fl influence that piece of code, 
> the id is requested in fl afterall.



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

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

[jira] [Updated] (SOLR-8308) XSS vulnerability

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-8308:
---
Attachment: SOLR-8308.patch

strawman patch.  running tests now, and see some failures so it's already too 
strict: "Invalid core name: .system_shard1_replica1".  what's the right pattern 
to allow for core names?

> XSS vulnerability
> -
>
> Key: SOLR-8308
> URL: https://issues.apache.org/jira/browse/SOLR-8308
> Project: Solr
>  Issue Type: Bug
>Reporter: Adam Johnson
> Attachments: SOLR-8308.patch
>
>
> You can rename a core using the following modified URL 
> https://SOLR:PORT/solr/admin/cores?wt=json=false=RENAME=test_app_shared2_replica2=%3Csvg+onload%3Dalert(1)%3E&_=1445468005152.
>  The core becomes inaccessible / unusable.  There should be more form 
> validation to the core name assignment



--
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-8308) XSS vulnerability

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-8308:


with the latest patch, all tests pass and the described steps above to rename 
the core results in a core rename exception.

> XSS vulnerability
> -
>
> Key: SOLR-8308
> URL: https://issues.apache.org/jira/browse/SOLR-8308
> Project: Solr
>  Issue Type: Bug
>Reporter: Adam Johnson
> Attachments: SOLR-8308.patch, SOLR-8308.patch
>
>
> You can rename a core using the following modified URL 
> https://SOLR:PORT/solr/admin/cores?wt=json=false=RENAME=test_app_shared2_replica2=%3Csvg+onload%3Dalert(1)%3E&_=1445468005152.
>  The core becomes inaccessible / unusable.  There should be more form 
> validation to the core name assignment



--
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-6392) If run Solr having two collections configured but only one config delivered to Zookeeper causes that config is applied for all collections

[Frank Kelly (JIRA)]

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

Frank Kelly commented on SOLR-6392:
---

Was there ever a resolution to this - either a code issue or a user error. I 
think I am seeing this also (working through the user list right now)

> If run Solr having two collections configured but only one config delivered 
> to Zookeeper causes that config is applied for all collections
> --
>
> Key: SOLR-6392
> URL: https://issues.apache.org/jira/browse/SOLR-6392
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Ilya Meleshkov
>
> I have simplest Solr cloud configured locally. Thus I have single Solr and 
> Zookeeper nodes. 
> Steps to reproduce an error:
> # have stopped Solr+ZK with two collections
> # run ZK
> # deliver config to one collection only
> # run Solr - Solr running without any complains or errors
> # deliver config to second collection - doesn't have an effect
> But if I deliver configs for both collections before start Solr - it work 
> perfectly.
> So I would say that Solr should fail with meaningful error if there is no 
> config for some collection.



--
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-8344) Decide default when requested fields are both column and row stored.

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8344:


Followup of 
https://issues.apache.org/jira/browse/SOLR-8220?focusedCommentId=15034013=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15034013

bq. Not quite sure what to do if the user defines both however, perhaps use the 
stored value?
That's what this issue is about.

bq. Why are we trying to anticipate "the right thing to do"?
They are both "right" (semantically equivalent), so we're trying to figure out 
the best performing option.  That will change based on the request, and always 
(statically) choosing one over the other is never going to be optimal.

Example: If a field is column-stored (docValued), one could chose to add it as 
stored so that it would be quicker to retrieve along with other non-docvalue 
fields (if you need to go to stored fields anyway, just get all the field 
values you can from there).  But when accessing that field alone, we'd still 
certainly want to use the column... it will be much faster.


> Decide default when requested fields are both column and row stored.
> 
>
> Key: SOLR-8344
> URL: https://issues.apache.org/jira/browse/SOLR-8344
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>
> This issue was discussed in the comments at SOLR-8220. Splitting it out to a 
> separate issue so that we can have a focused discussion on whether/how to do 
> this.
> If a given set of requested fields are all stored and have docValues (column 
> stored), we can retrieve the values from either place.  What should the 
> default be?



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

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

[jira] [Created] (LUCENE-6915) Change lucene xsd namespace to geode.apache.org

[Dan Smith (JIRA)]

Dan Smith created LUCENE-6915:
-

 Summary: Change lucene xsd namespace to geode.apache.org
 Key: LUCENE-6915
 URL: https://issues.apache.org/jira/browse/LUCENE-6915
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Dan Smith


The current namespace for lucene is geode.incubator.apache.org. Based on 
discussion on GEODE-386, this should be changed to geode.apache.org



--
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-8220) Read field from docValues for non stored fields

[Erick Erickson (JIRA)]

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

Erick Erickson edited comment on SOLR-8220 at 12/1/15 5:04 PM:
---

Deleting, see discussion at SOLR-8344


was (Author: erickerickson):
Random thought that occurred to me before coffee, so be warned.

The initial statement here is 'Many times a value will be both stored="true" 
and docValues="true" ', then there was a lot of discussion about efficiencies 
etc... 

Why are we trying to anticipate "the right thing to do"? It would be simpler to 
code something like:
> If the field is stored=true, return the stored value (don't even need to look 
> whether DV is true or not).
> If the field is stored=false and docValues=true, return the DV value.

Now it's totally under the control of the user which path is chosen through the 
schema definition; we don't have to try to guess anything. No new syntax. Maybe 
with a new "best practice" or something. There would be a learning curve for 
users around using only docValues=true for efficiency and _not_ setting 
stored=true. Not quite sure what to do if the user defines both however, 
perhaps use the stored value?

The thing one does lose is the ability to get 2 and 1. from the 
_same_ field, so there would be the added burden on the user of having to have 
two fields, one stored-only one dv-only if that distinction was important.

And in the "wild and crazy" department (and for a different ticket _entirely_) 
we could consider disallowing fields with both docValues=true and stored=true. 
Not advocating this last, just throwing out for discussion.

Let me emphasize that I don't have any investment in doing things this way, and 
apologies for thinking of this so late in the game.

> Read field from docValues for non stored fields
> ---
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, 
> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>-- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



--
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-8099) Remove sleep() function / ValueSourceParser

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8099:


Both these were added by [~ysee...@gmail.com] in SOLR-3685 
(https://svn.apache.org/viewvc?view=revision=1370297). Is it supposed 
to be useful for tests which are under consideration? Or is it dead code which 
is safe to remove?

> Remove sleep() function / ValueSourceParser
> ---
>
> Key: SOLR-8099
> URL: https://issues.apache.org/jira/browse/SOLR-8099
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>  Labels: security
> Fix For: 5.4
>
> Attachments: SOLR-8099.patch
>
>
> As per Doug Turnbull, the sleep() represents a security risk.
> {noformat}
> I noticed a while back that "sleep" is a function query. Which I
> believe means I can make the current query thread sleep for as long as I
> like.
> I'm guessing an attacker could use this to starve Solr of threads, running
> a denial of service attack by running multiple queries with sleeps in them.
> Is this a concern? I realize there may be test purposes to sleep a function
> query, but I'm trying to think if there's really practical purpose to
> having sleep here.
> Best,
> -Doug
> {noformat}
> This issue is to remove it, since it is neither documented publicly, nor used 
> internally very much, apart from one test suite.



--
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-8344) Decide default when requested fields are both column and row stored.

[Yonik Seeley (JIRA)]

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

Yonik Seeley edited comment on SOLR-8344 at 12/1/15 5:08 PM:
-

bq. Not quite sure what to do if the user defines both however, perhaps use the 
stored value?
That's what this issue is about.

bq. Why are we trying to anticipate "the right thing to do"?
They are both "right" (semantically equivalent), so we're trying to figure out 
the best performing option.  That will change based on the request, and always 
(statically) choosing one over the other is never going to be optimal.

Example: If a field is column-stored (docValued), one could chose to add it as 
stored so that it would be quicker to retrieve along with other non-docvalue 
fields (if you need to go to stored fields anyway, just get all the field 
values you can from there).  But when accessing that field alone, we'd still 
certainly want to use the column... it will be much faster.



was (Author: ysee...@gmail.com):
Followup of 
https://issues.apache.org/jira/browse/SOLR-8220?focusedCommentId=15034013=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15034013

bq. Not quite sure what to do if the user defines both however, perhaps use the 
stored value?
That's what this issue is about.

bq. Why are we trying to anticipate "the right thing to do"?
They are both "right" (semantically equivalent), so we're trying to figure out 
the best performing option.  That will change based on the request, and always 
(statically) choosing one over the other is never going to be optimal.

Example: If a field is column-stored (docValued), one could chose to add it as 
stored so that it would be quicker to retrieve along with other non-docvalue 
fields (if you need to go to stored fields anyway, just get all the field 
values you can from there).  But when accessing that field alone, we'd still 
certainly want to use the column... it will be much faster.


> Decide default when requested fields are both column and row stored.
> 
>
> Key: SOLR-8344
> URL: https://issues.apache.org/jira/browse/SOLR-8344
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>
> This issue was discussed in the comments at SOLR-8220. Splitting it out to a 
> separate issue so that we can have a focused discussion on whether/how to do 
> this.
> If a given set of requested fields are all stored and have docValues (column 
> stored), we can retrieve the values from either place.  What should the 
> default be?



--
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-8099) Remove sleep() function / ValueSourceParser

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8099:


They are useful for manual testing.  I've often used sleep for testing timeout 
situations.
I used the threadid s long time ago to verify that thread pools were behaving 
as expected so we wouldn't use more thread locals than expected (this dates 
back to when Lucene used more thread-locals).

Whether sleep should be considered a security issue?  shrug.
What if it was modified to respect any timeAllowed parameter?  w/o a 
timeAllowed, there are dozens of ways I could construct requests that would 
take a *long* time and suck up a lot more resources than sleep does.

> Remove sleep() function / ValueSourceParser
> ---
>
> Key: SOLR-8099
> URL: https://issues.apache.org/jira/browse/SOLR-8099
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>  Labels: security
> Fix For: 5.4
>
> Attachments: SOLR-8099.patch, SOLR-8099.patch
>
>
> As per Doug Turnbull, the sleep() represents a security risk.
> {noformat}
> I noticed a while back that "sleep" is a function query. Which I
> believe means I can make the current query thread sleep for as long as I
> like.
> I'm guessing an attacker could use this to starve Solr of threads, running
> a denial of service attack by running multiple queries with sleeps in them.
> Is this a concern? I realize there may be test purposes to sleep a function
> query, but I'm trying to think if there's really practical purpose to
> having sleep here.
> Best,
> -Doug
> {noformat}
> This issue is to remove it, since it is neither documented publicly, nor used 
> internally very much, apart from one test suite.



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

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

[jira] [Closed] (LUCENE-6915) Change lucene xsd namespace to geode.apache.org

[Dan Smith (JIRA)]

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

Dan Smith closed LUCENE-6915.
-
Resolution: Not A Problem

Sorry, created this bug against the wrong project.

> Change lucene xsd namespace to geode.apache.org
> ---
>
> Key: LUCENE-6915
> URL: https://issues.apache.org/jira/browse/LUCENE-6915
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dan Smith
>
> The current namespace for lucene is geode.incubator.apache.org. Based on 
> discussion on GEODE-386, this should be changed to geode.apache.org



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

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

Re: LUCENE-5791 and LUCENE-6672 (BasicOperations#determinize() performance)

[Irfan Hamid]

Hi Michael,

Is the functionality you're mentioning the same as the one pointed out by
David Causse in LUCENE-6672
? If so he is claiming
that maxDeterminizedStates is not respected by UTF32ToUTF8 and can thus
cause a problem. I'm looking at lucene trunk to try and figure it out.
However, input from you would be much appreciated.

TIA,
Irfan.

On Tue, Dec 1, 2015 at 3:19 AM, Dawid Weiss  wrote:

>
>> I think it would be interesting to explore an NFA implementation for
>> Lucene!
>>
>>
> It would be interesting and valuable to have an optimized non-DFA graph
> engine in general. I'm thinking of something like re2.
> https://github.com/google/re2
>
> Dawid
>
>

[jira] [Commented] (SOLR-8344) Decide default when requested fields are both column and row stored.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8344:
--

Moving my comment from SOLR-8220 here, didn't see this ticket before pasting my 
comment there:

My initial take would be something like add a new possibility to stored, 
something like stored="true|false|docvalues".

No guessing involved then. stored="docvalues" would NOT put anything in the fdt 
file for this field. We should probably error out if stored="docvalues" and 
docValues="false".

If it was important to get 2, not 1. then there would need to be a 
stored=true variant of the field.

**Another take...
Should we consider disallowing setting both? I.e. stored="true" 
docValues="true" throws an error...

Now it's totally under the control of the user which path is chosen through the 
schema definition; we don't have to try to guess anything. No new syntax 
either. Maybe with a new "best practice" or something. There would be a 
learning curve for users around using only docValues=true for efficiency and 
not setting stored=true.

That said, I suspect that the break in back-compat is too expensive and I think 
stored=docvalues is better anyway


> Decide default when requested fields are both column and row stored.
> 
>
> Key: SOLR-8344
> URL: https://issues.apache.org/jira/browse/SOLR-8344
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>
> This issue was discussed in the comments at SOLR-8220. Splitting it out to a 
> separate issue so that we can have a focused discussion on whether/how to do 
> this.
> If a given set of requested fields are all stored and have docValues (column 
> stored), we can retrieve the values from either place.  What should the 
> default be?



--
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-8344) Decide default when requested fields are both column and row stored.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8344:
--

Yeah, removed that all from 8220, thought about it more and saw this ticket...

We do want to keep in mind though that from a _user_ perspective, inputting 
'2.178734872984723984729387" as a float and getting  back "2.17873477935791" 
are not equivalent. So whatever we do needs to take that into account. If we 
use the stored=docvalues approach, then they'd need a copyField with 
stored=true field if it was important to them.

The other thing I like about the stored=docvalues approach, existing 
schemas/applications continue to work exactly as they do now. Upgrading is not 
surprising. Users can selectively take advantage of this new capability.

I think it'd even work if a user changed an existing schema from stored=true to 
stored=docvalues and did not re-index. True, they'd be carrying around some 
useless data in the *.fdt files until it was merged away for updated docs, but 
as long as docValues=true was set in the original schema, it'd "do the expected 
thing".

I suppose the same functionality could come from a new parameter on a  
definition like fl_from_dv=true but aside from the awkward name, I think this 
is harder to wrap your head around.

If you were willing to pay the "wasted disk space" penalty though, a separate 
parameter on the  to control where the "stored" value came from would 
allow one to switch back and forth without re-indexing. But to be clear, I 
don't think this is a good idea; using the  stored=docvalues option forces a 
decision to be made up-front.

> Decide default when requested fields are both column and row stored.
> 
>
> Key: SOLR-8344
> URL: https://issues.apache.org/jira/browse/SOLR-8344
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>
> This issue was discussed in the comments at SOLR-8220. Splitting it out to a 
> separate issue so that we can have a focused discussion on whether/how to do 
> this.
> If a given set of requested fields are all stored and have docValues (column 
> stored), we can retrieve the values from either place.  What should the 
> default be?



--
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-8318) SimpleQueryParser doesn't use MultiTermAnalysis for Fuzzy Queries

[Tom Hill (JIRA)]

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

Tom Hill commented on SOLR-8318:


To answer my Nov 19th comment:

I don't think I need to do anything with setRewriteMethod for fuzzy queries. 
QueryParserBase has a newPrefixQuery() and a newFuzzyQuery(), and it does call 
setRewriteMethod in newPrefixQuery, but not in newFuzzyQuery.



> SimpleQueryParser doesn't use MultiTermAnalysis for Fuzzy Queries
> -
>
> Key: SOLR-8318
> URL: https://issues.apache.org/jira/browse/SOLR-8318
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 5.3
>Reporter: Tom Hill
>Assignee: Erick Erickson
>Priority: Trivial
> Attachments: sqp_fuzzy_multiterm.patch
>
>
> Fuzzy queries in SimpleQParserPlugin don't seem to use the multi-term 
> analysis chain. Prefix queries do, and SolrQueryParser does use multi-term 
> analysis for fuzzy queries, so it seems like SimpleQParserPlugin should as 
> well.



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

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

[jira] [Updated] (SOLR-8220) Read field from docValues for non stored fields

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-8220:
---
Attachment: SOLR-8220.patch

bq. have some updated tests in separate patch which I haven't uploaded, I need 
to clean it up a bit and can submit it tonight.
I've fixed the issue in this updated patch, thanks to Yonik's suggestion. 
Keith, looking forward to the tests.

> Read field from docValues for non stored fields
> ---
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, 
> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>-- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



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

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

[jira] [Updated] (SOLR-8099) Remove sleep() function / ValueSourceParser

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-8099:
---
Attachment: SOLR-8099.patch

Updating the patch to keep those two functions around, but removing them from 
the list of implicitly added functions. If someone wants, he could still use 
it, and if not we can eventually remove it.

> Remove sleep() function / ValueSourceParser
> ---
>
> Key: SOLR-8099
> URL: https://issues.apache.org/jira/browse/SOLR-8099
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>  Labels: security
> Fix For: 5.4
>
> Attachments: SOLR-8099.patch, SOLR-8099.patch
>
>
> As per Doug Turnbull, the sleep() represents a security risk.
> {noformat}
> I noticed a while back that "sleep" is a function query. Which I
> believe means I can make the current query thread sleep for as long as I
> like.
> I'm guessing an attacker could use this to starve Solr of threads, running
> a denial of service attack by running multiple queries with sleeps in them.
> Is this a concern? I realize there may be test purposes to sleep a function
> query, but I'm trying to think if there's really practical purpose to
> having sleep here.
> Best,
> -Doug
> {noformat}
> This issue is to remove it, since it is neither documented publicly, nor used 
> internally very much, apart from one test suite.



--
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-8318) SimpleQueryParser doesn't use MultiTermAnalysis for Fuzzy Queries

[Tom Hill (JIRA)]

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

Tom Hill commented on SOLR-8318:


Right. The SimpleQueryParser has implementations of newFuzzyQuery and 
newPrefixQuery that just loop through the weights, and build a Boolean query.

The existing implementation for SimpleQParser in SimpleQParserPlugin does 
override newPrefixQuery to use the multi-term analysis chain. It does not call 
the base class implementation. (the base class is basically a loop and a new. I 
looked at using a lambda to share a bit more code, but I found that more 
confusing).

The problem I was trying to fix is that the existing implementation does not 
override newFuzzyQuery to use the muti-term analysis chain for fuzzy queries. 
So I basically duplicated what had been done for newPrefixQuery in 
SimpleQParser.



> SimpleQueryParser doesn't use MultiTermAnalysis for Fuzzy Queries
> -
>
> Key: SOLR-8318
> URL: https://issues.apache.org/jira/browse/SOLR-8318
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 5.3
>Reporter: Tom Hill
>Assignee: Erick Erickson
>Priority: Trivial
> Attachments: sqp_fuzzy_multiterm.patch
>
>
> Fuzzy queries in SimpleQParserPlugin don't seem to use the multi-term 
> analysis chain. Prefix queries do, and SolrQueryParser does use multi-term 
> analysis for fuzzy queries, so it seems like SimpleQParserPlugin should as 
> well.



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

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

[jira] [Updated] (SOLR-8099) Remove sleep() function / ValueSourceParser

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-8099:
---
Attachment: SOLR-8099.patch

I'm not really sure myself if this is a security issue. Was just wondering if 
it served any purpose. And seems like it does.

Do you think we can stop loading it implicitly for everyone, and load it up 
using solrconfig.xml for only those who want it?
Here's a patch that adds the two VSPs to solrconfig.xml, and the 
QueryEqualityTest.testTestFunc() passes.

> Remove sleep() function / ValueSourceParser
> ---
>
> Key: SOLR-8099
> URL: https://issues.apache.org/jira/browse/SOLR-8099
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>  Labels: security
> Fix For: 5.4
>
> Attachments: SOLR-8099.patch, SOLR-8099.patch, SOLR-8099.patch
>
>
> As per Doug Turnbull, the sleep() represents a security risk.
> {noformat}
> I noticed a while back that "sleep" is a function query. Which I
> believe means I can make the current query thread sleep for as long as I
> like.
> I'm guessing an attacker could use this to starve Solr of threads, running
> a denial of service attack by running multiple queries with sleeps in them.
> Is this a concern? I realize there may be test purposes to sleep a function
> query, but I'm trying to think if there's really practical purpose to
> having sleep here.
> Best,
> -Doug
> {noformat}
> This issue is to remove it, since it is neither documented publicly, nor used 
> internally very much, apart from one test suite.



--
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-8344) Decide default when requested fields are both column and row stored.

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8344:


[~erickerickson] As of now, users got the stored value directly, but the dv 
value by using field(). If we load stored fields also from docValues, do you 
think adding a function stored(), which would actually go and retrieve the row 
stored value, solve this usecase?

> Decide default when requested fields are both column and row stored.
> 
>
> Key: SOLR-8344
> URL: https://issues.apache.org/jira/browse/SOLR-8344
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>
> This issue was discussed in the comments at SOLR-8220. Splitting it out to a 
> separate issue so that we can have a focused discussion on whether/how to do 
> this.
> If a given set of requested fields are all stored and have docValues (column 
> stored), we can retrieve the values from either place.  What should the 
> default be?



--
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-8180) Missing logging dependency in solrj-lib for SolrJ

[ASF subversion and git services (JIRA)]

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

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

Commit 1717481 from [~dsmiley] in branch 'dev/trunk'
[ https://svn.apache.org/r1717481 ]

SOLR-8180: jcl-over-slf4j is officially a solrj/solr dependency now; not marked 
optional in a POM.

> Missing logging dependency in solrj-lib for SolrJ
> -
>
> Key: SOLR-8180
> URL: https://issues.apache.org/jira/browse/SOLR-8180
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>Assignee: David Smiley
> Fix For: 5.4
>
> Attachments: SOLR-8180.patch, SOLR_8180_jcl_over_slf4j.patch, 
> SOLR_8180_jcl_over_slf4j.patch
>
>
> When using DBVisualizer, SquirrelSQL, or Java JDBC with the Solr JDBC driver, 
> an additional logging dependency must be added otherwise the following 
> exception occurs:
> {code}
> org.apache.solr.common.SolrException: Unable to create HttpClient instance. 
>   at 
> org.apache.solr.client.solrj.impl.HttpClientUtil$HttpClientFactory.createHttpClient(HttpClientUtil.java:393)
>   at 
> org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:124)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.(CloudSolrClient.java:196)
>   at 
> org.apache.solr.client.solrj.io.SolrClientCache.getCloudSolrClient(SolrClientCache.java:47)
>   at 
> org.apache.solr.client.solrj.io.sql.ConnectionImpl.(ConnectionImpl.java:51)
>   at 
> org.apache.solr.client.solrj.io.sql.DriverImpl.connect(DriverImpl.java:108)
>   at 
> org.apache.solr.client.solrj.io.sql.DriverImpl.connect(DriverImpl.java:76)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at com.onseven.dbvis.h.B.D.ￄﾁ(Z:1548)
>   at com.onseven.dbvis.h.B.F$A.call(Z:1369)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>   at 
> org.apache.solr.client.solrj.impl.HttpClientUtil$HttpClientFactory.createHttpClient(HttpClientUtil.java:391)
>   ... 16 more
> Caused by: java.lang.NoClassDefFoundError: 
> org/apache/commons/logging/LogFactory
>   at 
> org.apache.http.impl.client.CloseableHttpClient.(CloseableHttpClient.java:58)
>   at 
> org.apache.http.impl.client.AbstractHttpClient.(AbstractHttpClient.java:287)
>   at 
> org.apache.http.impl.client.DefaultHttpClient.(DefaultHttpClient.java:128)
>   at 
> org.apache.http.impl.client.SystemDefaultHttpClient.(SystemDefaultHttpClient.java:116)
>   ... 21 more
> {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-8180) Missing logging dependency in solrj-lib for SolrJ

[ASF subversion and git services (JIRA)]

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

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

Commit 1717483 from [~dsmiley] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1717483 ]

SOLR-8180: jcl-over-slf4j is officially a solrj/solr dependency now; not marked 
optional in a POM.

> Missing logging dependency in solrj-lib for SolrJ
> -
>
> Key: SOLR-8180
> URL: https://issues.apache.org/jira/browse/SOLR-8180
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>Assignee: David Smiley
> Fix For: 5.4
>
> Attachments: SOLR-8180.patch, SOLR_8180_jcl_over_slf4j.patch, 
> SOLR_8180_jcl_over_slf4j.patch
>
>
> When using DBVisualizer, SquirrelSQL, or Java JDBC with the Solr JDBC driver, 
> an additional logging dependency must be added otherwise the following 
> exception occurs:
> {code}
> org.apache.solr.common.SolrException: Unable to create HttpClient instance. 
>   at 
> org.apache.solr.client.solrj.impl.HttpClientUtil$HttpClientFactory.createHttpClient(HttpClientUtil.java:393)
>   at 
> org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:124)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.(CloudSolrClient.java:196)
>   at 
> org.apache.solr.client.solrj.io.SolrClientCache.getCloudSolrClient(SolrClientCache.java:47)
>   at 
> org.apache.solr.client.solrj.io.sql.ConnectionImpl.(ConnectionImpl.java:51)
>   at 
> org.apache.solr.client.solrj.io.sql.DriverImpl.connect(DriverImpl.java:108)
>   at 
> org.apache.solr.client.solrj.io.sql.DriverImpl.connect(DriverImpl.java:76)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at com.onseven.dbvis.h.B.D.ￄﾁ(Z:1548)
>   at com.onseven.dbvis.h.B.F$A.call(Z:1369)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>   at 
> org.apache.solr.client.solrj.impl.HttpClientUtil$HttpClientFactory.createHttpClient(HttpClientUtil.java:391)
>   ... 16 more
> Caused by: java.lang.NoClassDefFoundError: 
> org/apache/commons/logging/LogFactory
>   at 
> org.apache.http.impl.client.CloseableHttpClient.(CloseableHttpClient.java:58)
>   at 
> org.apache.http.impl.client.AbstractHttpClient.(AbstractHttpClient.java:287)
>   at 
> org.apache.http.impl.client.DefaultHttpClient.(DefaultHttpClient.java:128)
>   at 
> org.apache.http.impl.client.SystemDefaultHttpClient.(SystemDefaultHttpClient.java:116)
>   ... 21 more
> {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-8321) add a (SolrQueryRequest free) SortSpecParsing.parseSortSpec variant

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8321: add a (SolrQueryRequest free) SortSpecParsing.parseSortSpec variant 
(merge in revision 1717454 from trunk)

> add a (SolrQueryRequest free) SortSpecParsing.parseSortSpec variant
> ---
>
> Key: SOLR-8321
> URL: https://issues.apache.org/jira/browse/SOLR-8321
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8321.patch
>
>
> proposed patch against trunk 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-8344) Decide default when requested fields are both column and row stored.

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8344:


bq. We do want to keep in mind though that from a user perspective, inputting 
'2.178734872984723984729387" as a float and getting back "2.17873477935791" 

Right.  Numeric values are already stored in binary form, so any truncation 
that may occur is already occurring (and should occur in an identical way for 
docvalues).

> Decide default when requested fields are both column and row stored.
> 
>
> Key: SOLR-8344
> URL: https://issues.apache.org/jira/browse/SOLR-8344
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>
> This issue was discussed in the comments at SOLR-8220. Splitting it out to a 
> separate issue so that we can have a focused discussion on whether/how to do 
> this.
> If a given set of requested fields are all stored and have docValues (column 
> stored), we can retrieve the values from either place.  What should the 
> default be?



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

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

[jira] [Updated] (SOLR-8175) Wordbreak spellchecker throws IOOBE with Occur.MUST term

[James Dyer (JIRA)]

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

James Dyer updated SOLR-8175:
-
Attachment: SOLR-8175.patch

here is an updated patch with a slightly different unit test.  It might take a 
little while to get this committed as I'm fighting with the test runner, 
precommit, etc.

> Wordbreak spellchecker throws IOOBE with Occur.MUST term
> 
>
> Key: SOLR-8175
> URL: https://issues.apache.org/jira/browse/SOLR-8175
> Project: Solr
>  Issue Type: Bug
>Reporter: Ryan Josal
>Assignee: James Dyer
> Attachments: SOLR-8175.patch, solr8175.patch
>
>
> Using the WordBreakSolrSpellChecker, if a user queries for "+foo barbaz" and 
> "bar baz" is a suggestion for "barbaz", Solr will throw an 
> IndexOutOfBoundsException.  As a result, a server driven by user queries 
> might throw a certain percentage of HTTP 500 responses as users hit this.



--
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-8321) add a (SolrQueryRequest free) SortSpecParsing.parseSortSpec variant

[Christine Poerschke (JIRA)]

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

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

> add a (SolrQueryRequest free) SortSpecParsing.parseSortSpec variant
> ---
>
> Key: SOLR-8321
> URL: https://issues.apache.org/jira/browse/SOLR-8321
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: Trunk, 5.5
>
> Attachments: SOLR-8321.patch
>
>
> proposed patch against trunk 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-8175) Wordbreak spellchecker throws IOOBE with Occur.MUST term

[ASF subversion and git services (JIRA)]

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

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

Commit 1717492 from jd...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1717492 ]

SOLR-8175: fix AIOOBE w/WordBreakSolrSpellChecker

> Wordbreak spellchecker throws IOOBE with Occur.MUST term
> 
>
> Key: SOLR-8175
> URL: https://issues.apache.org/jira/browse/SOLR-8175
> Project: Solr
>  Issue Type: Bug
>Reporter: Ryan Josal
>Assignee: James Dyer
> Attachments: SOLR-8175.patch, solr8175.patch
>
>
> Using the WordBreakSolrSpellChecker, if a user queries for "+foo barbaz" and 
> "bar baz" is a suggestion for "barbaz", Solr will throw an 
> IndexOutOfBoundsException.  As a result, a server driven by user queries 
> might throw a certain percentage of HTTP 500 responses as users hit this.



--
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-8355) RuleBasedAuthenticationPlugin doesn't work with update permission enabled

[ASF subversion and git services (JIRA)]

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

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

Commit 1717493 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1717493 ]

SOLR-8355: update permissions were failing node recovery

> RuleBasedAuthenticationPlugin doesn't work with update permission enabled
> -
>
> Key: SOLR-8355
> URL: https://issues.apache.org/jira/browse/SOLR-8355
> Project: Solr
>  Issue Type: Bug
>  Components: security
>Affects Versions: 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Noble Paul
>Priority: Blocker
>  Labels: authorization-plugin
> Fix For: 5.4
>
> Attachments: SOLR-8355.patch
>
>
> Here are the steps that recreate this issue. I tried this on Solr 5.4 and I 
> had the following stack trace when I issued an ADDREPLICA. This seems pretty 
> similar to what we saw on SOLR-8326 so it might be just something we missed 
> but we should make sure that we ship 5.4 with this fixed.
> #Upload Security Conf
> server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd putfile 
> /security.json ~/security.json
> #Start Solr
> bin/solr start -e cloud -z localhost:2181
> #Collection Admin Edit Command:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : 
> {"name":"collection-admin-edit", "role":"admin"}}'
> #Read User and permission:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : {"name":"read", 
> "role":"read"}}'
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : {"name":"update", 
> "role":"update"]}}'
> #Add Users
> #Read User
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
> 'Content-type:application/json' -d '{"set-user" : {"solrread":"solrRocks"}}'
> #Update user
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
> 'Content-type:application/json' -d '{"set-user" : {"solrupdate":"solrRocks"}}'
> #Set user roles
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-user-role" : 
> {"solrupdate":["read","update"]}}'
> #Read User
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-user-role" : {"solrread":["read"]}}'
> #Create collection
> curl --user solr:SolrRocks 
> 'http://localhost:8983/solr/admin/collections?action=CREATE=a=1=1=gettingstarted=json'
> #Add Replica
> curl --user solr:SolrRocks 
> 'http://localhost:8983/solr/admin/collections?action=ADDREPLICA=a=shard1=json'
> Exception log:
> INFO  - 2015-12-01 04:57:47.022; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.cloud.RecoveryStrategy; Starting 
> Replication Recovery.
> INFO  - 2015-12-01 04:57:47.023; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.cloud.RecoveryStrategy; Attempting to 
> replicate from http://172.20.10.4:7574/solr/a_shard1_replica1/.
> ERROR - 2015-12-01 04:57:47.027; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.common.SolrException; Error while trying 
> to 
> recover:org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
> Error from server at http://172.20.10.4:7574/solr/a_shard1_replica1: Expected 
> mime type application/octet-stream but got text/html. 
> 
> 
> Error 401 Unauthorized request, Response code: 401
> 
> HTTP ERROR 401
> Problem accessing /solr/a_shard1_replica1/update. Reason:
> Unauthorized request, Response code: 
> 401Powered by Jetty://
> 
> 
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:167)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.commitOnLeader(RecoveryStrategy.java:205)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.replicate(RecoveryStrategy.java:145)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:436)
>   at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:225)
> INFO  - 2015-12-01 04:57:47.028; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] 

[jira] [Commented] (SOLR-8355) RuleBasedAuthenticationPlugin doesn't work with update permission enabled

[ASF subversion and git services (JIRA)]

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

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

Commit 1717494 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1717494 ]

SOLR-8355: update permissions were failing node recovery

> RuleBasedAuthenticationPlugin doesn't work with update permission enabled
> -
>
> Key: SOLR-8355
> URL: https://issues.apache.org/jira/browse/SOLR-8355
> Project: Solr
>  Issue Type: Bug
>  Components: security
>Affects Versions: 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Noble Paul
>Priority: Blocker
>  Labels: authorization-plugin
> Fix For: 5.4
>
> Attachments: SOLR-8355.patch
>
>
> Here are the steps that recreate this issue. I tried this on Solr 5.4 and I 
> had the following stack trace when I issued an ADDREPLICA. This seems pretty 
> similar to what we saw on SOLR-8326 so it might be just something we missed 
> but we should make sure that we ship 5.4 with this fixed.
> #Upload Security Conf
> server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd putfile 
> /security.json ~/security.json
> #Start Solr
> bin/solr start -e cloud -z localhost:2181
> #Collection Admin Edit Command:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : 
> {"name":"collection-admin-edit", "role":"admin"}}'
> #Read User and permission:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : {"name":"read", 
> "role":"read"}}'
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : {"name":"update", 
> "role":"update"]}}'
> #Add Users
> #Read User
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
> 'Content-type:application/json' -d '{"set-user" : {"solrread":"solrRocks"}}'
> #Update user
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
> 'Content-type:application/json' -d '{"set-user" : {"solrupdate":"solrRocks"}}'
> #Set user roles
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-user-role" : 
> {"solrupdate":["read","update"]}}'
> #Read User
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-user-role" : {"solrread":["read"]}}'
> #Create collection
> curl --user solr:SolrRocks 
> 'http://localhost:8983/solr/admin/collections?action=CREATE=a=1=1=gettingstarted=json'
> #Add Replica
> curl --user solr:SolrRocks 
> 'http://localhost:8983/solr/admin/collections?action=ADDREPLICA=a=shard1=json'
> Exception log:
> INFO  - 2015-12-01 04:57:47.022; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.cloud.RecoveryStrategy; Starting 
> Replication Recovery.
> INFO  - 2015-12-01 04:57:47.023; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.cloud.RecoveryStrategy; Attempting to 
> replicate from http://172.20.10.4:7574/solr/a_shard1_replica1/.
> ERROR - 2015-12-01 04:57:47.027; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.common.SolrException; Error while trying 
> to 
> recover:org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
> Error from server at http://172.20.10.4:7574/solr/a_shard1_replica1: Expected 
> mime type application/octet-stream but got text/html. 
> 
> 
> Error 401 Unauthorized request, Response code: 401
> 
> HTTP ERROR 401
> Problem accessing /solr/a_shard1_replica1/update. Reason:
> Unauthorized request, Response code: 
> 401Powered by Jetty://
> 
> 
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:167)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.commitOnLeader(RecoveryStrategy.java:205)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.replicate(RecoveryStrategy.java:145)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:436)
>   at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:225)
> INFO  - 2015-12-01 04:57:47.028; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] 

Re: [JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_66) - Build # 5437 - Still Failing!

[Dawid Weiss]

This reproduces. Looks like it picks CheapBastard codec and it doesn't
play too nice with the tests?

Dawid

On Wed, Dec 2, 2015 at 1:31 AM, Policeman Jenkins Server
 wrote:
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5437/
> Java: 64bit/jdk1.8.0_66 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
>
> 2 tests failed.
> FAILED:  
> org.apache.lucene.index.TestIndexWriterExceptions.testMergeExceptionIsTragic
>
> 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([8DA8EC6B89D77C2E]:0)
>
>
> FAILED:  
> junit.framework.TestSuite.org.apache.lucene.index.TestIndexWriterExceptions
>
> Error Message:
> Suite timeout exceeded (>= 720 msec).
>
> Stack Trace:
> java.lang.Exception: Suite timeout exceeded (>= 720 msec).
> at __randomizedtesting.SeedInfo.seed([8DA8EC6B89D77C2E]:0)
>
>
>
>
> Build Log:
> [...truncated 1819 lines...]
>[junit4] Suite: org.apache.lucene.index.TestIndexWriterExceptions
>[junit4]   2> Noll 02, 2015 2:31:19 A.M. 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
>[junit4]   2> WARNING: Suite execution timed out: 
> org.apache.lucene.index.TestIndexWriterExceptions
>[junit4]   2>1) Thread[id=1489, 
> name=TEST-TestIndexWriterExceptions.testMergeExceptionIsTragic-seed#[8DA8EC6B89D77C2E],
>  state=RUNNABLE, group=TGRP-TestIndexWriterExceptions]
>[junit4]   2> at java.util.HashMap.hash(HashMap.java:338)
>[junit4]   2> at java.util.HashMap.put(HashMap.java:611)
>[junit4]   2> at java.util.HashSet.add(HashSet.java:219)
>[junit4]   2> at 
> org.apache.lucene.index.IndexWriter$ReaderPool.noDups(IndexWriter.java:679)
>[junit4]   2> at 
> org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:668)
>[junit4]   2> at 
> org.apache.lucene.index.IndexWriter.numDeletedDocs(IndexWriter.java:694)
>[junit4]   2> at 
> org.apache.lucene.index.MergePolicy.size(MergePolicy.java:451)
>[junit4]   2> at 
> org.apache.lucene.index.TieredMergePolicy$SegmentByteSizeDescending.compare(TieredMergePolicy.java:249)
>[junit4]   2> at 
> org.apache.lucene.index.TieredMergePolicy$SegmentByteSizeDescending.compare(TieredMergePolicy.java:238)
>[junit4]   2> at java.util.TimSort.mergeHi(TimSort.java:837)
>[junit4]   2> at java.util.TimSort.mergeAt(TimSort.java:516)
>[junit4]   2> at 
> java.util.TimSort.mergeForceCollapse(TimSort.java:457)
>[junit4]   2> at java.util.TimSort.sort(TimSort.java:254)
>[junit4]   2> at java.util.Arrays.sort(Arrays.java:1512)
>[junit4]   2> at java.util.ArrayList.sort(ArrayList.java:1454)
>[junit4]   2> at java.util.Collections.sort(Collections.java:175)
>[junit4]   2> at 
> org.apache.lucene.index.TieredMergePolicy.findMerges(TieredMergePolicy.java:292)
>[junit4]   2> at 
> org.apache.lucene.index.IndexWriter.updatePendingMerges(IndexWriter.java:1952)
>[junit4]   2> at 
> org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1916)
>[junit4]   2> at 
> org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:454)
>[junit4]   2> at 
> org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:86)
>[junit4]   2> at 
> org.apache.lucene.index.TestIndexWriterExceptions.testMergeExceptionIsTragic(TestIndexWriterExceptions.java:2340)
>[junit4]   2> at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]   2> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]   2> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]   2> at java.lang.reflect.Method.invoke(Method.java:497)
>[junit4]   2> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
>[junit4]   2> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
>[junit4]   2> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
>[junit4]   2> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
>[junit4]   2> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>[junit4]   2> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>[junit4]   2> at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>[junit4]   2> at 
> 

[JENKINS] Lucene-Solr-SmokeRelease-trunk - Build # 351 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-trunk/351/

No tests ran.

Build Log:
[...truncated 52623 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.1 MB in 0.01 sec (18.9 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.0.0-src.tgz...
   [smoker] 28.3 MB in 0.04 sec (795.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.0.0.tgz...
   [smoker] 65.4 MB in 0.08 sec (772.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.0.0.zip...
   [smoker] 75.9 MB in 0.10 sec (771.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5951 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5951 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 211 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.1 MB in 0.00 sec (145.9 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.0.0-src.tgz...
   [smoker] 37.2 MB in 0.05 sec (735.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.0.0.tgz...
   [smoker] 132.0 MB in 0.18 sec (733.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.0.0.zip...
   [smoker] 140.3 MB in 0.19 sec (747.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 30 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]   [/]  

[GitHub] lucene-solr pull request: SOLR-8059 - NPE distributed DebugCompone...

[manisnesan]

GitHub user manisnesan opened a pull request:

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

SOLR-8059 - NPE distributed DebugComponent. Test reproducer

This patch reproduces the NPE exception thrown when fl=id query param used 
along with debug=true or debug=results.

Example
curl 
"http://localhost:8983/solr/techproducts/select?q=*%3A*=json=true=true=id,score;
 => NPE thrown
curl 
"http://localhost:8983/solr/techproducts/select?q=*%3A*=ruby=true=results=id,score;
 => NPE thrown

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

$ git pull https://github.com/manisnesan/lucene-solr trunk

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

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

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

This closes #213


commit d28cd093a907446a632ede1a2838f0f405b1cfa9
Author: Mani 
Date:   2015-12-02T03:27:15Z

SOLR-8059 - NPE distributed DebugComponent. Test to reproduce NPE in 
DebugComponent.




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

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

[jira] [Updated] (SOLR-8220) Read field from docValues for non stored fields

[Keith Laban (JIRA)]

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

Keith Laban updated SOLR-8220:
--
Attachment: SOLR-8220.patch

- Removed leaked in {{SolrBaseDocument}} references 
- Fixed support for EnumField (single and multi valued)
- Fixed support for {{*_i}} type globs
- Removed tests from {{BasicFuntionalityTests}} and moved them to a new test 
class along with its own test schema.
- Added more robust testing including multivalued field testing 

> Read field from docValues for non stored fields
> ---
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, 
> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>-- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



--
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-8220) Read field from docValues for non stored fields

[Keith Laban (JIRA)]

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

Keith Laban commented on SOLR-8220:
---

This still needs work around bumping the schema version, this impl changes the 
default behavior for globs

> Read field from docValues for non stored fields
> ---
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, 
> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>-- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



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

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic

Error Message:
127.0.0.1:44865 failed to respond

Stack Trace:
org.apache.http.NoHttpResponseException: 127.0.0.1:44865 failed to respond
at 
__randomizedtesting.SeedInfo.seed([4EE3FEA531BBACFC:E519E3B0EE672AD2]:0)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at 
org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
at 
org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at 
org.apache.lucene.replicator.http.HttpClientBase.executeGET(HttpClientBase.java:159)
at 
org.apache.lucene.replicator.http.HttpReplicator.checkForUpdate(HttpReplicator.java:51)
at 
org.apache.lucene.replicator.ReplicationClient.doUpdate(ReplicationClient.java:196)
at 
org.apache.lucene.replicator.ReplicationClient.updateNow(ReplicationClient.java:402)
at 
org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic(HttpReplicatorTest.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Commented] (SOLR-8059) NPE distributed DebugComponent

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8059:
--

GitHub user manisnesan opened a pull request:

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

SOLR-8059 - NPE distributed DebugComponent. Test reproducer

This patch reproduces the NPE exception thrown when fl=id query param used 
along with debug=true or debug=results.

Example
curl 
"http://localhost:8983/solr/techproducts/select?q=*%3A*=json=true=true=id,score;
 => NPE thrown
curl 
"http://localhost:8983/solr/techproducts/select?q=*%3A*=ruby=true=results=id,score;
 => NPE thrown

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

$ git pull https://github.com/manisnesan/lucene-solr trunk

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

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

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

This closes #213


commit d28cd093a907446a632ede1a2838f0f405b1cfa9
Author: Mani 
Date:   2015-12-02T03:27:15Z

SOLR-8059 - NPE distributed DebugComponent. Test to reproduce NPE in 
DebugComponent.




> NPE distributed DebugComponent
> --
>
> Key: SOLR-8059
> URL: https://issues.apache.org/jira/browse/SOLR-8059
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.4
>
>
> The following URL select?debug=true=*:*=id,score yields
> {code}
> java.lang.NullPointerException
>   at 
> org.apache.solr.handler.component.DebugComponent.finishStage(DebugComponent.java:229)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:416)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:210)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:499)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> I can reproduce it everytime. Strange enough fl=*,score, or any other content 
> field does not! I have seen this happening in Highlighter as well on the same 
> code path. It makes little sense, how would fl influence that piece of code, 
> the id is requested in fl afterall.



--
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-8059) NPE distributed DebugComponent

[Mani (JIRA)]

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

Mani commented on SOLR-8059:


[~shalinmangar]  Since I do not have enough context/understanding about the 
DebugComponent, I have just updated with the reproducer. If you have any 
comments with the test let me know I can submit an updated patch.


> NPE distributed DebugComponent
> --
>
> Key: SOLR-8059
> URL: https://issues.apache.org/jira/browse/SOLR-8059
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Markus Jelsma
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.4
>
>
> The following URL select?debug=true=*:*=id,score yields
> {code}
> java.lang.NullPointerException
>   at 
> org.apache.solr.handler.component.DebugComponent.finishStage(DebugComponent.java:229)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:416)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:210)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:499)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> I can reproduce it everytime. Strange enough fl=*,score, or any other content 
> field does not! I have seen this happening in Highlighter as well on the same 
> code path. It makes little sense, how would fl influence that piece of code, 
> the id is requested in fl afterall.



--
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-6392) If run Solr having two collections configured but only one config delivered to Zookeeper causes that config is applied for all collections

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-6392:
--

Frank:

Here's the rules if you don't specify a configName when issuing the Collections 
API CREATE command (at least as I understand them)

0> if there are no config sets in ZK, fail
1> if there's a configset with the same name as the collection use it. 
2> else if there's only a single configset, use that regardless of whether name 
matches or not.
3> else if there's more than one configset, fail.

The above if (and only if) there is no config specified when creating the 
collection. If you do specify a configset name, then of course it has to be 
there or collection creation fails.

So here's one possible sequence leading to what's described here:
1> upload a config set with a name of "bonkers".
2> create collection1 with or without specifying the configset name
3> create collection2 with or without specifying the configset name

Now, both are registered with ZK as using configset "bonkers" and will stay 
that way unless and until that association is explicitly changed via linkconfig 
as Mark recommended.

It would be dangerous IMO to change the config set associated with collection2 
just because someone uploaded a new configset with the name collection2.

So I believe this is working as designed, I'm going to close it. We can reopen 
or create a new JIRA if necessary.

> If run Solr having two collections configured but only one config delivered 
> to Zookeeper causes that config is applied for all collections
> --
>
> Key: SOLR-6392
> URL: https://issues.apache.org/jira/browse/SOLR-6392
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Ilya Meleshkov
>
> I have simplest Solr cloud configured locally. Thus I have single Solr and 
> Zookeeper nodes. 
> Steps to reproduce an error:
> # have stopped Solr+ZK with two collections
> # run ZK
> # deliver config to one collection only
> # run Solr - Solr running without any complains or errors
> # deliver config to second collection - doesn't have an effect
> But if I deliver configs for both collections before start Solr - it work 
> perfectly.
> So I would say that Solr should fail with meaningful error if there is no 
> config for some collection.



--
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-6392) If run Solr having two collections configured but only one config delivered to Zookeeper causes that config is applied for all collections

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-6392.
--
Resolution: Not A Problem

> If run Solr having two collections configured but only one config delivered 
> to Zookeeper causes that config is applied for all collections
> --
>
> Key: SOLR-6392
> URL: https://issues.apache.org/jira/browse/SOLR-6392
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Ilya Meleshkov
>
> I have simplest Solr cloud configured locally. Thus I have single Solr and 
> Zookeeper nodes. 
> Steps to reproduce an error:
> # have stopped Solr+ZK with two collections
> # run ZK
> # deliver config to one collection only
> # run Solr - Solr running without any complains or errors
> # deliver config to second collection - doesn't have an effect
> But if I deliver configs for both collections before start Solr - it work 
> perfectly.
> So I would say that Solr should fail with meaningful error if there is no 
> config for some collection.



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

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

[jira] [Updated] (SOLR-8220) Read field from docValues for non stored fields

[Keith Laban (JIRA)]

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

Keith Laban updated SOLR-8220:
--
Attachment: SOLR-8220.patch

Crushed one more bug with multivalued fields being added on docs without that 
value and a test for it

> Read field from docValues for non stored fields
> ---
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, 
> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>-- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



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

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

[jira] [Updated] (SOLR-8220) Read field from docValues for non stored fields

[Keith Laban (JIRA)]

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

Keith Laban updated SOLR-8220:
--
Attachment: SOLR-8220.patch

One more patch.. It looks like at some point the logic for {{onlyPseudoFields}} 
was modified to something that may not work, so reverting that line back to the 
original.

> Read field from docValues for non stored fields
> ---
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, 
> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>-- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



--
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-8355) RuleBasedAuthenticationPlugin doesn't work with update permission enabled

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-8355.
--
   Resolution: Fixed
Fix Version/s: Trunk

> RuleBasedAuthenticationPlugin doesn't work with update permission enabled
> -
>
> Key: SOLR-8355
> URL: https://issues.apache.org/jira/browse/SOLR-8355
> Project: Solr
>  Issue Type: Bug
>  Components: security
>Affects Versions: 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Noble Paul
>Priority: Blocker
>  Labels: authorization-plugin
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8355.patch
>
>
> Here are the steps that recreate this issue. I tried this on Solr 5.4 and I 
> had the following stack trace when I issued an ADDREPLICA. This seems pretty 
> similar to what we saw on SOLR-8326 so it might be just something we missed 
> but we should make sure that we ship 5.4 with this fixed.
> #Upload Security Conf
> server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd putfile 
> /security.json ~/security.json
> #Start Solr
> bin/solr start -e cloud -z localhost:2181
> #Collection Admin Edit Command:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : 
> {"name":"collection-admin-edit", "role":"admin"}}'
> #Read User and permission:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : {"name":"read", 
> "role":"read"}}'
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : {"name":"update", 
> "role":"update"]}}'
> #Add Users
> #Read User
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
> 'Content-type:application/json' -d '{"set-user" : {"solrread":"solrRocks"}}'
> #Update user
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
> 'Content-type:application/json' -d '{"set-user" : {"solrupdate":"solrRocks"}}'
> #Set user roles
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-user-role" : 
> {"solrupdate":["read","update"]}}'
> #Read User
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-user-role" : {"solrread":["read"]}}'
> #Create collection
> curl --user solr:SolrRocks 
> 'http://localhost:8983/solr/admin/collections?action=CREATE=a=1=1=gettingstarted=json'
> #Add Replica
> curl --user solr:SolrRocks 
> 'http://localhost:8983/solr/admin/collections?action=ADDREPLICA=a=shard1=json'
> Exception log:
> INFO  - 2015-12-01 04:57:47.022; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.cloud.RecoveryStrategy; Starting 
> Replication Recovery.
> INFO  - 2015-12-01 04:57:47.023; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.cloud.RecoveryStrategy; Attempting to 
> replicate from http://172.20.10.4:7574/solr/a_shard1_replica1/.
> ERROR - 2015-12-01 04:57:47.027; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.common.SolrException; Error while trying 
> to 
> recover:org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
> Error from server at http://172.20.10.4:7574/solr/a_shard1_replica1: Expected 
> mime type application/octet-stream but got text/html. 
> 
> 
> Error 401 Unauthorized request, Response code: 401
> 
> HTTP ERROR 401
> Problem accessing /solr/a_shard1_replica1/update. Reason:
> Unauthorized request, Response code: 
> 401Powered by Jetty://
> 
> 
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:167)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.commitOnLeader(RecoveryStrategy.java:205)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.replicate(RecoveryStrategy.java:145)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:436)
>   at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:225)
> INFO  - 2015-12-01 04:57:47.028; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.update.UpdateLog; Dropping buffered 
> updates FSUpdateLog{state=BUFFERING, tlog=null}
> ERROR - 2015-12-01 04:57:47.028; [c:a s:shard1 r:core_node2 
> 

[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1618: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1618/

No tests ran.

Build Log:
[...truncated 36891 lines...]
-validate-maven-dependencies:
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-test-framework:6.0.0-SNAPSHOT: checking for updates 
from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-test-framework:6.0.0-SNAPSHOT: checking for updates 
from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
sonatype.releases
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-common:6.0.0-SNAPSHOT: checking for updates 
from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-common:6.0.0-SNAPSHOT: checking for updates 
from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-kuromoji:6.0.0-SNAPSHOT: checking for 
updates from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-kuromoji:6.0.0-SNAPSHOT: checking for 
updates from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-phonetic:6.0.0-SNAPSHOT: checking for 
updates from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-phonetic:6.0.0-SNAPSHOT: checking for 
updates from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-backward-codecs:6.0.0-SNAPSHOT: checking for updates 
from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-backward-codecs:6.0.0-SNAPSHOT: checking for updates 
from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-codecs:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-codecs:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-core:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-core:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-expressions:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-expressions:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-grouping:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-grouping:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-highlighter:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-highlighter:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-join:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-join:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-memory:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-memory:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-misc:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-misc:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queries:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queries:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queryparser:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queryparser:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-sandbox:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-sandbox:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] 

Re: 5.4 branch created, feature freeze in place (was Re: A 5.4 release?)

[Noble Paul]

I'm done with SOLR-8355

On Tue, Dec 1, 2015 at 4:24 PM, Noble Paul  wrote:
> hi Upayavira,
> sorry for the trouble. There is another blocker created
> https://issues.apache.org/jira/browse/SOLR-8355
> I'm fixing that
>
> On Mon, Nov 30, 2015 at 8:26 PM, Christine Poerschke (BLOOMBERG/
> LONDON)  wrote:
>> Fair point, I have re-worded the ticket title and summary. Will await
>> further opinions before applying or not applying the patch to 5.4 branch
>> (and trunk and branch_5x).
>>
>> Christine
>>
>> From: dev@lucene.apache.org At: Nov 30 2015 14:29:58
>> To: dev@lucene.apache.org
>> Subject: Re: 5.4 branch created, feature freeze in place (was Re: A 5.4
>> release?)
>>
>> The patch seems innocuous enough. From the ticket though it isn't so clear
>> to me what problem it solves. I'm open to the opinion of others.
>>
>> Upayavira
>>
>> On Mon, Nov 30, 2015, at 12:09 PM, Christine Poerschke (BLOOMBERG/ LONDON)
>> wrote:
>>
>> Any thoughts on getting the
>> https://issues.apache.org/jira/browse/LUCENE-6911 fix into 5.4 solr or not?
>> Basically StandardQueryParser's existing getMultiFields method is a no-op.
>>
>> From: dev@lucene.apache.org At: Nov 25 2015 14:11:46
>> To: dev@lucene.apache.org
>> Subject: Re:5.4 branch created, feature freeze in place (was Re: A 5.4
>> release?)
>>
>> I have created the lucene_solr_5_4 branch. Please, no new features in this
>> branch.
>>
>> Please update this thread with any changes you propose to make to this
>> branch. Only JIRA tickets which are a blocker and have fix version 5.4 will
>> delay a release candidate build.
>>
>> Please do review the below - and take any action to clear up these tickets
>> asap.
>>
>> I expect to create the first RC this time next week.
>>
>> Thanks!
>>
>> Upayavira
>>
>> On Wed, Nov 25, 2015, at 02:05 PM, Upayavira wrote:
>>
>> I shall shortly create the 5.4 release branch. From this moment, the feature
>> freeze starts.
>>
>> Looking through JIRA, I see some 71 tickets assigned to fix version 5.4. I
>> suspect we won't be able to fix all 71 in one week, so I expect that the
>> majority will be pushed, after this release, to 5.5.
>>
>> Looking for blockers or critical tickets, I see five tickets:
>>
>> https://issues.apache.org/jira/browse/SOLR-8326 (Anusham, Noble) blocker
>>   "Adding read restriction to BasicAuth + RuleBased authorization causes
>> issue with replication"
>>
>>   Anusham/Noble - any thoughts on how to resolve this before the release?
>>
>> https://issues.apache.org/jira/browse/SOLR-8035 (Erik) critical
>>   "Move solr/webapp to solr/server/solr-webapp"
>>
>>   This one I know isn't a blocker in any sense.
>>
>> https://issues.apache.org/jira/browse/SOLR-7901 (Erik) critical
>>   "Add tests for bin/post"
>>
>>   Again, this one does not seem to be something worthy of holding back a
>> release
>>
>> https://issues.apache.org/jira/browse/LUCENE-6723 (Uwe) critical
>>   "Date field problems using ExtractingRequestHandler and java 9 (b71)"
>>
>>   Uwe, I presume as this relates to Java 9, it isn't a blocker?
>>
>> https://issues.apache.org/jira/browse/LUCENE-6722 (Shalin, others), blocker
>>   "Java 8 as the minimum supported JVM version for branch_5x"
>>
>>   Looking at the discussion, there was no consensus here, so I will not
>> consider this a blocker either.
>>
>>   - o -
>>
>> So SOLR-8326 and LUCENE-6723 seem to be the ones worthy of attention. Anyone
>> have comments/observations here?
>>
>> I will create the branch shortly.
>>
>> Upayavira
>>
>>
>>
>>
>
>
>
> --
> -
> Noble Paul



-- 
-
Noble Paul

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.client.solrj.embedded.SolrExampleStreamingBinaryTest.testUpdateField

Error Message:
ConcurrentUpdateSolrClient did not report an error

Stack Trace:
java.lang.AssertionError: ConcurrentUpdateSolrClient did not report an error
at 
__randomizedtesting.SeedInfo.seed([CF20CDD42B4918AA:9A536780EB61086C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.client.solrj.SolrExampleTests.testUpdateField(SolrExampleTests.java:1632)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest.testUpdateField

Error Message:
ConcurrentUpdateSolrClient did not report an error

Stack Trace:
java.lang.AssertionError: ConcurrentUpdateSolrClient 

[jira] [Commented] (SOLR-8180) Missing logging dependency in solrj-lib for SolrJ

[ASF subversion and git services (JIRA)]

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

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

Commit 1717497 from [~dsmiley] in branch 'dev/branches/lucene_solr_5_4'
[ https://svn.apache.org/r1717497 ]

SOLR-8180: jcl-over-slf4j is officially a solrj/solr dependency now; not marked 
optional in a POM.

> Missing logging dependency in solrj-lib for SolrJ
> -
>
> Key: SOLR-8180
> URL: https://issues.apache.org/jira/browse/SOLR-8180
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>Assignee: David Smiley
> Fix For: 5.4
>
> Attachments: SOLR-8180.patch, SOLR_8180_jcl_over_slf4j.patch, 
> SOLR_8180_jcl_over_slf4j.patch
>
>
> When using DBVisualizer, SquirrelSQL, or Java JDBC with the Solr JDBC driver, 
> an additional logging dependency must be added otherwise the following 
> exception occurs:
> {code}
> org.apache.solr.common.SolrException: Unable to create HttpClient instance. 
>   at 
> org.apache.solr.client.solrj.impl.HttpClientUtil$HttpClientFactory.createHttpClient(HttpClientUtil.java:393)
>   at 
> org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:124)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.(CloudSolrClient.java:196)
>   at 
> org.apache.solr.client.solrj.io.SolrClientCache.getCloudSolrClient(SolrClientCache.java:47)
>   at 
> org.apache.solr.client.solrj.io.sql.ConnectionImpl.(ConnectionImpl.java:51)
>   at 
> org.apache.solr.client.solrj.io.sql.DriverImpl.connect(DriverImpl.java:108)
>   at 
> org.apache.solr.client.solrj.io.sql.DriverImpl.connect(DriverImpl.java:76)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at com.onseven.dbvis.h.B.D.ￄﾁ(Z:1548)
>   at com.onseven.dbvis.h.B.F$A.call(Z:1369)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>   at 
> org.apache.solr.client.solrj.impl.HttpClientUtil$HttpClientFactory.createHttpClient(HttpClientUtil.java:391)
>   ... 16 more
> Caused by: java.lang.NoClassDefFoundError: 
> org/apache/commons/logging/LogFactory
>   at 
> org.apache.http.impl.client.CloseableHttpClient.(CloseableHttpClient.java:58)
>   at 
> org.apache.http.impl.client.AbstractHttpClient.(AbstractHttpClient.java:287)
>   at 
> org.apache.http.impl.client.DefaultHttpClient.(DefaultHttpClient.java:128)
>   at 
> org.apache.http.impl.client.SystemDefaultHttpClient.(SystemDefaultHttpClient.java:116)
>   ... 21 more
> {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-8344) Decide default when requested fields are both column and row stored.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8344:
--

Damn, ya' learn something new every day. 

It's still a problem with dates though. If I index something like: 
2015-11-11T12:12:12Z-3DAYS I get back 2015-11-08T12:12:12Z

I'm not sure it matters enough to worry about, but whatever we do should be 
intentional.

> Decide default when requested fields are both column and row stored.
> 
>
> Key: SOLR-8344
> URL: https://issues.apache.org/jira/browse/SOLR-8344
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>
> This issue was discussed in the comments at SOLR-8220. Splitting it out to a 
> separate issue so that we can have a focused discussion on whether/how to do 
> this.
> If a given set of requested fields are all stored and have docValues (column 
> stored), we can retrieve the values from either place.  What should the 
> default be?



--
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-8344) Decide default when requested fields are both column and row stored.

[Erick Erickson (JIRA)]

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

Erick Erickson edited comment on SOLR-8344 at 12/1/15 7:07 PM:
---

Damn, ya' learn something new every day. 

Golly, I need to think before I type. We get the transformed date back from the 
_stored_ field.

So never mind the whole "they may not get back what they put in" discussion, 
it's misguided.



was (Author: erickerickson):
Damn, ya' learn something new every day. 

It's still a problem with dates though. If I index something like: 
2015-11-11T12:12:12Z-3DAYS I get back 2015-11-08T12:12:12Z

I'm not sure it matters enough to worry about, but whatever we do should be 
intentional.

> Decide default when requested fields are both column and row stored.
> 
>
> Key: SOLR-8344
> URL: https://issues.apache.org/jira/browse/SOLR-8344
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>
> This issue was discussed in the comments at SOLR-8220. Splitting it out to a 
> separate issue so that we can have a focused discussion on whether/how to do 
> this.
> If a given set of requested fields are all stored and have docValues (column 
> stored), we can retrieve the values from either place.  What should the 
> default be?



--
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-8355) RuleBasedAuthenticationPlugin doesn't work with update permission enabled

[ASF subversion and git services (JIRA)]

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

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

Commit 1717495 from [~noble.paul] in branch 'dev/branches/lucene_solr_5_4'
[ https://svn.apache.org/r1717495 ]

SOLR-8355: update permissions were failing node recovery

> RuleBasedAuthenticationPlugin doesn't work with update permission enabled
> -
>
> Key: SOLR-8355
> URL: https://issues.apache.org/jira/browse/SOLR-8355
> Project: Solr
>  Issue Type: Bug
>  Components: security
>Affects Versions: 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Noble Paul
>Priority: Blocker
>  Labels: authorization-plugin
> Fix For: 5.4
>
> Attachments: SOLR-8355.patch
>
>
> Here are the steps that recreate this issue. I tried this on Solr 5.4 and I 
> had the following stack trace when I issued an ADDREPLICA. This seems pretty 
> similar to what we saw on SOLR-8326 so it might be just something we missed 
> but we should make sure that we ship 5.4 with this fixed.
> #Upload Security Conf
> server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd putfile 
> /security.json ~/security.json
> #Start Solr
> bin/solr start -e cloud -z localhost:2181
> #Collection Admin Edit Command:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : 
> {"name":"collection-admin-edit", "role":"admin"}}'
> #Read User and permission:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : {"name":"read", 
> "role":"read"}}'
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : {"name":"update", 
> "role":"update"]}}'
> #Add Users
> #Read User
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
> 'Content-type:application/json' -d '{"set-user" : {"solrread":"solrRocks"}}'
> #Update user
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
> 'Content-type:application/json' -d '{"set-user" : {"solrupdate":"solrRocks"}}'
> #Set user roles
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-user-role" : 
> {"solrupdate":["read","update"]}}'
> #Read User
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-user-role" : {"solrread":["read"]}}'
> #Create collection
> curl --user solr:SolrRocks 
> 'http://localhost:8983/solr/admin/collections?action=CREATE=a=1=1=gettingstarted=json'
> #Add Replica
> curl --user solr:SolrRocks 
> 'http://localhost:8983/solr/admin/collections?action=ADDREPLICA=a=shard1=json'
> Exception log:
> INFO  - 2015-12-01 04:57:47.022; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.cloud.RecoveryStrategy; Starting 
> Replication Recovery.
> INFO  - 2015-12-01 04:57:47.023; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.cloud.RecoveryStrategy; Attempting to 
> replicate from http://172.20.10.4:7574/solr/a_shard1_replica1/.
> ERROR - 2015-12-01 04:57:47.027; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.common.SolrException; Error while trying 
> to 
> recover:org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
> Error from server at http://172.20.10.4:7574/solr/a_shard1_replica1: Expected 
> mime type application/octet-stream but got text/html. 
> 
> 
> Error 401 Unauthorized request, Response code: 401
> 
> HTTP ERROR 401
> Problem accessing /solr/a_shard1_replica1/update. Reason:
> Unauthorized request, Response code: 
> 401Powered by Jetty://
> 
> 
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:167)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.commitOnLeader(RecoveryStrategy.java:205)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.replicate(RecoveryStrategy.java:145)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:436)
>   at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:225)
> INFO  - 2015-12-01 04:57:47.028; [c:a s:shard1 r:core_node2 
> 

[jira] [Commented] (SOLR-8175) Wordbreak spellchecker throws IOOBE with Occur.MUST term

[ASF subversion and git services (JIRA)]

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

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

Commit 1717496 from jd...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1717496 ]

SOLR-8175: fix AIOOBE w/WordBreakSolrSpellChecker

> Wordbreak spellchecker throws IOOBE with Occur.MUST term
> 
>
> Key: SOLR-8175
> URL: https://issues.apache.org/jira/browse/SOLR-8175
> Project: Solr
>  Issue Type: Bug
>Reporter: Ryan Josal
>Assignee: James Dyer
> Attachments: SOLR-8175.patch, solr8175.patch
>
>
> Using the WordBreakSolrSpellChecker, if a user queries for "+foo barbaz" and 
> "bar baz" is a suggestion for "barbaz", Solr will throw an 
> IndexOutOfBoundsException.  As a result, a server driven by user queries 
> might throw a certain percentage of HTTP 500 responses as users hit this.



--
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-8344) Decide default when requested fields are both column and row stored.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8344:
--

[~ichattopadhyaya] I think it'd solve the use-case. and I'm +1 on adding 
stored().

I'm also concerned with the upgrade case though. If someone takes their 5x 
schema and app (and I'm assuming all this is 6.0 at the earliest) and does 
nothing to their schema or app, I'd like them to see no change. If we require 
them to use stored() to pull the stored value explicitly, the app needs to 
change or the users will be surprised.

Which is why I kinda like the stored=docvalues option. It would mean that they 
get the same behavior they see now if they do nothing, but the option of doing 
things the new way without re-indexing.

Hmmm, I like _also_ adding the stored() option. That would allow someone to 
take an existing schema/index/app, add stored=docvalues option (for fields that 
are _already_ DV fields) and _still_ get the raw stored value if they want.

Hm2. the more I think about it, the more I think that it's probably better 
to have something like a new option. Rather than stored=docvalues, something 
like defaultStoredReturn=docvalues|stored. That would allow an _existing_ index 
with a DV field to have the maximum flexibility. Plus it would allow a single 
field definition to serve all the use cases. My original idea of 
stored=docvalues wouldn't put anything in the fdt files when indexing, so a 
stored() operation wouldn't work on a new index.

Hm3. Maybe I'm worrying too much about flexibility. We already have enough 
trouble explaining the nuances of stored/indexed/docValues. Adding 
defaultStoredReturn to the mix makes it _really_ ugly. Just using 
stored=docvalues allows people to make a decision, and the back-compat story is 
simple. "To take advantage of these efficiencies, you may have to reindex if 
you care about the edge case of floats/doubles/ints/longs (and maybe dates)".

> Decide default when requested fields are both column and row stored.
> 
>
> Key: SOLR-8344
> URL: https://issues.apache.org/jira/browse/SOLR-8344
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>
> This issue was discussed in the comments at SOLR-8220. Splitting it out to a 
> separate issue so that we can have a focused discussion on whether/how to do 
> this.
> If a given set of requested fields are all stored and have docValues (column 
> stored), we can retrieve the values from either place.  What should the 
> default be?



--
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-8180) Missing logging dependency in solrj-lib for SolrJ

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-8180.

Resolution: Fixed

> Missing logging dependency in solrj-lib for SolrJ
> -
>
> Key: SOLR-8180
> URL: https://issues.apache.org/jira/browse/SOLR-8180
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>Assignee: David Smiley
> Fix For: 5.4
>
> Attachments: SOLR-8180.patch, SOLR_8180_jcl_over_slf4j.patch, 
> SOLR_8180_jcl_over_slf4j.patch
>
>
> When using DBVisualizer, SquirrelSQL, or Java JDBC with the Solr JDBC driver, 
> an additional logging dependency must be added otherwise the following 
> exception occurs:
> {code}
> org.apache.solr.common.SolrException: Unable to create HttpClient instance. 
>   at 
> org.apache.solr.client.solrj.impl.HttpClientUtil$HttpClientFactory.createHttpClient(HttpClientUtil.java:393)
>   at 
> org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:124)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.(CloudSolrClient.java:196)
>   at 
> org.apache.solr.client.solrj.io.SolrClientCache.getCloudSolrClient(SolrClientCache.java:47)
>   at 
> org.apache.solr.client.solrj.io.sql.ConnectionImpl.(ConnectionImpl.java:51)
>   at 
> org.apache.solr.client.solrj.io.sql.DriverImpl.connect(DriverImpl.java:108)
>   at 
> org.apache.solr.client.solrj.io.sql.DriverImpl.connect(DriverImpl.java:76)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at com.onseven.dbvis.h.B.D.ￄﾁ(Z:1548)
>   at com.onseven.dbvis.h.B.F$A.call(Z:1369)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>   at 
> org.apache.solr.client.solrj.impl.HttpClientUtil$HttpClientFactory.createHttpClient(HttpClientUtil.java:391)
>   ... 16 more
> Caused by: java.lang.NoClassDefFoundError: 
> org/apache/commons/logging/LogFactory
>   at 
> org.apache.http.impl.client.CloseableHttpClient.(CloseableHttpClient.java:58)
>   at 
> org.apache.http.impl.client.AbstractHttpClient.(AbstractHttpClient.java:287)
>   at 
> org.apache.http.impl.client.DefaultHttpClient.(DefaultHttpClient.java:128)
>   at 
> org.apache.http.impl.client.SystemDefaultHttpClient.(SystemDefaultHttpClient.java:116)
>   ... 21 more
> {code} 



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

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

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1618: POMs out of sync

[Shalin Shekhar Mangar]

I'll fix this. Why does ant nightly-smoke not catch this?

On Wed, Dec 2, 2015 at 12:06 AM, Apache Jenkins Server
 wrote:
> Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1618/
>
> No tests ran.
>
> Build Log:
> [...truncated 36891 lines...]
> -validate-maven-dependencies:
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-test-framework:6.0.0-SNAPSHOT: checking for updates 
> from maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-test-framework:6.0.0-SNAPSHOT: checking for updates 
> from releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
> sonatype.releases
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
> maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
> releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-analyzers-common:6.0.0-SNAPSHOT: checking for 
> updates from maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-analyzers-common:6.0.0-SNAPSHOT: checking for 
> updates from releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-analyzers-kuromoji:6.0.0-SNAPSHOT: checking for 
> updates from maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-analyzers-kuromoji:6.0.0-SNAPSHOT: checking for 
> updates from releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-analyzers-phonetic:6.0.0-SNAPSHOT: checking for 
> updates from maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-analyzers-phonetic:6.0.0-SNAPSHOT: checking for 
> updates from releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-backward-codecs:6.0.0-SNAPSHOT: checking for updates 
> from maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-backward-codecs:6.0.0-SNAPSHOT: checking for updates 
> from releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-codecs:6.0.0-SNAPSHOT: checking for updates from 
> maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-codecs:6.0.0-SNAPSHOT: checking for updates from 
> releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-core:6.0.0-SNAPSHOT: checking for updates from 
> maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-core:6.0.0-SNAPSHOT: checking for updates from 
> releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-expressions:6.0.0-SNAPSHOT: checking for updates 
> from maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-expressions:6.0.0-SNAPSHOT: checking for updates 
> from releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-grouping:6.0.0-SNAPSHOT: checking for updates from 
> maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-grouping:6.0.0-SNAPSHOT: checking for updates from 
> releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-highlighter:6.0.0-SNAPSHOT: checking for updates 
> from maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-highlighter:6.0.0-SNAPSHOT: checking for updates 
> from releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-join:6.0.0-SNAPSHOT: checking for updates from 
> maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-join:6.0.0-SNAPSHOT: checking for updates from 
> releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-memory:6.0.0-SNAPSHOT: checking for updates from 
> maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-memory:6.0.0-SNAPSHOT: checking for updates from 
> releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-misc:6.0.0-SNAPSHOT: checking for updates from 
> maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-misc:6.0.0-SNAPSHOT: checking for updates from 
> releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-queries:6.0.0-SNAPSHOT: checking for updates from 
> maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-queries:6.0.0-SNAPSHOT: checking for updates from 
> releases.cloudera.com
> [artifact:dependencies] [INFO] snapshot 
> org.apache.lucene:lucene-queryparser:6.0.0-SNAPSHOT: checking for updates 
> from maven-restlet
> [artifact:dependencies] [INFO] snapshot 
> 

Re: 5.4 branch created, feature freeze in place (was Re: A 5.4 release?)

[Upayavira]

Thx, I hope to create the first RC tomorrow.

On Tue, Dec 1, 2015, at 06:36 PM, Noble Paul wrote:
> I'm done with SOLR-8355
> 
> On Tue, Dec 1, 2015 at 4:24 PM, Noble Paul  wrote:
> > hi Upayavira,
> > sorry for the trouble. There is another blocker created
> > https://issues.apache.org/jira/browse/SOLR-8355
> > I'm fixing that
> >
> > On Mon, Nov 30, 2015 at 8:26 PM, Christine Poerschke (BLOOMBERG/
> > LONDON)  wrote:
> >> Fair point, I have re-worded the ticket title and summary. Will await
> >> further opinions before applying or not applying the patch to 5.4 branch
> >> (and trunk and branch_5x).
> >>
> >> Christine
> >>
> >> From: dev@lucene.apache.org At: Nov 30 2015 14:29:58
> >> To: dev@lucene.apache.org
> >> Subject: Re: 5.4 branch created, feature freeze in place (was Re: A 5.4
> >> release?)
> >>
> >> The patch seems innocuous enough. From the ticket though it isn't so clear
> >> to me what problem it solves. I'm open to the opinion of others.
> >>
> >> Upayavira
> >>
> >> On Mon, Nov 30, 2015, at 12:09 PM, Christine Poerschke (BLOOMBERG/ LONDON)
> >> wrote:
> >>
> >> Any thoughts on getting the
> >> https://issues.apache.org/jira/browse/LUCENE-6911 fix into 5.4 solr or not?
> >> Basically StandardQueryParser's existing getMultiFields method is a no-op.
> >>
> >> From: dev@lucene.apache.org At: Nov 25 2015 14:11:46
> >> To: dev@lucene.apache.org
> >> Subject: Re:5.4 branch created, feature freeze in place (was Re: A 5.4
> >> release?)
> >>
> >> I have created the lucene_solr_5_4 branch. Please, no new features in this
> >> branch.
> >>
> >> Please update this thread with any changes you propose to make to this
> >> branch. Only JIRA tickets which are a blocker and have fix version 5.4 will
> >> delay a release candidate build.
> >>
> >> Please do review the below - and take any action to clear up these tickets
> >> asap.
> >>
> >> I expect to create the first RC this time next week.
> >>
> >> Thanks!
> >>
> >> Upayavira
> >>
> >> On Wed, Nov 25, 2015, at 02:05 PM, Upayavira wrote:
> >>
> >> I shall shortly create the 5.4 release branch. From this moment, the 
> >> feature
> >> freeze starts.
> >>
> >> Looking through JIRA, I see some 71 tickets assigned to fix version 5.4. I
> >> suspect we won't be able to fix all 71 in one week, so I expect that the
> >> majority will be pushed, after this release, to 5.5.
> >>
> >> Looking for blockers or critical tickets, I see five tickets:
> >>
> >> https://issues.apache.org/jira/browse/SOLR-8326 (Anusham, Noble) blocker
> >>   "Adding read restriction to BasicAuth + RuleBased authorization causes
> >> issue with replication"
> >>
> >>   Anusham/Noble - any thoughts on how to resolve this before the release?
> >>
> >> https://issues.apache.org/jira/browse/SOLR-8035 (Erik) critical
> >>   "Move solr/webapp to solr/server/solr-webapp"
> >>
> >>   This one I know isn't a blocker in any sense.
> >>
> >> https://issues.apache.org/jira/browse/SOLR-7901 (Erik) critical
> >>   "Add tests for bin/post"
> >>
> >>   Again, this one does not seem to be something worthy of holding back a
> >> release
> >>
> >> https://issues.apache.org/jira/browse/LUCENE-6723 (Uwe) critical
> >>   "Date field problems using ExtractingRequestHandler and java 9 (b71)"
> >>
> >>   Uwe, I presume as this relates to Java 9, it isn't a blocker?
> >>
> >> https://issues.apache.org/jira/browse/LUCENE-6722 (Shalin, others), blocker
> >>   "Java 8 as the minimum supported JVM version for branch_5x"
> >>
> >>   Looking at the discussion, there was no consensus here, so I will not
> >> consider this a blocker either.
> >>
> >>   - o -
> >>
> >> So SOLR-8326 and LUCENE-6723 seem to be the ones worthy of attention. 
> >> Anyone
> >> have comments/observations here?
> >>
> >> I will create the branch shortly.
> >>
> >> Upayavira
> >>
> >>
> >>
> >>
> >
> >
> >
> > --
> > -
> > Noble Paul
> 
> 
> 
> -- 
> -
> Noble Paul
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b93) - Build # 15089 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15089/
Java: 64bit/jdk1.9.0-ea-b93 -XX:+UseCompressedOops -XX:+UseSerialGC 
-XX:-CompactStrings

2 tests failed.
FAILED:  
org.apache.solr.client.solrj.embedded.SolrExampleStreamingBinaryTest.testUpdateField

Error Message:
ConcurrentUpdateSolrClient did not report an error

Stack Trace:
java.lang.AssertionError: ConcurrentUpdateSolrClient did not report an error
at 
__randomizedtesting.SeedInfo.seed([9FFA2515E50F62E6:CA898F4125277220]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.client.solrj.SolrExampleTests.testUpdateField(SolrExampleTests.java:1632)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:747)


FAILED:  
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest.testUpdateField

Error Message:
ConcurrentUpdateSolrClient did not report an error

Stack Trace:
java.lang.AssertionError: 

Re: 5.4 branch created, feature freeze in place (was Re: A 5.4 release?)

[david.w.smi...@gmail.com]

SOLR-8180 (jcl-over-slf4j) is there too now, some 30min ago.

On Tue, Dec 1, 2015 at 2:27 PM Upayavira  wrote:

> Thx, I hope to create the first RC tomorrow.
>
> On Tue, Dec 1, 2015, at 06:36 PM, Noble Paul wrote:
> > I'm done with SOLR-8355
> >
> > On Tue, Dec 1, 2015 at 4:24 PM, Noble Paul  wrote:
> > > hi Upayavira,
> > > sorry for the trouble. There is another blocker created
> > > https://issues.apache.org/jira/browse/SOLR-8355
> > > I'm fixing that
> > >
> > > On Mon, Nov 30, 2015 at 8:26 PM, Christine Poerschke (BLOOMBERG/
> > > LONDON)  wrote:
> > >> Fair point, I have re-worded the ticket title and summary. Will await
> > >> further opinions before applying or not applying the patch to 5.4
> branch
> > >> (and trunk and branch_5x).
> > >>
> > >> Christine
> > >>
> > >> From: dev@lucene.apache.org At: Nov 30 2015 14:29:58
> > >> To: dev@lucene.apache.org
> > >> Subject: Re: 5.4 branch created, feature freeze in place (was Re: A
> 5.4
> > >> release?)
> > >>
> > >> The patch seems innocuous enough. From the ticket though it isn't so
> clear
> > >> to me what problem it solves. I'm open to the opinion of others.
> > >>
> > >> Upayavira
> > >>
> > >> On Mon, Nov 30, 2015, at 12:09 PM, Christine Poerschke (BLOOMBERG/
> LONDON)
> > >> wrote:
> > >>
> > >> Any thoughts on getting the
> > >> https://issues.apache.org/jira/browse/LUCENE-6911 fix into 5.4 solr
> or not?
> > >> Basically StandardQueryParser's existing getMultiFields method is a
> no-op.
> > >>
> > >> From: dev@lucene.apache.org At: Nov 25 2015 14:11:46
> > >> To: dev@lucene.apache.org
> > >> Subject: Re:5.4 branch created, feature freeze in place (was Re: A 5.4
> > >> release?)
> > >>
> > >> I have created the lucene_solr_5_4 branch. Please, no new features in
> this
> > >> branch.
> > >>
> > >> Please update this thread with any changes you propose to make to this
> > >> branch. Only JIRA tickets which are a blocker and have fix version
> 5.4 will
> > >> delay a release candidate build.
> > >>
> > >> Please do review the below - and take any action to clear up these
> tickets
> > >> asap.
> > >>
> > >> I expect to create the first RC this time next week.
> > >>
> > >> Thanks!
> > >>
> > >> Upayavira
> > >>
> > >> On Wed, Nov 25, 2015, at 02:05 PM, Upayavira wrote:
> > >>
> > >> I shall shortly create the 5.4 release branch. From this moment, the
> feature
> > >> freeze starts.
> > >>
> > >> Looking through JIRA, I see some 71 tickets assigned to fix version
> 5.4. I
> > >> suspect we won't be able to fix all 71 in one week, so I expect that
> the
> > >> majority will be pushed, after this release, to 5.5.
> > >>
> > >> Looking for blockers or critical tickets, I see five tickets:
> > >>
> > >> https://issues.apache.org/jira/browse/SOLR-8326 (Anusham, Noble)
> blocker
> > >>   "Adding read restriction to BasicAuth + RuleBased authorization
> causes
> > >> issue with replication"
> > >>
> > >>   Anusham/Noble - any thoughts on how to resolve this before the
> release?
> > >>
> > >> https://issues.apache.org/jira/browse/SOLR-8035 (Erik) critical
> > >>   "Move solr/webapp to solr/server/solr-webapp"
> > >>
> > >>   This one I know isn't a blocker in any sense.
> > >>
> > >> https://issues.apache.org/jira/browse/SOLR-7901 (Erik) critical
> > >>   "Add tests for bin/post"
> > >>
> > >>   Again, this one does not seem to be something worthy of holding
> back a
> > >> release
> > >>
> > >> https://issues.apache.org/jira/browse/LUCENE-6723 (Uwe) critical
> > >>   "Date field problems using ExtractingRequestHandler and java 9
> (b71)"
> > >>
> > >>   Uwe, I presume as this relates to Java 9, it isn't a blocker?
> > >>
> > >> https://issues.apache.org/jira/browse/LUCENE-6722 (Shalin, others),
> blocker
> > >>   "Java 8 as the minimum supported JVM version for branch_5x"
> > >>
> > >>   Looking at the discussion, there was no consensus here, so I will
> not
> > >> consider this a blocker either.
> > >>
> > >>   - o -
> > >>
> > >> So SOLR-8326 and LUCENE-6723 seem to be the ones worthy of attention.
> Anyone
> > >> have comments/observations here?
> > >>
> > >> I will create the branch shortly.
> > >>
> > >> Upayavira
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > > --
> > > -
> > > Noble Paul
> >
> >
> >
> > --
> > -
> > Noble Paul
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:

[jira] [Commented] (SOLR-8344) Decide default when requested fields are both column and row stored.

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8344:


bq. I'm also concerned with the upgrade case though. If someone takes their 5x 
schema and app (and I'm assuming all this is 6.0 at the earliest) and does 
nothing to their schema or app, I'd like them to see no change.

The plan from SOLR-8220 was to use the schema version for back compat... 
meaning that if you have unstored docValues fields, they won't suddenly start 
appearing when you do fl=*

> Decide default when requested fields are both column and row stored.
> 
>
> Key: SOLR-8344
> URL: https://issues.apache.org/jira/browse/SOLR-8344
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>
> This issue was discussed in the comments at SOLR-8220. Splitting it out to a 
> separate issue so that we can have a focused discussion on whether/how to do 
> this.
> If a given set of requested fields are all stored and have docValues (column 
> stored), we can retrieve the values from either place.  What should the 
> default be?



--
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-7940) [CollectionAPI] Frequent Cluster Status timeout

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-7940:
-

I think this has been fixed by SOLR-7636?

> [CollectionAPI] Frequent Cluster Status timeout
> ---
>
> Key: SOLR-7940
> URL: https://issues.apache.org/jira/browse/SOLR-7940
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.10.2
> Environment: Ubuntu on Azure
>Reporter: Stephan Lagraulet
>
> Very often we have a timeout when we call 
> http://server2:8080/solr/admin/collections?action=CLUSTERSTATUS=json
> {code}
> {"responseHeader": 
> {"status": 500,
> "QTime": 180100},
> "error": 
> {"msg": "CLUSTERSTATUS the collection time out:180s",
> "trace": "org.apache.solr.common.SolrException: CLUSTERSTATUS the collection 
> time out:180s\n\tat 
> org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:368)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:320)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.handleClusterStatus(CollectionsHandler.java:640)\n\tat
>  
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:220)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:729)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:267)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1338)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:350)\n\tat 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)\n\tat
>  
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)\n\tat
>  
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)\n\tat
>  org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630)\n\tat 
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)\n\tat 
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77)\n\tat
>  
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:606)\n\tat
>  
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46)\n\tat
>  
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603)\n\tat
>  
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538)\n\tat
>  java.lang.Thread.run(Thread.java:745)\n",
> "code": 500}}
> {code}
> The cluster has 3 SolR nodes with 6 small collections replicated on all nodes.
> We were using this api to monitor cluster state but it was failing every 10 
> minutes. We switched by using ZkStateReader in CloudSolrServer and it has 
> been working for a day without problems.
> Is there a kind of deadlock as this call was been made on the three nodes 
> concurrently?



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

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

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

[Policeman Jenkins Server]

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

38 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.CollectionReloadTest

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

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


FAILED:  org.apache.solr.TestDistributedGrouping.test

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:34474/er/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:34474/er/collection1
at 
__randomizedtesting.SeedInfo.seed([937189C765DE6E90:1B25B61DCB220368]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:589)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:896)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:859)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:874)
at 
org.apache.solr.BaseDistributedSearchTestCase.del(BaseDistributedSearchTestCase.java:544)
at 
org.apache.solr.TestDistributedGrouping.test(TestDistributedGrouping.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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:986)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

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

[Apache Jenkins Server]

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

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

Error Message:
Captured an uncaught exception in thread: Thread[id=22727, 
name=zkCallback-553-thread-15, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=22727, name=zkCallback-553-thread-15, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded


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

Error Message:
116 threads leaked from SUITE scope at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest: 1) Thread[id=22487, 
name=searcherExecutor-3572-thread-1, state=WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)2) Thread[id=19958, 
name=qtp129174011-19958-selector-ServerConnectorManager@9c681d/1, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at 
sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at 
sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at 
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:102) at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:600)
 at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:549)
 at 
org.eclipse.jetty.util.thread.NonBlockingThread.run(NonBlockingThread.java:52)  
   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)3) Thread[id=20335, 
name=searcherExecutor-1760-thread-1, state=WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)4) Thread[id=19965, 
name=Scheduler-1630664890, state=TIMED_WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)5) Thread[id=19981, 
name=searcherExecutor-1498-thread-1, state=WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068) 

[jira] [Commented] (LUCENE-6911) StandardQueryParser's getMultiFields(CharSequence[] fields) method is a no-op

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-6911: remove deprecated, no-op 
StandardQueryParser.getMultiFields(CharSequence[] fields) method.

> StandardQueryParser's getMultiFields(CharSequence[] fields) method is a no-op
> -
>
> Key: LUCENE-6911
> URL: https://issues.apache.org/jira/browse/LUCENE-6911
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6911.patch
>
>
> problem summary:
> * 
> {{lucene.queryparser.flexible.standard.StandardQueryParser.getMultiFields(CharSequence[]
>  fields)}} is a no-op
> details:
> * https://scan.coverity.com/projects/5620 mentioned on the dev mailing list 
> (http://mail-archives.apache.org/mod_mbox/lucene-dev/201507.mbox/%3ccaftwexg51-jm_6mdeoz1reagn3xgkbetoz5ou_f+melboo1...@mail.gmail.com%3e)
>  in July 2015:
> ** coverity CID 120698



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

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

[jira] [Commented] (LUCENE-6911) StandardQueryParser's getMultiFields(CharSequence[] fields) method is a no-op

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on LUCENE-6911:
-

Done. Yes, someone calling the no-op method seems unlikely. Was just trying to 
get a sense of how deprecating and removal of methods works generally. Thanks 
for the guidance.

> StandardQueryParser's getMultiFields(CharSequence[] fields) method is a no-op
> -
>
> Key: LUCENE-6911
> URL: https://issues.apache.org/jira/browse/LUCENE-6911
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6911.patch
>
>
> problem summary:
> * 
> {{lucene.queryparser.flexible.standard.StandardQueryParser.getMultiFields(CharSequence[]
>  fields)}} is a no-op
> details:
> * https://scan.coverity.com/projects/5620 mentioned on the dev mailing list 
> (http://mail-archives.apache.org/mod_mbox/lucene-dev/201507.mbox/%3ccaftwexg51-jm_6mdeoz1reagn3xgkbetoz5ou_f+melboo1...@mail.gmail.com%3e)
>  in July 2015:
> ** coverity CID 120698



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

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

[jira] [Resolved] (LUCENE-6911) StandardQueryParser's getMultiFields(CharSequence[] fields) method is a no-op

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved LUCENE-6911.
-
Resolution: Fixed

[~mkhludnev] and [~dsmiley] - thanks for your input on LUCENE-6910 and this 
ticket LUCENE-6911 here.
[~rmp91] - thanks for running the Coverity Scan analysis and sharing the 
findings on the dev mailing list.

> StandardQueryParser's getMultiFields(CharSequence[] fields) method is a no-op
> -
>
> Key: LUCENE-6911
> URL: https://issues.apache.org/jira/browse/LUCENE-6911
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6911.patch
>
>
> problem summary:
> * 
> {{lucene.queryparser.flexible.standard.StandardQueryParser.getMultiFields(CharSequence[]
>  fields)}} is a no-op
> details:
> * https://scan.coverity.com/projects/5620 mentioned on the dev mailing list 
> (http://mail-archives.apache.org/mod_mbox/lucene-dev/201507.mbox/%3ccaftwexg51-jm_6mdeoz1reagn3xgkbetoz5ou_f+melboo1...@mail.gmail.com%3e)
>  in July 2015:
> ** coverity CID 120698



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

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

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.solr.client.solrj.embedded.SolrExampleStreamingBinaryTest.testUpdateField

Error Message:
ConcurrentUpdateSolrClient did not report an error

Stack Trace:
java.lang.AssertionError: ConcurrentUpdateSolrClient did not report an error
at 
__randomizedtesting.SeedInfo.seed([A50BCF04EA43155E:F07865502A6B0598]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.client.solrj.SolrExampleTests.testUpdateField(SolrExampleTests.java:1632)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest.testUpdateField

Error Message:
ConcurrentUpdateSolrClient did not report an error

Stack Trace:
java.lang.AssertionError: ConcurrentUpdateSolrClient did 

[jira] [Commented] (SOLR-8330) Restrict logger visibility throughout the codebase to private so that only the file that declares it can use it

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8330:
-

The attached patch no longer applies cleanly. You have to "svn update" to 
revision 1717026. Then it works and compiles, but updating then to trunk again 
leads to conflicts and compile errors. It looks like this patch has so many 
changes so it should be applied ASAP.

[~gchanan]'s fix for SolrCore should be applied, too.

> Restrict logger visibility throughout the codebase to private so that only 
> the file that declares it can use it
> ---
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>  Labels: logging
> Fix For: Trunk
>
> Attachments: SOLR-8330-combined.patch, SOLR-8330-detector.patch, 
> SOLR-8330-detector.patch, SOLR-8330.patch, SOLR-8330.patch, SOLR-8330.patch, 
> SOLR-8330.patch, SOLR-8330.patch
>
>
> As Mike Drob pointed out in Solr-8324, many loggers in Solr are 
> unintentionally shared between classes.  Many instances of this are caused by 
> overzealous copy-paste.  This can make debugging tougher, as messages appear 
> to come from an incorrect location.
> As discussed in the comments on SOLR-8324, there also might be legitimate 
> reasons for sharing loggers between classes.  Where any ambiguity exists, 
> these instances shouldn't be touched.



--
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-8355) RuleBasedAuthenticationPlugin doesn't work with update permission enabled

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8355:
--

Nailed the issue, {{RecoveryStrategy}} creates its own httpclient. So it does 
not send the PKI Authentication Headers. So, the request is not authorized at 
the leader.



> RuleBasedAuthenticationPlugin doesn't work with update permission enabled
> -
>
> Key: SOLR-8355
> URL: https://issues.apache.org/jira/browse/SOLR-8355
> Project: Solr
>  Issue Type: Bug
>  Components: security
>Affects Versions: 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Noble Paul
>Priority: Blocker
>  Labels: authorization-plugin
> Fix For: 5.4
>
>
> Here are the steps that recreate this issue. I tried this on Solr 5.4 and I 
> had the following stack trace when I issued an ADDREPLICA. This seems pretty 
> similar to what we saw on SOLR-8326 so it might be just something we missed 
> but we should make sure that we ship 5.4 with this fixed.
> #Upload Security Conf
> server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd putfile 
> /security.json ~/security.json
> #Start Solr
> bin/solr start -e cloud -z localhost:2181
> #Collection Admin Edit Command:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : 
> {"name":"collection-admin-edit", "role":"admin"}}'
> #Read User and permission:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : {"name":"read", 
> "role":"read"}}'
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : {"name":"update", 
> "role":"update"]}}'
> #Add Users
> #Read User
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
> 'Content-type:application/json' -d '{"set-user" : {"solrread":"solrRocks"}}'
> #Update user
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
> 'Content-type:application/json' -d '{"set-user" : {"solrupdate":"solrRocks"}}'
> #Set user roles
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-user-role" : 
> {"solrupdate":["read","update"]}}'
> #Read User
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-user-role" : {"solrread":["read"]}}'
> #Create collection
> curl --user solr:SolrRocks 
> 'http://localhost:8983/solr/admin/collections?action=CREATE=a=1=1=gettingstarted=json'
> #Add Replica
> curl --user solr:SolrRocks 
> 'http://localhost:8983/solr/admin/collections?action=ADDREPLICA=a=shard1=json'
> Exception log:
> INFO  - 2015-12-01 04:57:47.022; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.cloud.RecoveryStrategy; Starting 
> Replication Recovery.
> INFO  - 2015-12-01 04:57:47.023; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.cloud.RecoveryStrategy; Attempting to 
> replicate from http://172.20.10.4:7574/solr/a_shard1_replica1/.
> ERROR - 2015-12-01 04:57:47.027; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.common.SolrException; Error while trying 
> to 
> recover:org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: 
> Error from server at http://172.20.10.4:7574/solr/a_shard1_replica1: Expected 
> mime type application/octet-stream but got text/html. 
> 
> 
> Error 401 Unauthorized request, Response code: 401
> 
> HTTP ERROR 401
> Problem accessing /solr/a_shard1_replica1/update. Reason:
> Unauthorized request, Response code: 
> 401Powered by Jetty://
> 
> 
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:167)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.commitOnLeader(RecoveryStrategy.java:205)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.replicate(RecoveryStrategy.java:145)
>   at 
> org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:436)
>   at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:225)
> INFO  - 2015-12-01 04:57:47.028; [c:a s:shard1 r:core_node2 
> x:a_shard1_replica2] org.apache.solr.update.UpdateLog; Dropping buffered 
> updates 

Re: 5.4 branch created, feature freeze in place (was Re: A 5.4 release?)

[Noble Paul]

hi Upayavira,
sorry for the trouble. There is another blocker created
https://issues.apache.org/jira/browse/SOLR-8355
I'm fixing that

On Mon, Nov 30, 2015 at 8:26 PM, Christine Poerschke (BLOOMBERG/
LONDON)  wrote:
> Fair point, I have re-worded the ticket title and summary. Will await
> further opinions before applying or not applying the patch to 5.4 branch
> (and trunk and branch_5x).
>
> Christine
>
> From: dev@lucene.apache.org At: Nov 30 2015 14:29:58
> To: dev@lucene.apache.org
> Subject: Re: 5.4 branch created, feature freeze in place (was Re: A 5.4
> release?)
>
> The patch seems innocuous enough. From the ticket though it isn't so clear
> to me what problem it solves. I'm open to the opinion of others.
>
> Upayavira
>
> On Mon, Nov 30, 2015, at 12:09 PM, Christine Poerschke (BLOOMBERG/ LONDON)
> wrote:
>
> Any thoughts on getting the
> https://issues.apache.org/jira/browse/LUCENE-6911 fix into 5.4 solr or not?
> Basically StandardQueryParser's existing getMultiFields method is a no-op.
>
> From: dev@lucene.apache.org At: Nov 25 2015 14:11:46
> To: dev@lucene.apache.org
> Subject: Re:5.4 branch created, feature freeze in place (was Re: A 5.4
> release?)
>
> I have created the lucene_solr_5_4 branch. Please, no new features in this
> branch.
>
> Please update this thread with any changes you propose to make to this
> branch. Only JIRA tickets which are a blocker and have fix version 5.4 will
> delay a release candidate build.
>
> Please do review the below - and take any action to clear up these tickets
> asap.
>
> I expect to create the first RC this time next week.
>
> Thanks!
>
> Upayavira
>
> On Wed, Nov 25, 2015, at 02:05 PM, Upayavira wrote:
>
> I shall shortly create the 5.4 release branch. From this moment, the feature
> freeze starts.
>
> Looking through JIRA, I see some 71 tickets assigned to fix version 5.4. I
> suspect we won't be able to fix all 71 in one week, so I expect that the
> majority will be pushed, after this release, to 5.5.
>
> Looking for blockers or critical tickets, I see five tickets:
>
> https://issues.apache.org/jira/browse/SOLR-8326 (Anusham, Noble) blocker
>   "Adding read restriction to BasicAuth + RuleBased authorization causes
> issue with replication"
>
>   Anusham/Noble - any thoughts on how to resolve this before the release?
>
> https://issues.apache.org/jira/browse/SOLR-8035 (Erik) critical
>   "Move solr/webapp to solr/server/solr-webapp"
>
>   This one I know isn't a blocker in any sense.
>
> https://issues.apache.org/jira/browse/SOLR-7901 (Erik) critical
>   "Add tests for bin/post"
>
>   Again, this one does not seem to be something worthy of holding back a
> release
>
> https://issues.apache.org/jira/browse/LUCENE-6723 (Uwe) critical
>   "Date field problems using ExtractingRequestHandler and java 9 (b71)"
>
>   Uwe, I presume as this relates to Java 9, it isn't a blocker?
>
> https://issues.apache.org/jira/browse/LUCENE-6722 (Shalin, others), blocker
>   "Java 8 as the minimum supported JVM version for branch_5x"
>
>   Looking at the discussion, there was no consensus here, so I will not
> consider this a blocker either.
>
>   - o -
>
> So SOLR-8326 and LUCENE-6723 seem to be the ones worthy of attention. Anyone
> have comments/observations here?
>
> I will create the branch shortly.
>
> Upayavira
>
>
>
>



-- 
-
Noble Paul

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

[jira] [Updated] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-5944:
---
Attachment: SOLR-5944.patch

Updating patch, depends on SOLR-8220.
If waiting for pending/reordered dependent update fails, it tries to get the 
updates from the leader now (as per point 2 in above comment). Fixed a few 
nocommits.
Still need to add the extensive stress tests, and maybe some more refactoring 
needed.

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
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-7339) Upgrade Jetty from 9.2 to 9.3

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-7339:
-

There's still a curious failure in 
SolrExampleStreamingBinaryTest.testUpdateField which runs into connection reset 
errors with the new jetty and I'm not sure why.

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 6.0
>
> Attachments: SOLR-7339.patch, SOLR-7339.patch
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
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-8220) Read field from docValues for non stored fields

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8220:


bq. It sounds like you are arguing for a common way to access docvalues and 
stored fields using the 'fl' parameter. I'm +1 to that.

Ah, ok... I mis-read your previous comment of "i.e. keep this issue focused on 
adding syntactic sugar to read field from doc values for non-stored fields" as 
advocating for new syntax for "fl" to load from non-stored docValue fields.

bq. Let's discuss this optimization in SOLR-8344 and keep the two issues 
separate.

I didn't really see it as separate (it depends on how you look at it),  I see 
it more as, we have a new feature that treats docValues as "column-stored".  
What should the default behavior be when all requested fields are both 
column-stored and row-stored? I think we can make progress + commit this issue 
separately, but should still come at SOLR-8344 "fresh" (i.e. not put the burden 
of proof on one default more than the other).


> Read field from docValues for non stored fields
> ---
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, 
> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>-- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



--
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-8330) Restrict logger visibility throughout the codebase to private so that only the file that declares it can use it

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-8330:
---

Tests passed for me, so I _think_ this patch should be looking good.

> Restrict logger visibility throughout the codebase to private so that only 
> the file that declares it can use it
> ---
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>  Labels: logging
> Fix For: Trunk
>
> Attachments: SOLR-8330-combined.patch, SOLR-8330-detector.patch, 
> SOLR-8330-detector.patch, SOLR-8330.patch, SOLR-8330.patch, SOLR-8330.patch, 
> SOLR-8330.patch, SOLR-8330.patch, SOLR-8330.patch
>
>
> As Mike Drob pointed out in Solr-8324, many loggers in Solr are 
> unintentionally shared between classes.  Many instances of this are caused by 
> overzealous copy-paste.  This can make debugging tougher, as messages appear 
> to come from an incorrect location.
> As discussed in the comments on SOLR-8324, there also might be legitimate 
> reasons for sharing loggers between classes.  Where any ambiguity exists, 
> these instances shouldn't be touched.



--
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-8220) Read field from docValues for non stored fields

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-8220:
-

Agreed. Let's wrap this up. [~ichattopadhyaya] or [~k317h], can one of you put 
up an updated patch? I can review and commit.

> Read field from docValues for non stored fields
> ---
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, 
> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>-- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



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

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

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_66) - Build # 5436 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5436/
Java: 32bit/jdk1.8.0_66 -server -XX:+UseParallelGC

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

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

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50
at __randomizedtesting.SeedInfo.seed([917A8DDFF56889D3]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:449)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:221)
at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


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

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

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestLazyCores: 
   1) Thread[id=10773, name=searcherExecutor-4804-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([917A8DDFF56889D3]:0)


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

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=10773, 

[jira] [Updated] (SOLR-8220) Read field from docValues for non stored fields

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-8220:
---
Attachment: SOLR-8220.patch

Updating the patch.
# Only tackles non-stored docvalues.
# Depends on the refactoring performed at SOLR-8339.

> Read field from docValues for non stored fields
> ---
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, 
> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>-- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



--
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-8220) Read field from docValues for non stored fields

[Keith Laban (JIRA)]

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

Keith Laban commented on SOLR-8220:
---

I found some issues with the way this patch works and have some updated tests 
in separate patch which I haven't uploaded, I need to clean it up a bit and can 
submit it tonight.

One issues I found is that if a document doesn't have a field value for a dv 
field it will get an empty value in the response, we should probably check with 
in the doc value api for docs with field, to make sure that that document had a 
value. 

> Read field from docValues for non stored fields
> ---
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, 
> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>-- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



--
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-8318) SimpleQueryParser doesn't use MultiTermAnalysis for Fuzzy Queries

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8318:
--

Hmmm, I'm a bit puzzled here. The base class SimpleQueryParser already _has_ a 
newFuzzyQuery method that this patch overrides. I'm out of my familiarity with 
the code, so my question is whether we should override this method in the 
plugin or is the real problem in the base class' implementation of 
newFuzzyQuery?

The tests in this patch certainly fail with the new overridden method commented 
out though I put some debugging in and the superclass' method is never 
called in our regular tests so maybe this is really straight bug with 
SimpleQueryParser?


> SimpleQueryParser doesn't use MultiTermAnalysis for Fuzzy Queries
> -
>
> Key: SOLR-8318
> URL: https://issues.apache.org/jira/browse/SOLR-8318
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 5.3
>Reporter: Tom Hill
>Assignee: Erick Erickson
>Priority: Trivial
> Attachments: sqp_fuzzy_multiterm.patch
>
>
> Fuzzy queries in SimpleQParserPlugin don't seem to use the multi-term 
> analysis chain. Prefix queries do, and SolrQueryParser does use multi-term 
> analysis for fuzzy queries, so it seems like SimpleQParserPlugin should as 
> well.



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b93) - Build # 15088 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15088/
Java: 32bit/jdk1.9.0-ea-b93 -client -XX:+UseParallelGC -XX:-CompactStrings

2 tests failed.
FAILED:  
org.apache.solr.client.solrj.embedded.SolrExampleStreamingBinaryTest.testUpdateField

Error Message:
ConcurrentUpdateSolrClient did not report an error

Stack Trace:
java.lang.AssertionError: ConcurrentUpdateSolrClient did not report an error
at 
__randomizedtesting.SeedInfo.seed([F70CF91674891DC5:A27F5342B4A10D03]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.client.solrj.SolrExampleTests.testUpdateField(SolrExampleTests.java:1632)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:747)


FAILED:  
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest.testUpdateField

Error Message:
ConcurrentUpdateSolrClient did not report an error

Stack Trace:
java.lang.AssertionError: 

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 675 - Failure

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.solr.client.solrj.embedded.SolrExampleStreamingBinaryTest.testUpdateField

Error Message:
ConcurrentUpdateSolrClient did not report an error

Stack Trace:
java.lang.AssertionError: ConcurrentUpdateSolrClient did not report an error
at 
__randomizedtesting.SeedInfo.seed([9B5537F4C8D1F8BA:CE269DA008F9E87C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.client.solrj.SolrExampleTests.testUpdateField(SolrExampleTests.java:1632)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest.testUpdateField

Error Message:
ConcurrentUpdateSolrClient did not report an error

Stack Trace:
java.lang.AssertionError: ConcurrentUpdateSolrClient did not report an error
at 

[jira] [Reopened] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar reopened SOLR-7339:
-

Oops, this broke the tests because Jetty 9.3 removed the GzipFilter 
functionality but didn't actually remove the filter class!

I'll test with the fix that Greg has given in his original patch.

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 6.0
>
> Attachments: SOLR-7339.patch, SOLR-7339.patch
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



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