[GitHub] lucene-solr pull request: WordDelimiterFilter - Don't split words ...

[LucVL]

Github user LucVL commented on the pull request:

https://github.com/apache/lucene-solr/pull/210#issuecomment-158335822
  
There’s good documentation on combining git pull-requests with jira 
issues on the apache wiki (there’s a bot for that)
https://wiki.apache.org/lucene-java/BensonMarguliesGitWorkflow

Basically:

-  Create the JIRA issue first

-  Create the pull request with the JIRA issue in the title. This 
will cause a bot to pick it up and link the two.  A comment will appear in the 
JIRA issue that includes a link to an equivalent patch for non-git users.

-  When the JIRA issue is closed, the committer should include 
“This closes #PP”. This causes the bot to close the PR as well

For an example, see https://issues.apache.org/jira/browse/SOLR-8050

Luc


From: smartprix [mailto:notificati...@github.com]
Sent: donderdag 19 november 2015 15:27
To: apache/lucene-solr
Subject: Re: [lucene-solr] WordDelimiterFilter - Don't split words marked 
as keyword (#210)


The behavior should is now configurable. I have updated the pull request to 
reflect that. A new attribute "splitKeywordTokens" which is false by default 
for lucene >= 6.0 and true otherwise.

Does lucene not accept pull requests from github? Should I create it on 
JIRA?

—
Reply to this email directly or view it on 
GitHub.



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

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

[jira] [Commented] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6905:


bq. Updated patch that moves unwrapping to GeoUtils. 
TestGeoUtils.testGeoRelations is also reenabled and updated for BKD verification

Whoa, wonderful!  I will look at the patch!

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the MBR into 
> east/west ranges and rewriting to a Boolean SHOULD. PostFiltering is 
> accomplished by calculating the distance from the center point to the 
> candidate point field. Unfortunately the center point is wrapped such that 
> calculating the distance from a eastern point to a western MBR provides 
> incorrect results.



--
This message was sent by Atlassian 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-8302) SolrResourceLoader should take a Path to its instance directory, rather than a String

[ASF subversion and git services (JIRA)]

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

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

Commit 1715344 from [~romseygeek] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1715344 ]

SOLR-8302: SolrResourceLoader takes a Path for its instance directory

> SolrResourceLoader should take a Path to its instance directory, rather than 
> a String
> -
>
> Key: SOLR-8302
> URL: https://issues.apache.org/jira/browse/SOLR-8302
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8302.patch, SOLR-8302.patch
>
>
> First step of SOLR-8282.  We have a whole bunch of code that deals with 
> loading things relative to the resource loader's instance dir.  These become 
> a lot simpler if the instance dir is a Path.



--
This message was sent by Atlassian 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-6893) factor out CorePlusQueriesParser from CorePlusExtensionsParser

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-6893: factor out CorePlusQueriesParser from CorePlusExtensionsParser 
(merge in revision 1715343 from trunk)

> factor out CorePlusQueriesParser from CorePlusExtensionsParser
> --
>
> Key: LUCENE-6893
> URL: https://issues.apache.org/jira/browse/LUCENE-6893
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-6893.patch, LUCENE-6893.patch
>
>
> proposed change (patch against trunk to follow):
> before:
>  * {{CorePlusExtensionsParser}} extends {{CoreParser}}
>  * {{CorePlusExtensionsParser}} uses {{(LikeThis|Boosting)QueryBuilder}} 
> which uses {{org.apache.lucene.queries.(BoostingQuery|mlt.MoreLikeThisQuery)}}
>  * {{CorePlusExtensionsParser}} uses {{FuzzyLikeThisQueryBuilder}} which 
> uses {{org.apache.lucene.sandbox.queries.(FuzzyLikeThisQuery|SlowFuzzyQuery)}}
> 
> after:
>  * {{CorePlusQueriesParser}} extends {{CoreParser}}
>  * {{CorePlusQueriesParser}} uses {{(LikeThis|Boosting)QueryBuilder}} 
> which uses {{org.apache.lucene.queries.(BoostingQuery|mlt.MoreLikeThisQuery)}}
>  * {{CorePlusExtensionsParser}} extends {{CorePlusQueriesParser}}
>  * {{CorePlusExtensionsParser}} uses {{FuzzyLikeThisQueryBuilder}} which 
> uses {{org.apache.lucene.sandbox.queries.(FuzzyLikeThisQuery|SlowFuzzyQuery)}}
> 
> motivation:
>  * we wish to use or inherit from a {{CorePlus...Parser}} and use 
> {{org.apache.lucene.queries.\*}} but not pull in any 
> {{org.apache.lucene.sandbox.\*}} code



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

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

[jira] [Updated] (SOLR-5971) 'Illegal character in query' when proxying request

[Ishan Chattopadhyaya (JIRA)]

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

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

bq. Also use the correct constants for UTF-8.
Updated the patch to use {{StandardCharsets.UTF_8.name()}}. There are several 
other instances of the use of "UTF-8" constant. 

Btw, should we change all of those to {{StandardCharsets.UTF_8.name()}} in a 
separate JIRA issue? I've included one such change in this patch, i.e. 
ClientUtils. That method in the ClientUtils is very similar to what we're doing 
here in this patch.

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:662)
> Without the facet.field attribute, it works fine on all the nodes.
> Is this some kind of double escaping when proxying the request?



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

[jira] [Commented] (SOLR-5971) 'Illegal character in query' when proxying request

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-5971:


All tests pass for me after applying this patch (some fail intermittently, and 
seem like unrelated and non-reproducible failures. All the usual culprits from 
Jenkins over past few days.).

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:662)
> Without the facet.field attribute, it works fine on all the nodes.
> Is this some kind of double escaping when proxying the request?



--
This message was sent by Atlassian 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-6893) factor out CorePlusQueriesParser from CorePlusExtensionsParser

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated LUCENE-6893:

Fix Version/s: 5.4
   Trunk

> factor out CorePlusQueriesParser from CorePlusExtensionsParser
> --
>
> Key: LUCENE-6893
> URL: https://issues.apache.org/jira/browse/LUCENE-6893
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6893.patch, LUCENE-6893.patch
>
>
> proposed change (patch against trunk to follow):
> before:
>  * {{CorePlusExtensionsParser}} extends {{CoreParser}}
>  * {{CorePlusExtensionsParser}} uses {{(LikeThis|Boosting)QueryBuilder}} 
> which uses {{org.apache.lucene.queries.(BoostingQuery|mlt.MoreLikeThisQuery)}}
>  * {{CorePlusExtensionsParser}} uses {{FuzzyLikeThisQueryBuilder}} which 
> uses {{org.apache.lucene.sandbox.queries.(FuzzyLikeThisQuery|SlowFuzzyQuery)}}
> 
> after:
>  * {{CorePlusQueriesParser}} extends {{CoreParser}}
>  * {{CorePlusQueriesParser}} uses {{(LikeThis|Boosting)QueryBuilder}} 
> which uses {{org.apache.lucene.queries.(BoostingQuery|mlt.MoreLikeThisQuery)}}
>  * {{CorePlusExtensionsParser}} extends {{CorePlusQueriesParser}}
>  * {{CorePlusExtensionsParser}} uses {{FuzzyLikeThisQueryBuilder}} which 
> uses {{org.apache.lucene.sandbox.queries.(FuzzyLikeThisQuery|SlowFuzzyQuery)}}
> 
> motivation:
>  * we wish to use or inherit from a {{CorePlus...Parser}} and use 
> {{org.apache.lucene.queries.\*}} but not pull in any 
> {{org.apache.lucene.sandbox.\*}} 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-5971) 'Illegal character in query' when proxying request

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-5971:


Shall we mark this as a blocker for 5.4 instead of 5.5?

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:662)
> Without the facet.field attribute, it works fine on all the nodes.
> Is this some kind of double escaping when proxying the request?



--
This message was sent by Atlassian 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-7169) init.d status command has incorrect return value

[Dominik Siebel (JIRA)]

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

Dominik Siebel commented on SOLR-7169:
--

Experiencing the same problem with orchestration via Saltstack currently.

> init.d status command has incorrect return value
> 
>
> Key: SOLR-7169
> URL: https://issues.apache.org/jira/browse/SOLR-7169
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.0
> Environment: Debian stable
>Reporter: Martin Skøtt
>Assignee: Timothy Potter
>
> {{/etc/init.d/solr status}} returns 0 if Solr is not running, but according 
> to the LSB 0 means that the service is running 
> (http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html).
> In my situation this causes problems when managing the service with Puppet 
> which uses the status command to determine if a service should be started. 
> Puppet simply doesn't start the service because it thinks its already 
> running. Any other script depending on the result of the status command will 
> suffer similar problems.
> Workaround for other Puppet users:
> Setting {{hasstatus => false}} and {{pattern => "solr.solr.home"}} in the 
> service definition works for me.



--
This message was sent by Atlassian 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-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 updated SOLR-8321:
--
Attachment: SOLR-8321.patch

> 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] (LUCENE-6904) Rewrite max bound GeoPointInBBoxQuery to FieldValueQuery

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6904:


+1, except maybe add a comment where you use {{FieldValueQuery}} explaining 
that we can do this because we index the lat/lon into doc values?

> Rewrite max bound GeoPointInBBoxQuery to FieldValueQuery
> 
>
> Key: LUCENE-6904
> URL: https://issues.apache.org/jira/browse/LUCENE-6904
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: Trunk, 5.4
>Reporter: Nicholas Knize
>Priority: Minor
> Attachments: LUCENE-6904.patch, LUCENE-6904.patch
>
>
> This simple improvement rewrites a GeoPointInBBoxQuery to a FieldValueQuery 
> when the min/max lon/lat (or x/y) values are set to their limits (e.g., -180, 
> 180, -90, 90). This bypasses all unnecessary GeoPointTermsEnum logic.



--
This message was sent by Atlassian 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-8302) SolrResourceLoader should take a Path to its instance directory, rather than a String

[Alan Woodward (JIRA)]

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

Alan Woodward resolved SOLR-8302.
-
   Resolution: Fixed
Fix Version/s: Trunk
   5.4

Thanks for the review Shawn

> SolrResourceLoader should take a Path to its instance directory, rather than 
> a String
> -
>
> Key: SOLR-8302
> URL: https://issues.apache.org/jira/browse/SOLR-8302
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8302.patch, SOLR-8302.patch
>
>
> First step of SOLR-8282.  We have a whole bunch of code that deals with 
> loading things relative to the resource loader's instance dir.  These become 
> a lot simpler if the instance dir is a Path.



--
This message was sent by Atlassian 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-8298) small preferLocalShards implementation refactor

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-8298.
---
   Resolution: Fixed
Fix Version/s: Trunk
   5.4

> small preferLocalShards implementation refactor
> ---
>
> Key: SOLR-8298
> URL: https://issues.apache.org/jira/browse/SOLR-8298
> Project: Solr
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8298.patch
>
>
> Towards rebasing the SOLR-6730 patch after SOLR-6832 and other changes - 
> proposed patch against trunk to follow.
> existing calling chain:
>  * {{ResponseBuilder.addRequest(... ShardRequest sreq)}} does {{sreq.rb = 
> this;}} so that later on {{HttpShardHandler.submit(ShardRequest sreq ...)}} 
> can do {{sreq.rb.req.getOriginalParams().getBool}} for 
> {{CommonParams.PREFER_LOCAL_SHARDS}}
> proposed alternative calling chain:
>  * {{HttpShardHandler.prepDistributed(ResponseBuilder rb)}} sets 
> {{rb.preferredHostAddress}} and {{SearchHandler}} calls 
> {{ShardHandler.submit(ShardRequest sreq ... rb.preferredHostAddress)}}
> structural changes:
>  * {{ShardRequest.rb}} member removed in favour of a new 
> {{ResponseBuilder.preferredHostAddress}} member.
>  * {{String preferredHostAddress}} argument added to the abstract 
> {{ShardHandler.submit}} method (and to two derived (test) classes' submit 
> methods also).
>  * {code}public void submit(ShardRequest sreq, String shard, 
> ModifiableSolrParams params) { submit(sreq, shard, params, null); } {code} 
> added to avoid having to change {{ShardHandler.submit}} callers which don't 
> have a concept of preferring a local shard e.g. for PeerSync requests.



--
This message was sent by Atlassian 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-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6905:


For the record, MBR in geo speak means "minimum bounding rectangle" :)

In the {{GeoDistanceUtils.maxRadialDistance}} javadocs can you say that the 
returned results is in meters?

Is this comment in {{GeoUtils.unwrapLon}} stale?

{noformat}
+// if centerLon is within bbox
{noformat}

(I see no {{centerLon}} nor a bbox).

Can you add a javadoc to this method?  Can you add an assert before returning 
that lon is now in-bounds?  (I.e. that the incoming lon did not require more 
than one iteration of unwrapping).   Can you make the {{ += 360}} also a double 
(or make the other one an int)?

OK so the test failures were caused by 1) not having a tolerance for up to 0.5% 
error in the distance, and 2) not handling dateline crossovers correctly, and 
not pole crossing issues?  We should fix this test to "behave" like the query 
does: rewrite up front into the two halves of the MBR, instead of unwrapping on 
each step of the recursion.  But let's do that separately ... can you add a 
TODO?

Can we now remove the {{true}} in {{TestGeoUtils.testGeoRelations}}?:

{noformat}
  // TODO: GeoUtils APIs are still buggy for large distances:
  if (true || useSmallRanges) {
// Approx 3 degrees lon at the equator:
radiusMeters = random().nextDouble() * 333000;
  } else {
radiusMeters = random().nextDouble() * 
GeoProjectionUtils.SEMIMAJOR_AXIS * Math.PI / 2.0;
  }
{noformat}

I.e. we can now test large distances?

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the MBR into 
> east/west ranges and rewriting to a Boolean SHOULD. PostFiltering is 
> accomplished by calculating the distance from the center point to the 
> candidate point field. Unfortunately the center point is wrapped such that 
> calculating the distance from a eastern point to a western MBR provides 
> incorrect results.



--
This message was sent by Atlassian 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-6893) factor out CorePlusQueriesParser from CorePlusExtensionsParser

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-6893: factor out CorePlusQueriesParser from CorePlusExtensionsParser

> factor out CorePlusQueriesParser from CorePlusExtensionsParser
> --
>
> Key: LUCENE-6893
> URL: https://issues.apache.org/jira/browse/LUCENE-6893
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-6893.patch, LUCENE-6893.patch
>
>
> proposed change (patch against trunk to follow):
> before:
>  * {{CorePlusExtensionsParser}} extends {{CoreParser}}
>  * {{CorePlusExtensionsParser}} uses {{(LikeThis|Boosting)QueryBuilder}} 
> which uses {{org.apache.lucene.queries.(BoostingQuery|mlt.MoreLikeThisQuery)}}
>  * {{CorePlusExtensionsParser}} uses {{FuzzyLikeThisQueryBuilder}} which 
> uses {{org.apache.lucene.sandbox.queries.(FuzzyLikeThisQuery|SlowFuzzyQuery)}}
> 
> after:
>  * {{CorePlusQueriesParser}} extends {{CoreParser}}
>  * {{CorePlusQueriesParser}} uses {{(LikeThis|Boosting)QueryBuilder}} 
> which uses {{org.apache.lucene.queries.(BoostingQuery|mlt.MoreLikeThisQuery)}}
>  * {{CorePlusExtensionsParser}} extends {{CorePlusQueriesParser}}
>  * {{CorePlusExtensionsParser}} uses {{FuzzyLikeThisQueryBuilder}} which 
> uses {{org.apache.lucene.sandbox.queries.(FuzzyLikeThisQuery|SlowFuzzyQuery)}}
> 
> motivation:
>  * we wish to use or inherit from a {{CorePlus...Parser}} and use 
> {{org.apache.lucene.queries.\*}} but not pull in any 
> {{org.apache.lucene.sandbox.\*}} 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-8302) SolrResourceLoader should take a Path to its instance directory, rather than a String

[ASF subversion and git services (JIRA)]

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

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

Commit 1715345 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1715345 ]

SOLR-8302: Remove deprecated methods in trunk

> SolrResourceLoader should take a Path to its instance directory, rather than 
> a String
> -
>
> Key: SOLR-8302
> URL: https://issues.apache.org/jira/browse/SOLR-8302
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8302.patch, SOLR-8302.patch
>
>
> First step of SOLR-8282.  We have a whole bunch of code that deals with 
> loading things relative to the resource loader's instance dir.  These become 
> a lot simpler if the instance dir is a Path.



--
This message was sent by Atlassian 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-5971) 'Illegal character in query' when proxying request

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-5971 at 11/20/15 1:04 PM:
--

While performing a remote query at HttpSolrCall, the original query request 
string is passed along as is to the httpclient to make the forward query. The 
problem is (maybe a newly introduced one, due to some HttpClient regression?) 
that httpclient throws exception for urls that contain certain special 
characters like {{^}} or \{ or \}.

Added a patch which recreates another query string by URL encoding every query 
parameter.

The reason why we missed this in our testing is that all our tests use the 
SolrQuery and a SolrClient to make the queries, and that uses url encoding 
internally. For testing this, I couldn't use an httpclient to query with such 
special characters in the url, since httpclient doesn't allow this in the first 
place. Resorted to using a java.net.URL.openStream() with the url containing 
weird characters to test this; added a new test suite altogether as I couldn't 
find out an appropriate test suite that exists right now.

Can someone please review the patch? Thanks.


was (Author: ichattopadhyaya):
While performing a remote query at HttpSolrCall, the original query request 
string is passed along as is to the httpclient to make the forward query. The 
problem is (maybe a newly introduced one, due to some HttpClient regression?) 
that httpclient throws exception for urls that contain certain special 
characters like ^ or { or }.

Added a patch which recreates another query string by URL encoding every query 
parameter.

The reason why we missed this in our testing is that all our tests use the 
SolrQuery and a SolrClient to make the queries, and that uses url encoding 
internally. For testing this, I couldn't use an httpclient to query with such 
special characters in the url, since httpclient doesn't allow this in the first 
place. Resorted to using a java.net.URL.openStream() with the url containing 
weird characters to test this; added a new test suite altogether as I couldn't 
find out an appropriate test suite that exists right now.

Can someone please review the patch? Thanks.

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> 

[jira] [Commented] (LUCENE-6902) Fail fsync immediately

[Daniel Mitterdorfer (JIRA)]

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

Daniel Mitterdorfer commented on LUCENE-6902:
-

Sorry, wasn't aware of that. Thanks for pointing it out.

> Fail fsync immediately
> --
>
> Key: LUCENE-6902
> URL: https://issues.apache.org/jira/browse/LUCENE-6902
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Affects Versions: 5.3.1
>Reporter: Daniel Mitterdorfer
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 5.4
>
> Attachments: ioutils-fsync-fail-fast.patch
>
>
> While analysing a build issue in Elasticsearch I stumpled upon 
> org.apache.lucene.util.IOUtils.fsync. It has a retry loop in fsync whenever 
> an IOException occurs. However, there are lots of instances where a retry is 
> not useful, e.g. when a channel has been closed, a ClosedChannelException is 
> thrown and IOUtils#fsync still tries to fsync multiple times on the closed 
> channel.
> After bringing the issue to Robert's attention, he even opted for removing 
> the retry logic entirely for fsyncing.
> Please find attached a patch that removes the retry logic.



--
This message was sent by Atlassian 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-8302) SolrResourceLoader should take a Path to its instance directory, rather than a String

[ASF subversion and git services (JIRA)]

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

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

Commit 1715342 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1715342 ]

SOLR-8302: SolrResourceLoader takes a Path for its instance directory

> SolrResourceLoader should take a Path to its instance directory, rather than 
> a String
> -
>
> Key: SOLR-8302
> URL: https://issues.apache.org/jira/browse/SOLR-8302
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8302.patch, SOLR-8302.patch
>
>
> First step of SOLR-8282.  We have a whole bunch of code that deals with 
> loading things relative to the resource loader's instance dir.  These become 
> a lot simpler if the instance dir is a Path.



--
This message was sent by Atlassian 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-5971) 'Illegal character in query' when proxying request

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-5971:
-

You must also pass the key name through the encoder! Its unlikely that Solr 
contains key names which violate the spec, but better safe than fail again in 
the future. forms encoding requires that both key and value is encoded. Also 
use the correct constants for UTF-8.

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:662)
> Without the facet.field attribute, it works fine on all the nodes.
> Is this some kind of double escaping when proxying the request?



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

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

[jira] [Created] (SOLR-8321) add a (SolrQueryRequest free) SortSpecParsing.parseSortSpec variant

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-8321:
-

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


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] [Updated] (SOLR-5971) 'Illegal character in query' when proxying request

[Ishan Chattopadhyaya (JIRA)]

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

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

While performing a remote query at HttpSolrCall, the original query request 
string is passed along as is to the httpclient to make the forward query. The 
problem is (maybe a newly introduced one, due to some HttpClient regression?) 
that httpclient throws exception for urls that contain certain special 
characters like ^ or { or }.

Added a patch which recreates another query string by URL encoding every query 
parameter.

The reason why we missed this in our testing is that all our tests use the 
SolrQuery and a SolrClient to make the queries, and that uses url encoding 
internally. For testing this, I couldn't use an httpclient to query with such 
special characters in the url, since httpclient doesn't allow this in the first 
place. Resorted to using a java.net.URL.openStream() with the url containing 
weird characters to test this; added a new test suite altogether as I couldn't 
find out an appropriate test suite that exists right now.

Can someone please review the patch? Thanks.

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> 

[jira] [Updated] (SOLR-5971) 'Illegal character in query' when proxying request

[Ishan Chattopadhyaya (JIRA)]

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

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

Thanks Uwe for looking at it. Encoded the key as well to be safe.
Running the full suite of tests now (it passed for me last time, apart from the 
ones that fail frequently at Jenkins anyway).

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:662)
> Without the facet.field attribute, it works fine on all the nodes.
> Is this some kind of double escaping when proxying the request?



--
This message was sent by Atlassian 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-8050) Partial update on document with multivalued date field fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8050:
--

Github user LucVL commented on the pull request:

https://github.com/apache/lucene-solr/pull/210#issuecomment-158335822
  
There’s good documentation on combining git pull-requests with jira issues 
on the apache wiki (there’s a bot for that)
https://wiki.apache.org/lucene-java/BensonMarguliesGitWorkflow

Basically:

-  Create the JIRA issue first

-  Create the pull request with the JIRA issue in the title. This 
will cause a bot to pick it up and link the two.  A comment will appear in the 
JIRA issue that includes a link to an equivalent patch for non-git users.

-  When the JIRA issue is closed, the committer should include 
“This closes #PP”. This causes the bot to close the PR as well

For an example, see https://issues.apache.org/jira/browse/SOLR-8050

Luc


From: smartprix [mailto:notificati...@github.com]
Sent: donderdag 19 november 2015 15:27
To: apache/lucene-solr
Subject: Re: [lucene-solr] WordDelimiterFilter - Don't split words marked 
as keyword (#210)


The behavior should is now configurable. I have updated the pull request to 
reflect that. A new attribute "splitKeywordTokens" which is false by default 
for lucene >= 6.0 and true otherwise.

Does lucene not accept pull requests from github? Should I create it on 
JIRA?

—
Reply to this email directly or view it on 
GitHub.



> Partial update on document with multivalued date field fails
> 
>
> Key: SOLR-8050
> URL: https://issues.apache.org/jira/browse/SOLR-8050
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java, SolrJ
>Affects Versions: 5.2.1
> Environment: embedded solr
> java 1.7
> win
>Reporter: Burkhard Buelte
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8050.patch, screenshot-1.png
>
>
> When updating a document with multivalued date field Solr throws a exception
> like: org.apache.solr.common.SolrException: Invalid Date String:'Mon Sep 
> 14 01:48:38 CEST 2015'
> even if the update document doesn't contain any datefield.
> See following code snippet to reproduce 
> 1. create a doc with multivalued date field (here dynamic field _dts)
> SolrInputDocument doc = new SolrInputDocument();
> String id = Long.toString(System.currentTimeMillis());
> System.out.println("testUpdate: adding test document to solr ID=" + 
> id);
> doc.addField(CollectionSchema.id.name(), id);
> doc.addField(CollectionSchema.title.name(), "Lorem ipsum");
> doc.addField(CollectionSchema.host_s.name(), "yacy.net");
> doc.addField(CollectionSchema.text_t.name(), "Lorem ipsum dolor sit 
> amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut 
> labore et dolore magna aliqua.");
> doc.addField(CollectionSchema.dates_in_content_dts.name(), new 
> Date());
> solr.add(doc);
> solr.commit(true);
> 2. update any field on this doc via partial update
> SolrInputDocument sid = new SolrInputDocument();
> sid.addField(CollectionSchema.id.name(), 
> doc.getFieldValue(CollectionSchema.id.name()));
> sid.addField(CollectionSchema.host_s.name(), "yacy.yacy");
> solr.update(sid);
> solr.commit(true);
> Result
> Caused by: org.apache.solr.common.SolrException: Invalid Date String:'Mon Sep 
> 14 01:48:38 CEST 2015'
>   at org.apache.solr.util.DateFormatUtil.parseMath(DateFormatUtil.java:87)
>   at 
> org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:473)
>   at org.apache.solr.schema.TrieField.createFields(TrieField.java:715)
>   at 
> org.apache.solr.update.DocumentBuilder.addField(DocumentBuilder.java:48)
>   at 
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:123)
>   at 
> org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:83)
>   at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:237)
>   at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:163)
>   at 
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
>   at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:955)
>   at 
> 

[jira] [Commented] (LUCENE-6902) Fail fsync immediately

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6902:
---

Looks fine! I will check and commit this later.
You can leave the old versions of the patch online, don't delete them! If you 
upload a new version of the same filename, the old one is grayed out, but is 
still accessible for doucmentation purposes.

> Fail fsync immediately
> --
>
> Key: LUCENE-6902
> URL: https://issues.apache.org/jira/browse/LUCENE-6902
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Affects Versions: 5.3.1
>Reporter: Daniel Mitterdorfer
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 5.4
>
> Attachments: ioutils-fsync-fail-fast.patch
>
>
> While analysing a build issue in Elasticsearch I stumpled upon 
> org.apache.lucene.util.IOUtils.fsync. It has a retry loop in fsync whenever 
> an IOException occurs. However, there are lots of instances where a retry is 
> not useful, e.g. when a channel has been closed, a ClosedChannelException is 
> thrown and IOUtils#fsync still tries to fsync multiple times on the closed 
> channel.
> After bringing the issue to Robert's attention, he even opted for removing 
> the retry logic entirely for fsyncing.
> Please find attached a patch that removes the retry logic.



--
This message was sent by Atlassian 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-5971) 'Illegal character in query' when proxying request

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-5971:


We use the {{ClientUtils.toQueryString()}}.

{noformat}
  public static String toQueryString( SolrParams params, boolean xml ) {
StringBuilder sb = new StringBuilder(128);
try {
  String amp = xml ? "" : "&";
  boolean first=true;
  Iterator names = params.getParameterNamesIterator();
  while( names.hasNext() ) {
String key = names.next();
String[] valarr = params.getParams( key );
if( valarr == null ) {
  sb.append( first?"?":amp );
  sb.append(key);
  first=false;
}
else {
  for (String val : valarr) {
sb.append( first? "?":amp );
sb.append(key);
if( val != null ) {
  sb.append('=');
  sb.append( URLEncoder.encode( val, StandardCharsets.UTF_8.name() 
) );
}
first=false;
  }
}
  }
}
catch (IOException e) {throw new RuntimeException(e);}  // can't happen
return sb.toString();
  }
{noformat}

Do you know how to use the HttpClient to build the query string?

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 

[jira] [Created] (SOLR-8322) Solr commitwithin is not happening for deletebyId on solr 4.10.4

[Matteo Grolla (JIRA)]

Matteo Grolla created SOLR-8322:
---

 Summary: Solr commitwithin is not happening for deletebyId on solr 
4.10.4
 Key: SOLR-8322
 URL: https://issues.apache.org/jira/browse/SOLR-8322
 Project: Solr
  Issue Type: Bug
  Components: SolrJ
Affects Versions: 4.6, Trunk
Reporter: Matteo Grolla
 Fix For: 4.10.4, 5.0, Trunk


Hi All,

Just found that solrj doesnot use commitwithin while using deletebyid. This 
issue is discussed in 
http://grokbase.com/t/lucene/solr-user/1275gkpntd/deletebyid-commitwithin-question

Faced the same issue today and found that, in 
org.apache.solr.client.solrj.request.UpdateRequest when new UpdateRequest is 
created in getRoutes() method ( Line number 244 ), the setCommitWithin param is 
not set in the urequest variable as it is done few lines above (Line number 
204) This causes setCommitWithin to revert to default value of -1 and the 
commit does not happen. Tried setting that like,
urequest.setCommitWithin(getCommitWithin()) and the feature is enabled from 
SolrJ.



--
This message was sent by Atlassian 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-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6905:


Also, why didn't our randomized tests (which I think do span the dateline 
sometimes) not tickle this bug?

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the MBR into 
> east/west ranges and rewriting to a Boolean SHOULD. PostFiltering is 
> accomplished by calculating the distance from the center point to the 
> candidate point field. Unfortunately the center point is wrapped such that 
> calculating the distance from a eastern point to a western MBR provides 
> incorrect results.



--
This message was sent by Atlassian 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-5971) 'Illegal character in query' when proxying request

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-5971:
-

OK. So your patch is fine. I am just confused why you put the utility method 
into RequestUtils, which is part of the json package. This seems "wrong" (the 
json package). Otherwise looks fine.

I general I don't think this is a bug in SOLR, it is just "wrong" to accept the 
incoming URL anyways, so Jetty should have refused it already :-) But that is a 
different discussion! We just workaround on broken users violating the UR spec. 
So I am fine with that.

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:662)
> Without the facet.field attribute, it works fine on all the nodes.
> Is this some kind of double escaping when proxying the request?



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

[jira] [Created] (SOLR-8323) Add CollectionWatcher API to ZkStateReader

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-8323:
---

 Summary: Add CollectionWatcher API to ZkStateReader
 Key: SOLR-8323
 URL: https://issues.apache.org/jira/browse/SOLR-8323
 Project: Solr
  Issue Type: Improvement
Affects Versions: Trunk
Reporter: Alan Woodward


An API to watch for changes to collection state would be a generally useful 
thing, both internally and for client use.



--
This message was sent by Atlassian 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-8323) Add CollectionWatcher API to ZkStateReader

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8323:

Attachment: SOLR-8323.patch

Patch outlining the basic idea.

This adds two new interfaces, CollectionStateWatcher and 
CollectionStatePredicate.  The first can be registered for a particular 
collection with ZkStateReader and is called when the state of that collection 
changes (as determined by the internal watcher of that collection's state.json 
node).  The second is used in a new ZkStateReader.waitForState() method, and is 
called on a state change to see if the state of a collection matches a 
predicate.  There are also forwarding methods on CloudSolrClient for use by 
SolrJ clients, and a couple of helper methods on DocCollection and Replica to 
easily check for collection liveness.

The new interfaces lend themselves nicely to use as Java 8 functional 
interfaces, and the TestCollectionStateWatchers test demonstrate both lambdas 
and method references here.

This should make it easy to replace some of the helper methods (eg 
waitForThingsToLevelOut, waitForRecoveriesToFinish) in our tests with methods 
available to SolrJ.

A caveat: this is only implemented for collections with their own state.json.  
I think it should be relatively easy to extend it to stateformat=1 collections 
as well if people think that's worth it.

> Add CollectionWatcher API to ZkStateReader
> --
>
> Key: SOLR-8323
> URL: https://issues.apache.org/jira/browse/SOLR-8323
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Alan Woodward
> Attachments: SOLR-8323.patch
>
>
> An API to watch for changes to collection state would be a generally useful 
> thing, both internally and for client use.



--
This message was sent by Atlassian 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-5971) 'Illegal character in query' when proxying request

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-5971:


I couldn't think of the right place to put this. "RequestUtil" sounded the 
least wrong place to put this in (but the json part seemed bad). I was also 
thinking of ClientUtils (which is in a solrj package). Maybe I should've kept 
it in HttpSolrCall itself.
I'll raise a patch to put this there. Does it sound fine?

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:662)
> Without the facet.field attribute, it works fine on all the nodes.
> Is this some kind of double escaping when proxying the request?



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

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

[jira] [Updated] (SOLR-8322) Solr commitwithin is not happening for deletebyId on solr 4.10.4

[Matteo Grolla (JIRA)]

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

Matteo Grolla updated SOLR-8322:

Description: 
Hi,
I'm using solr 4.10.4 and solrj 4.10.4 and when issuing a deleteById with a 
commitWithin I observe that the commit doesn't get executed.
I looked at the sources and noticed that the patch attached to issue 6984 is 
not applied to this version of solrj.
Which solrj versions solves this bug?
As a workaround if I issue a deleteByQuery and the query selectd a single id, 
of a nonexistent document, will I successfully obtain commit? If not is there 
any other workaround?


  was:
Hi All,

Just found that solrj doesnot use commitwithin while using deletebyid. This 
issue is discussed in 
http://grokbase.com/t/lucene/solr-user/1275gkpntd/deletebyid-commitwithin-question

Faced the same issue today and found that, in 
org.apache.solr.client.solrj.request.UpdateRequest when new UpdateRequest is 
created in getRoutes() method ( Line number 244 ), the setCommitWithin param is 
not set in the urequest variable as it is done few lines above (Line number 
204) This causes setCommitWithin to revert to default value of -1 and the 
commit does not happen. Tried setting that like,
urequest.setCommitWithin(getCommitWithin()) and the feature is enabled from 
SolrJ.


> Solr commitwithin is not happening for deletebyId on solr 4.10.4
> 
>
> Key: SOLR-8322
> URL: https://issues.apache.org/jira/browse/SOLR-8322
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 4.6, Trunk
>Reporter: Matteo Grolla
> Fix For: 4.10.4, 5.0, Trunk
>
>
> Hi,
> I'm using solr 4.10.4 and solrj 4.10.4 and when issuing a deleteById with 
> a commitWithin I observe that the commit doesn't get executed.
> I looked at the sources and noticed that the patch attached to issue 6984 is 
> not applied to this version of solrj.
> Which solrj versions solves this bug?
> As a workaround if I issue a deleteByQuery and the query selectd a single id, 
> of a nonexistent document, will I successfully obtain commit? If not is there 
> any other workaround?



--
This message was sent by Atlassian 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-5971) 'Illegal character in query' when proxying request

[Ishan Chattopadhyaya (JIRA)]

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

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

Here goes the patch with the method in HttpSolrCall itself. Uwe, if you can 
think of a better place to put it in than this, please feel free to move it 
during the commit. Thanks.

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch, 
> SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:662)
> Without the facet.field attribute, it works fine on all the nodes.
> Is this some kind of double escaping when proxying the request?



--
This message was sent by Atlassian 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-5971) 'Illegal character in query' when proxying request

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-5971 at 11/20/15 3:59 PM:
--

I couldn't think of the right place to put this. "RequestUtil" sounded the 
least wrong place to put this in (but the json part seemed bad). I was also 
thinking of ClientUtils (which is in a solrj package), because there is an very 
functionally similar method there by the same name already. Maybe I should've 
kept it in HttpSolrCall itself.
I'll raise a patch to put this in HttpSolrCall. Does it sound fine?


was (Author: ichattopadhyaya):
I couldn't think of the right place to put this. "RequestUtil" sounded the 
least wrong place to put this in (but the json part seemed bad). I was also 
thinking of ClientUtils (which is in a solrj package). Maybe I should've kept 
it in HttpSolrCall itself.
I'll raise a patch to put this there. Does it sound fine?

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch, 
> SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> 

[jira] [Commented] (SOLR-8271) use SchemaSimilarityFactory as default when no explicit (top level) sim is configured

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8271: Change implicit default Similarity to use SchemaSimilarityFactory 
when luceneMatchVersion >= 6

> use SchemaSimilarityFactory as default when no explicit (top level) sim is 
> configured
> -
>
> Key: SOLR-8271
> URL: https://issues.apache.org/jira/browse/SOLR-8271
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: Trunk
>
> Attachments: SOLR-8271.patch, SOLR-8271.patch
>
>
> Idea spun out of SOLR-8057...
> bq. As far as i can tell, the chief reason SchemaSimilarityFactory wasn't 
> made the implicit default in IndexSchema when it was introduced is because of 
> how it differed/differs from DefaultSimilarity/ClassicSimilarity with respect 
> to multi-clause queries – see SchemaSimilarityFactory's class javadoc notes 
> relating to {{queryNorm}} and {{coord}}. Users were expected to think about 
> this trade off when making a concious choice to switch from 
> DefaultSimilarity/ClassicSimilarity to SchemaSimilarityFactory. But (again, 
> AFAICT) these discrepencies don't exist between SchemaSimilarityFactory's 
> PerFieldSimilarityWrapper and BM25Similiarity.
> So assuming luceneMatchVersion >= 6.0, and BM25 is implicit default, we 
> should be able to safely switch to using SchemaSimilarityFactory as our 
> default (which internally uses BM25 for fieldTypes that don't override) and 
> make it much easier for people to declare fieldType overrides for the 
> similarity (just edit the fieldType, w/o also needing to explicitly declare 
> SchemaSimilarityFactory)



--
This message was sent by Atlassian 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-8271) use SchemaSimilarityFactory as default when no explicit (top level) sim is configured

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-8271.

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

> use SchemaSimilarityFactory as default when no explicit (top level) sim is 
> configured
> -
>
> Key: SOLR-8271
> URL: https://issues.apache.org/jira/browse/SOLR-8271
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: Trunk
>
> Attachments: SOLR-8271.patch, SOLR-8271.patch
>
>
> Idea spun out of SOLR-8057...
> bq. As far as i can tell, the chief reason SchemaSimilarityFactory wasn't 
> made the implicit default in IndexSchema when it was introduced is because of 
> how it differed/differs from DefaultSimilarity/ClassicSimilarity with respect 
> to multi-clause queries – see SchemaSimilarityFactory's class javadoc notes 
> relating to {{queryNorm}} and {{coord}}. Users were expected to think about 
> this trade off when making a concious choice to switch from 
> DefaultSimilarity/ClassicSimilarity to SchemaSimilarityFactory. But (again, 
> AFAICT) these discrepencies don't exist between SchemaSimilarityFactory's 
> PerFieldSimilarityWrapper and BM25Similiarity.
> So assuming luceneMatchVersion >= 6.0, and BM25 is implicit default, we 
> should be able to safely switch to using SchemaSimilarityFactory as our 
> default (which internally uses BM25 for fieldTypes that don't override) and 
> make it much easier for people to declare fieldType overrides for the 
> similarity (just edit the fieldType, w/o also needing to explicitly declare 
> SchemaSimilarityFactory)



--
This message was sent by Atlassian 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-5971) 'Illegal character in query' when proxying request

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-5971:
-

One thing: Maybe we can use a HttpClient method to build the query string? How 
do we do that in SolrJ generally?

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:662)
> Without the facet.field attribute, it works fine on all the nodes.
> Is this some kind of double escaping when proxying the request?



--
This message was sent by Atlassian 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-5971) 'Illegal character in query' when proxying request

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-5971 at 11/20/15 4:00 PM:
--

I couldn't think of the right place to put this. "RequestUtil" sounded the 
least wrong place to put this in (but the json part seemed bad). I was also 
thinking of ClientUtils (which is in a solrj package), because there is a very 
functionally similar method there by the same name already. Maybe I should've 
kept it in HttpSolrCall itself.
I'll raise a patch to put this in HttpSolrCall. Does it sound fine?


was (Author: ichattopadhyaya):
I couldn't think of the right place to put this. "RequestUtil" sounded the 
least wrong place to put this in (but the json part seemed bad). I was also 
thinking of ClientUtils (which is in a solrj package), because there is an very 
functionally similar method there by the same name already. Maybe I should've 
kept it in HttpSolrCall itself.
I'll raise a patch to put this in HttpSolrCall. Does it sound fine?

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch, 
> SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> 

[jira] [Commented] (SOLR-7136) Add an AutoPhrasing TokenFilter

[Ted Sullivan (JIRA)]

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

Ted Sullivan commented on SOLR-7136:


Thanks for this submission [~kvakhsho...@gmail.com]! I think that this really 
helps to scale the autophrasing solution. Also the improvement in dealing with 
PositionLength is a big plus, as are the improvements in the query parser. 
Great work, thanks.

I have seen some reports on the github version of my code about memory leaks. 
Have you looked at that? I will take your patch and try to do some A/B 
comparisons on this to see if the new FSM implementation (hopefully) removes 
that problem too. But in general, have you done any performance/scaling tests 
on your version of the autofilter? Obviously, this goes along with the 
production-readiness that your new implementation makes possible. Thanks again 
for submitting this patch.

As to complementarity with SOLR-4381 - I would agree - nice to hear that the 
two solutions play nicely with each other :) IMO this is an important problem 
that needs a committed solution. If we give Solr users more than one way to 
"skin the cat" - the better the chance that they will find a solution for their 
own problem set.  

As to the acronym 'DC' - this is also ambiguous because it also stands for 
"District of Columbia" - certainly domain context will clear this up some but 
not if you have a global search problem like Google or Bing. I'll look into 
this problem too.

> Add an AutoPhrasing TokenFilter
> ---
>
> Key: SOLR-7136
> URL: https://issues.apache.org/jira/browse/SOLR-7136
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ted Sullivan
> Attachments: AutoPhaseFiniteStateDiagram.pdf, SOLR-7136.patch, 
> SOLR-7136.patch, SOLR-7136.patch, SOLR-7136.patch
>
>
> Adds an 'autophrasing' token filter which is designed to enable noun phrases 
> that represent a single entity to be tokenized in a singular fashion. Adds 
> support for ManagedResources and Query parser auto-phrasing support given 
> LUCENE-2605.
> The rationale for this Token Filter and its use in solving the long standing 
> multi-term synonym problem in Lucene Solr has been documented online. 
> http://lucidworks.com/blog/automatic-phrase-tokenization-improving-lucene-search-precision-by-more-precise-linguistic-analysis/
> https://lucidworks.com/blog/solution-for-multi-term-synonyms-in-lucenesolr-using-the-auto-phrasing-tokenfilter/



--
This message was sent by Atlassian 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-7136) Add an AutoPhrasing TokenFilter

[Ted Sullivan (JIRA)]

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

Ted Sullivan edited comment on SOLR-7136 at 11/20/15 4:12 PM:
--

Thanks for this submission [~kvakhsho...@gmail.com]! I think that this really 
helps to scale the autophrasing solution. Also the improvement in dealing with 
PositionLength is a big plus, as are the improvements in the query parser. 
Great work, thanks.

I have seen some reports on the github version of my code about memory leaks. 
Have you looked at that? I will take your patch and try to do some A/B 
comparisons on this to see if the new FSM implementation (hopefully) removes 
that problem too. But in general, have you done any performance/scaling tests 
on your version of the autophrasing filter? Obviously, this goes along with the 
production-readiness that your new implementation makes possible. Thanks again 
for submitting this patch.

As to complementarity with SOLR-4381 - I would agree - nice to hear that the 
two solutions play nicely with each other :) IMO this is an important problem 
that needs a committed solution. If we give Solr users more than one way to 
"skin the cat" - the better the chance that they will find a solution for their 
own problem set.  

As to the acronym 'DC' - this is also ambiguous because it also stands for 
"District of Columbia" - certainly domain context will clear this up some but 
not if you have a global search problem like Google or Bing. I'll look into 
this problem too.


was (Author: tedsullivan):
Thanks for this submission [~kvakhsho...@gmail.com]! I think that this really 
helps to scale the autophrasing solution. Also the improvement in dealing with 
PositionLength is a big plus, as are the improvements in the query parser. 
Great work, thanks.

I have seen some reports on the github version of my code about memory leaks. 
Have you looked at that? I will take your patch and try to do some A/B 
comparisons on this to see if the new FSM implementation (hopefully) removes 
that problem too. But in general, have you done any performance/scaling tests 
on your version of the autofilter? Obviously, this goes along with the 
production-readiness that your new implementation makes possible. Thanks again 
for submitting this patch.

As to complementarity with SOLR-4381 - I would agree - nice to hear that the 
two solutions play nicely with each other :) IMO this is an important problem 
that needs a committed solution. If we give Solr users more than one way to 
"skin the cat" - the better the chance that they will find a solution for their 
own problem set.  

As to the acronym 'DC' - this is also ambiguous because it also stands for 
"District of Columbia" - certainly domain context will clear this up some but 
not if you have a global search problem like Google or Bing. I'll look into 
this problem too.

> Add an AutoPhrasing TokenFilter
> ---
>
> Key: SOLR-7136
> URL: https://issues.apache.org/jira/browse/SOLR-7136
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ted Sullivan
> Attachments: AutoPhaseFiniteStateDiagram.pdf, SOLR-7136.patch, 
> SOLR-7136.patch, SOLR-7136.patch, SOLR-7136.patch
>
>
> Adds an 'autophrasing' token filter which is designed to enable noun phrases 
> that represent a single entity to be tokenized in a singular fashion. Adds 
> support for ManagedResources and Query parser auto-phrasing support given 
> LUCENE-2605.
> The rationale for this Token Filter and its use in solving the long standing 
> multi-term synonym problem in Lucene Solr has been documented online. 
> http://lucidworks.com/blog/automatic-phrase-tokenization-improving-lucene-search-precision-by-more-precise-linguistic-analysis/
> https://lucidworks.com/blog/solution-for-multi-term-synonyms-in-lucenesolr-using-the-auto-phrasing-tokenfilter/



--
This message was sent by Atlassian 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-8316) Allow a field to be stored=false indexed=false docValues=true

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8316:


This jira doesn't make sense to me ... it is absolutely posible to have a field 
that is stored=false & indexed=false (regardless of whether 
docValues=true|false)

There are lots of examples of this in various schemas, and even tests for the 
specific case of wanting docValues w/o stored or indexed fields...

* the {{ignored_\*}} dynamic field in {{basic_configs/conf/schema.xml}}
* {{manu_exact}} in {{sample_techproducts_configs/conf/schema.xml}}
* all of the {{sort_\*}} fields in {{schema-icucollate-dv.xml}} tested in 
{{TestICUCollationFieldDocValues.java}}

...just to name a few.

what exactly is the error you are getting?

> Allow a field to be stored=false indexed=false docValues=true
> -
>
> Key: SOLR-8316
> URL: https://issues.apache.org/jira/browse/SOLR-8316
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
>
> Right now if you try to index a field which is not stored or indexed you will 
> get an exception, however sometimes it makes sense to have a field which only 
> has docValues on for example see [SOLR-8220]



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

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

[jira] [Comment Edited] (LUCENE-6902) Fail fsync immediately

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-6902 at 11/20/15 6:29 PM:
-

Hi the patch fails on windows, because it does not swallow the IOException when 
fsyncing a directory. I will correct it and upload new patch. In fact, you 
catched the exception at the wrong place!


was (Author: thetaphi):
Hi the patch fails on windows, because it does not swallow the IOException when 
fsyncing a directory. I will correct it and upload new patch.

> Fail fsync immediately
> --
>
> Key: LUCENE-6902
> URL: https://issues.apache.org/jira/browse/LUCENE-6902
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Affects Versions: 5.3.1
>Reporter: Daniel Mitterdorfer
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 5.4
>
> Attachments: ioutils-fsync-fail-fast.patch
>
>
> While analysing a build issue in Elasticsearch I stumpled upon 
> org.apache.lucene.util.IOUtils.fsync. It has a retry loop in fsync whenever 
> an IOException occurs. However, there are lots of instances where a retry is 
> not useful, e.g. when a channel has been closed, a ClosedChannelException is 
> thrown and IOUtils#fsync still tries to fsync multiple times on the closed 
> channel.
> After bringing the issue to Robert's attention, he even opted for removing 
> the retry logic entirely for fsyncing.
> Please find attached a patch that removes the retry logic.



--
This message was sent by Atlassian 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-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6905:
---
Description: GeoPointDistanceQuery handles dateline crossing by splitting 
the Minimum Bounding Rectangle (MBR) into east/west ranges and rewriting to a 
Boolean SHOULD. PostFiltering is accomplished by calculating the distance from 
the center point to the candidate point field. Unfortunately the center point 
is wrapped such that calculating the closest point on the "circle" from an 
eastern point to a western MBR provides incorrect results thus causing false 
negatives in the range creation. This was caught by a jenkins failure and 
reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}  
(was: GeoPointDistanceQuery handles dateline crossing by splitting the MBR into 
east/west ranges and rewriting to a Boolean SHOULD. PostFiltering is 
accomplished by calculating the distance from the center point to the candidate 
point field. Unfortunately the center point is wrapped such that calculating 
the distance from a eastern point to a western MBR provides incorrect results.)

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian 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-8179) SQL JDBC - DriverImpl loadParams doesn't support keys with no values in the connection string

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8179:
--

[~risdenk], reviewed this closely today. Found a couple small things one 
possible blocker. The blocker is that we need to be able to support the zk 
Quorum and chroot. There's no existing tests for this but I believe the 
existing parsing technique would work for this. Here is the string we need to 
support for the zkHost:

zoo1:9983,zoo2:9983,zoo3:9983/foo/bar

I suspect this will break the URI.

Any thoughts on this?

> SQL JDBC - DriverImpl loadParams doesn't support keys with no values in the 
> connection string
> -
>
> Key: SOLR-8179
> URL: https://issues.apache.org/jira/browse/SOLR-8179
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>Assignee: Joel Bernstein
> Attachments: SOLR-8179.patch
>
>
> DBVisualizer and SquirrelSQL when trying to use JDBC with no 
> username/password and the JDBC driver causes an exception.
> {code}
> DriverManager.getConnection("jdbc:solr://" + zkHost + 
> "?collection=collection1==");
> {code}
> {code}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
>   at 
> org.apache.solr.client.solrj.io.sql.DriverImpl.loadParams(DriverImpl.java:141)
>   ... 46 more
> {code}
> The loadParams method doesn't support keys with no values.



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

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

[jira] [Assigned] (SOLR-8303) CustomBufferedIndexInput should include resource description when throwing EOFException

[Uwe Schindler (JIRA)]

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

Uwe Schindler reassigned SOLR-8303:
---

Assignee: Uwe Schindler

> CustomBufferedIndexInput should include resource description when throwing 
> EOFException
> ---
>
> Key: SOLR-8303
> URL: https://issues.apache.org/jira/browse/SOLR-8303
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3, 5.3
>Reporter: Mike Drob
>Assignee: Uwe Schindler
> Fix For: Trunk
>
> Attachments: SOLR-8303.patch
>
>
> The other implementations of IndexInput all include the resource description 
> when throwing an EOFException, for example:
> https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/store/ByteBufferIndexInput.java#L81
> CustomBufferedIndexInput should follow suit.



--
This message was sent by Atlassian 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-8303) CustomBufferedIndexInput should include resource description when throwing EOFException

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8303:
-

Hi Mike,
I can take this issue. Will commit in a moment.

> CustomBufferedIndexInput should include resource description when throwing 
> EOFException
> ---
>
> Key: SOLR-8303
> URL: https://issues.apache.org/jira/browse/SOLR-8303
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3, 5.3
>Reporter: Mike Drob
> Fix For: Trunk
>
> Attachments: SOLR-8303.patch
>
>
> The other implementations of IndexInput all include the resource description 
> when throwing an EOFException, for example:
> https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/store/ByteBufferIndexInput.java#L81
> CustomBufferedIndexInput should follow suit.



--
This message was sent by Atlassian 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-8316) Allow a field to be stored=false indexed=false docValues=true

[Keith Laban (JIRA)]

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

Keith Laban commented on SOLR-8316:
---

See: 
https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/schema/FieldType.java#L253

It looks like the field doesn't actually get created when you have this 
configuration. Its valid from a schema prospective but the field itself is 
ignored when you try to index it. The goal of this jira ticket is to create the 
docValues of field that is not stored or indexed, as far as I can tell this 
doesn't happen right now.

> Allow a field to be stored=false indexed=false docValues=true
> -
>
> Key: SOLR-8316
> URL: https://issues.apache.org/jira/browse/SOLR-8316
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
>
> Right now if you try to index a field which is not stored or indexed you will 
> get an exception, however sometimes it makes sense to have a field which only 
> has docValues on for example see [SOLR-8220]



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

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

[jira] [Created] (SOLR-8325) Declare loggers as private static final

[Mike Drob (JIRA)]

Mike Drob created SOLR-8325:
---

 Summary: Declare loggers as private static final
 Key: SOLR-8325
 URL: https://issues.apache.org/jira/browse/SOLR-8325
 Project: Solr
  Issue Type: Sub-task
Reporter: Mike Drob


This will touch a lot of class files, but shouldn't affect more than a single 
declaration in each. If a logger ends up being used outside of its declaring 
class, then it will be easiest to expand the visibility on it for now.

Non-PSF loggers will be targeted in future improvements.



--
This message was sent by Atlassian 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 # 2882 - Failure!

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.lucene.codecs.simpletext.TestSimpleTextDocValuesFormat.testGCDCompression

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


FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.simpletext.TestSimpleTextDocValuesFormat

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

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




Build Log:
[...truncated 5967 lines...]
   [junit4] Suite: 
org.apache.lucene.codecs.simpletext.TestSimpleTextDocValuesFormat
   [junit4]   2> 十一月 20, 2015 11:26:35 上午 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
   [junit4]   2> WARNING: Suite execution timed out: 
org.apache.lucene.codecs.simpletext.TestSimpleTextDocValuesFormat
   [junit4]   2>1) Thread[id=1, name=main, state=WAITING, group=main]
   [junit4]   2> at java.lang.Object.wait(Native Method)
   [junit4]   2> at java.lang.Thread.join(Thread.java:1245)
   [junit4]   2> at java.lang.Thread.join(Thread.java:1319)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:601)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.run(RandomizedRunner.java:450)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:244)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:10)
   [junit4]   2>2) Thread[id=297, 
name=TEST-TestSimpleTextDocValuesFormat.testGCDCompression-seed#[EFA3149D84512E9],
 state=TIMED_WAITING, group=TGRP-TestSimpleTextDocValuesFormat]
   [junit4]   2> at java.lang.Object.wait(Native Method)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.doWait(IndexWriter.java:4290)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1773)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1707)
   [junit4]   2> at 
org.apache.lucene.index.RandomIndexWriter.forceMerge(RandomIndexWriter.java:421)
   [junit4]   2> at 
org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestNumericsVsStoredFields(BaseDocValuesFormatTestCase.java:1225)
   [junit4]   2> at 
org.apache.lucene.index.BaseDocValuesFormatTestCase.testGCDCompression(BaseDocValuesFormatTestCase.java:2208)
   [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 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
   

[jira] [Created] (SOLR-8324) Logger Untanglement

[Mike Drob (JIRA)]

Mike Drob created SOLR-8324:
---

 Summary: Logger Untanglement
 Key: SOLR-8324
 URL: https://issues.apache.org/jira/browse/SOLR-8324
 Project: Solr
  Issue Type: Improvement
Reporter: Mike Drob
 Fix For: Trunk


I propose that we do a thorough examination of how we use loggers over the 
whole project. There are many instances of loggers being shared between classes 
that make troubleshooting difficult, and we can probably clean up some of the 
usage that has accumulated over numerous code moves and refactorings.

Because this has the potential to scope wildly out of control, I would like to 
break the work down into several subtasks.

* Loggers should be declared all three of {{private static final}} when 
possible. This both helps avoid the situations described in later bullets, and 
might provide a very minor performance improvement.
* Distinct classes should not use loggers from other classes, unless they are 
explicitly delegated to do so.
* Subclasses should declare their own loggers instead of relying on loggers 
from parent classes.
* Examine if forbidden-api or some other tool(s) can help maintain this, once 
we reach a desired state.

Each bullet might turn into one or more tasks, depending on how invasive 
individual changes become.



--
This message was sent by Atlassian 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-8325) Declare loggers as private static final

[Mike Drob (JIRA)]

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

Mike Drob updated SOLR-8325:

Attachment: SOLR-8325.patch

Attaching a patch against trunk. This patch does not rename any loggers, it 
only adjusts the declaring modifiers.

I suspect that it will become stale quickly, so I will attempt to rebase it as 
needed until committed.

> Declare loggers as private static final
> ---
>
> Key: SOLR-8325
> URL: https://issues.apache.org/jira/browse/SOLR-8325
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Mike Drob
> Fix For: Trunk
>
> Attachments: SOLR-8325.patch
>
>
> This will touch a lot of class files, but shouldn't affect more than a single 
> declaration in each. If a logger ends up being used outside of its declaring 
> class, then it will be easiest to expand the visibility on it for now.
> Non-PSF loggers will be targeted in future improvements.



--
This message was sent by Atlassian 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-8230) Create Facet Telemetry for Nested Facet Query

[Michael Sun (JIRA)]

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

Michael Sun commented on SOLR-8230:
---

Make sense. Thanks [~yo...@apache.org]

> Create Facet Telemetry for Nested Facet Query
> -
>
> Key: SOLR-8230
> URL: https://issues.apache.org/jira/browse/SOLR-8230
> Project: Solr
>  Issue Type: Sub-task
>  Components: Facet Module
>Reporter: Michael Sun
> Fix For: Trunk
>
> Attachments: SOLR-8230.patch
>
>
> This is the first step for SOLR-8228 Facet Telemetry. It's going to implement 
> the telemetry for a nested facet query and put the information obtained in 
> debug field in response.



--
This message was sent by Atlassian 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-8324) Logger Untanglement

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8324:


Regarding task #2, making loggers private is one aspect of not using loggers 
from other classes, but I don't think there's any way to prevent one class from 
creating a logger within itself that is tied to another class.  This discussion 
leads into something I've been trying to do for a while: Declare a logger with 
identical code in every class.

This code works, but creates a logger for each instance of the class, which is 
less than ideal, especially for very large installs:

{code:java}
private final Logger log = LoggerFactory.getLogger(this.getClass());
{code}

Every idea I've come up with for creating a static logger without needing the 
class name has failed.


> Logger Untanglement
> ---
>
> Key: SOLR-8324
> URL: https://issues.apache.org/jira/browse/SOLR-8324
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mike Drob
> Fix For: Trunk
>
>
> I propose that we do a thorough examination of how we use loggers over the 
> whole project. There are many instances of loggers being shared between 
> classes that make troubleshooting difficult, and we can probably clean up 
> some of the usage that has accumulated over numerous code moves and 
> refactorings.
> Because this has the potential to scope wildly out of control, I would like 
> to break the work down into several subtasks.
> * Loggers should be declared all three of {{private static final}} when 
> possible. This both helps avoid the situations described in later bullets, 
> and might provide a very minor performance improvement.
> * Distinct classes should not use loggers from other classes, unless they are 
> explicitly delegated to do so.
> * Subclasses should declare their own loggers instead of relying on loggers 
> from parent classes.
> * Examine if forbidden-api or some other tool(s) can help maintain this, once 
> we reach a desired state.
> Each bullet might turn into one or more tasks, depending on how invasive 
> individual changes become.



--
This message was sent by Atlassian 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

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-8220 at 11/20/15 6:46 PM:
--

{quote}
 We are adding fields retrieved from docValues by doing the following:
{code}
doc.add(schemaField.getType().createField(schemaField, 
sdv.get(docid).utf8ToString(), 1.0f));
{code}

this {{createField}} call is returning {{null}} based on the code I wrote 
above. Perhaps we need to create fields differently, or change how 
{{createField}} works.
{quote}
[Referencing this comment from SOLR-8316]. Can we "decorate" the SolrDocument 
in DocStreamer instead of trying to do that with the StoredDocument from 
lucene? That will give us the benefits: (a) we won't need to fix SOLR-8316 
(although I still don't understand how it affects the work here, since I 
thought the createField was doing its job and consequently the tests were 
passing. Maybe I'm missing something), (b) we can leave the StoredDocument as 
is, and not change it from under the document cache (which is probably an 
awkward thing with the current patch), (c) it has efficient containsKey(), if 
needed, so the linear {{O\(n\)}} cost can be avoided. Though, point b will mean 
we won't need containsKey() anyway.
This also means that SOLR-8276 will have to change, and there we will have to 
decorate a SolrInputDocument instead of a SolrDocument. 
Keith, Yonik, what do you think?


was (Author: ichattopadhyaya):
{quote}
 We are adding fields retrieved from docValues by doing the following:
{code}
doc.add(schemaField.getType().createField(schemaField, 
sdv.get(docid).utf8ToString(), 1.0f));
{code}

this {{createField}} call is returning {{null}} based on the code I wrote 
above. Perhaps we need to create fields differently, or change how 
{{createField}} works.
{quote}
[Referencing this comment from SOLR-8316]. Can we "decorate" the SolrDocument 
in DocStreamer instead of trying to do that with the StoredDocument from 
lucene? That will give us the benefits: (a) we won't need to fix SOLR-8316 
(although I still don't understand how it affects the work here, since I 
thought the createField was doing its job and consequently the tests were 
passing. Maybe I'm missing something), (b) we can leave the StoredDocument as 
is, and not change it from under the document cache (which is probably an 
awkward thing with the current patch), (c) it has efficient containsKey(), if 
needed, so the linear {{O\(n\)}} cost can be avoided. Though, point b will mean 
we won't need containsKey() anyway.
This also means that SOLR-8276 will have to change, and there we have decorate 
a SolrInputDocument instead of a SolrDocument. 
Keith, Yonik, what do you think?

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

[jira] [Commented] (SOLR-8316) Allow a field to be stored=false indexed=false docValues=true

[Keith Laban (JIRA)]

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

Keith Laban commented on SOLR-8316:
---

I'll have to take a look at the {{sort_*}} fields that sounds promising. 

> Allow a field to be stored=false indexed=false docValues=true
> -
>
> Key: SOLR-8316
> URL: https://issues.apache.org/jira/browse/SOLR-8316
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
>
> Right now if you try to index a field which is not stored or indexed you will 
> get an exception, however sometimes it makes sense to have a field which only 
> has docValues on for example see [SOLR-8220]



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

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

[jira] [Assigned] (SOLR-8179) SQL JDBC - DriverImpl loadParams doesn't support keys with no values in the connection string

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-8179:


Assignee: Joel Bernstein

> SQL JDBC - DriverImpl loadParams doesn't support keys with no values in the 
> connection string
> -
>
> Key: SOLR-8179
> URL: https://issues.apache.org/jira/browse/SOLR-8179
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>Assignee: Joel Bernstein
> Attachments: SOLR-8179.patch
>
>
> DBVisualizer and SquirrelSQL when trying to use JDBC with no 
> username/password and the JDBC driver causes an exception.
> {code}
> DriverManager.getConnection("jdbc:solr://" + zkHost + 
> "?collection=collection1==");
> {code}
> {code}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
>   at 
> org.apache.solr.client.solrj.io.sql.DriverImpl.loadParams(DriverImpl.java:141)
>   ... 46 more
> {code}
> The loadParams method doesn't support keys with no values.



--
This message was sent by Atlassian 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-7136) Add an AutoPhrasing TokenFilter

[Koorosh Vakhshoori (JIRA)]

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

Koorosh Vakhshoori commented on SOLR-7136:
--

As far as the memory leaks issue, I looked at my version and identified couple 
of areas that it could cause problems: 1) in AutoPhrasingQParserPluging I 
updated the code so all resources associated with AutoPhrasingTokenFilter 
instance is released by calling end() and close(), 2) when it came to 
phraseSets, I make sure it is populated once, in the earlier version every time 
the filter was instantiated the constructor would repopulated it. However, in 
some cases you want that, I have a version of constructor that force-populate 
the phraseSets! I call it in the ManagedAutophraseFilterFactory class.

As far as performance/scaling, no I have not done any formal evaluation. All I 
can tell, we have it running in our QA and people who have tested it are 
satisfied with the speed. However, our speed requires are in seconds and not 
milliseconds. I love to hear the result of your A/B testing.

On the acronym topic, you hit the nail on the head. This falls under 
personalized or context search. In our use case, our content is collections of 
different corpus, i.e. carpi. This means different users depending on their 
specialty want to see different results for the same query. This is a tough nut 
to crack. Glad to hear you would be looking into this issue.


> Add an AutoPhrasing TokenFilter
> ---
>
> Key: SOLR-7136
> URL: https://issues.apache.org/jira/browse/SOLR-7136
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ted Sullivan
> Attachments: AutoPhaseFiniteStateDiagram.pdf, SOLR-7136.patch, 
> SOLR-7136.patch, SOLR-7136.patch, SOLR-7136.patch
>
>
> Adds an 'autophrasing' token filter which is designed to enable noun phrases 
> that represent a single entity to be tokenized in a singular fashion. Adds 
> support for ManagedResources and Query parser auto-phrasing support given 
> LUCENE-2605.
> The rationale for this Token Filter and its use in solving the long standing 
> multi-term synonym problem in Lucene Solr has been documented online. 
> http://lucidworks.com/blog/automatic-phrase-tokenization-improving-lucene-search-precision-by-more-precise-linguistic-analysis/
> https://lucidworks.com/blog/solution-for-multi-term-synonyms-in-lucenesolr-using-the-auto-phrasing-tokenfilter/



--
This message was sent by Atlassian 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-8088) Distributed grouping seems to require docValues in 5.x, didn't in 4.x

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8088:


[~ysee...@gmail.com], I know that fixing the fallout in Solr from LUCENE-5666 
probably won't be easy.  Do we have a realistic timeframe for when a fix might 
happen?  I think I can probably use the "copyField that has docValues" 
workaround, but that might not be a realistic option for some.  There are 
likely legitimate cases where somebody wants to be able to group on a tokenized 
field.

> Distributed grouping seems to require docValues in 5.x, didn't in 4.x
> -
>
> Key: SOLR-8088
> URL: https://issues.apache.org/jira/browse/SOLR-8088
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.2.1
>Reporter: Shawn Heisey
>
> I have a field in my index that is lowercased after the KeywordTokenizer.  I 
> wish to do grouping on this field.  It is a distributed index.
> This works fine in Solr 4.9.1 running on Java 8.
> When I try the distributed grouping request (with the same schema) on Solr 
> 5.2.1, it fails, with this exception:
> {code}
> java.lang.IllegalStateException: unexpected docvalues type SORTED_SET for 
> field 'ip' (expected=SORTED). Use UninvertingReader or index with docvalues.
> {code}
> If I make the same request directly to one of the shards on 5.2.1, it works.  
> If I create a copyField to a field using StrField with docValues, the 
> distributed request works ... but then I lose the lowercasing.



--
This message was sent by Atlassian 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-8316) Allow a field to be stored=false indexed=false docValues=true

[Keith Laban (JIRA)]

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

Keith Laban commented on SOLR-8316:
---

After looking further into this, it looks like a problem related to the worked 
being done in [SOLR-8220]. 

We are adding fields retrieved from docValues by doing the following:
{code}
doc.add(schemaField.getType().createField(schemaField, 
sdv.get(docid).utf8ToString(), 1.0f));
{code}

this {{createField}} call is returning {{null}} based on the code I wrote 
above. Perhaps we need to create fields differently, or change how 
{{createField}} works.

> Allow a field to be stored=false indexed=false docValues=true
> -
>
> Key: SOLR-8316
> URL: https://issues.apache.org/jira/browse/SOLR-8316
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
>
> Right now if you try to index a field which is not stored or indexed you will 
> get an exception, however sometimes it makes sense to have a field which only 
> has docValues on for example see [SOLR-8220]



--
This message was sent by Atlassian 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-8324) Logger Untanglement

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-8324:
-

I believe that in Java 8 you can do something like...

{noformat}
private static final Logger log = 
LoggerFactory.getLogger(MethodHandles.lookup().getClass());
{noformat}

But I have no idea how efficient that construction is.

> Logger Untanglement
> ---
>
> Key: SOLR-8324
> URL: https://issues.apache.org/jira/browse/SOLR-8324
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mike Drob
> Fix For: Trunk
>
>
> I propose that we do a thorough examination of how we use loggers over the 
> whole project. There are many instances of loggers being shared between 
> classes that make troubleshooting difficult, and we can probably clean up 
> some of the usage that has accumulated over numerous code moves and 
> refactorings.
> Because this has the potential to scope wildly out of control, I would like 
> to break the work down into several subtasks.
> * Loggers should be declared all three of {{private static final}} when 
> possible. This both helps avoid the situations described in later bullets, 
> and might provide a very minor performance improvement.
> * Distinct classes should not use loggers from other classes, unless they are 
> explicitly delegated to do so.
> * Subclasses should declare their own loggers instead of relying on loggers 
> from parent classes.
> * Examine if forbidden-api or some other tool(s) can help maintain this, once 
> we reach a desired state.
> Each bullet might turn into one or more tasks, depending on how invasive 
> individual changes become.



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:64012: KeeperErrorCode = NoNode for 
/overseer/collection-queue-work/qnr-04

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:64012: KeeperErrorCode = NoNode for 
/overseer/collection-queue-work/qnr-04
at 
__randomizedtesting.SeedInfo.seed([AE2355069D707764:26776ADC338C1A9C]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:290)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:734)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:155)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
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 

[jira] [Updated] (LUCENE-6902) Fail fsync immediately

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-6902:
--
Attachment: ioutils-fsync-fail-fast.patch

Corrected patch. The inner try-block was obsolete. The catching had to be 
outside (as it was before, just more complicated).

I will remove the extra check for Java 9 to work around LUCENE-6169 in a second 
commit.

> Fail fsync immediately
> --
>
> Key: LUCENE-6902
> URL: https://issues.apache.org/jira/browse/LUCENE-6902
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Affects Versions: 5.3.1
>Reporter: Daniel Mitterdorfer
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 5.4
>
> Attachments: ioutils-fsync-fail-fast.patch, 
> ioutils-fsync-fail-fast.patch
>
>
> While analysing a build issue in Elasticsearch I stumpled upon 
> org.apache.lucene.util.IOUtils.fsync. It has a retry loop in fsync whenever 
> an IOException occurs. However, there are lots of instances where a retry is 
> not useful, e.g. when a channel has been closed, a ClosedChannelException is 
> thrown and IOUtils#fsync still tries to fsync multiple times on the closed 
> channel.
> After bringing the issue to Robert's attention, he even opted for removing 
> the retry logic entirely for fsyncing.
> Please find attached a patch that removes the retry logic.



--
This message was sent by Atlassian 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

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8220:


{quote}
 We are adding fields retrieved from docValues by doing the following:
{code}
doc.add(schemaField.getType().createField(schemaField, 
sdv.get(docid).utf8ToString(), 1.0f));
{code}

this {{createField}} call is returning {{null}} based on the code I wrote 
above. Perhaps we need to create fields differently, or change how 
{{createField}} works.
{quote}
[Referencing this comment from SOLR-8316]. Can we "decorate" the SolrDocument 
in DocStreamer instead of trying to do that with the StoredDocument from 
lucene? That will give us the benefits: (a) we won't need to fix SOLR-8316, (b) 
we can leave the StoredDocument as is, and not change it from under the 
document cache (which is probably an awkward thing with the current patch), (c) 
it has efficient containsKey(), if needed, so the linear O(n) cost can be 
avoided. Though, point b will mean we won't need containsKey() anyway.
This also means that SOLR-8276 will have to change, and there we have decorate 
a SolrInputDocument instead of a SolrDocument. 
Keith, Yonik, what do you think?

> 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
>
>
> 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] [Comment Edited] (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:comment-tabpanel=15018489#comment-15018489
 ] 

Ishan Chattopadhyaya edited comment on SOLR-8220 at 11/20/15 6:44 PM:
--

{quote}
 We are adding fields retrieved from docValues by doing the following:
{code}
doc.add(schemaField.getType().createField(schemaField, 
sdv.get(docid).utf8ToString(), 1.0f));
{code}

this {{createField}} call is returning {{null}} based on the code I wrote 
above. Perhaps we need to create fields differently, or change how 
{{createField}} works.
{quote}
[Referencing this comment from SOLR-8316]. Can we "decorate" the SolrDocument 
in DocStreamer instead of trying to do that with the StoredDocument from 
lucene? That will give us the benefits: (a) we won't need to fix SOLR-8316 
(although I still don't understand how it affects the work here, since I 
thought the createField was doing its job and consequently the tests were 
passing. Maybe I'm missing something), (b) we can leave the StoredDocument as 
is, and not change it from under the document cache (which is probably an 
awkward thing with the current patch), (c) it has efficient containsKey(), if 
needed, so the linear {{O\(n\)}} cost can be avoided. Though, point b will mean 
we won't need containsKey() anyway.
This also means that SOLR-8276 will have to change, and there we have decorate 
a SolrInputDocument instead of a SolrDocument. 
Keith, Yonik, what do you think?


was (Author: ichattopadhyaya):
{quote}
 We are adding fields retrieved from docValues by doing the following:
{code}
doc.add(schemaField.getType().createField(schemaField, 
sdv.get(docid).utf8ToString(), 1.0f));
{code}

this {{createField}} call is returning {{null}} based on the code I wrote 
above. Perhaps we need to create fields differently, or change how 
{{createField}} works.
{quote}
[Referencing this comment from SOLR-8316]. Can we "decorate" the SolrDocument 
in DocStreamer instead of trying to do that with the StoredDocument from 
lucene? That will give us the benefits: (a) we won't need to fix SOLR-8316 
(although I still don't understand how it affects the work here, since I 
thought the createField was doing its job and consequently the tests were 
passing. Maybe I'm missing something), (b) we can leave the StoredDocument as 
is, and not change it from under the document cache (which is probably an 
awkward thing with the current patch), (c) it has efficient containsKey(), if 
needed, so the linear {{O(n)}} cost can be avoided. Though, point b will mean 
we won't need containsKey() anyway.
This also means that SOLR-8276 will have to change, and there we have decorate 
a SolrInputDocument instead of a SolrDocument. 
Keith, Yonik, what do you think?

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

[jira] [Commented] (LUCENE-6902) Fail fsync immediately

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6902:
---

Hi the patch fails on windows, because it does not swallow the IOException when 
fsyncing a directory. I will correct it and upload new patch.

> Fail fsync immediately
> --
>
> Key: LUCENE-6902
> URL: https://issues.apache.org/jira/browse/LUCENE-6902
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Affects Versions: 5.3.1
>Reporter: Daniel Mitterdorfer
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 5.4
>
> Attachments: ioutils-fsync-fail-fast.patch
>
>
> While analysing a build issue in Elasticsearch I stumpled upon 
> org.apache.lucene.util.IOUtils.fsync. It has a retry loop in fsync whenever 
> an IOException occurs. However, there are lots of instances where a retry is 
> not useful, e.g. when a channel has been closed, a ClosedChannelException is 
> thrown and IOUtils#fsync still tries to fsync multiple times on the closed 
> channel.
> After bringing the issue to Robert's attention, he even opted for removing 
> the retry logic entirely for fsyncing.
> Please find attached a patch that removes the retry logic.



--
This message was sent by Atlassian 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-8179) SQL JDBC - DriverImpl loadParams doesn't support keys with no values in the connection string

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8179:


Good question. I'll look into it and see if I can add a test for this.

> SQL JDBC - DriverImpl loadParams doesn't support keys with no values in the 
> connection string
> -
>
> Key: SOLR-8179
> URL: https://issues.apache.org/jira/browse/SOLR-8179
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>Assignee: Joel Bernstein
> Attachments: SOLR-8179.patch
>
>
> DBVisualizer and SquirrelSQL when trying to use JDBC with no 
> username/password and the JDBC driver causes an exception.
> {code}
> DriverManager.getConnection("jdbc:solr://" + zkHost + 
> "?collection=collection1==");
> {code}
> {code}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
>   at 
> org.apache.solr.client.solrj.io.sql.DriverImpl.loadParams(DriverImpl.java:141)
>   ... 46 more
> {code}
> The loadParams method doesn't support keys with no values.



--
This message was sent by Atlassian 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

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-8220 at 11/20/15 6:44 PM:
--

{quote}
 We are adding fields retrieved from docValues by doing the following:
{code}
doc.add(schemaField.getType().createField(schemaField, 
sdv.get(docid).utf8ToString(), 1.0f));
{code}

this {{createField}} call is returning {{null}} based on the code I wrote 
above. Perhaps we need to create fields differently, or change how 
{{createField}} works.
{quote}
[Referencing this comment from SOLR-8316]. Can we "decorate" the SolrDocument 
in DocStreamer instead of trying to do that with the StoredDocument from 
lucene? That will give us the benefits: (a) we won't need to fix SOLR-8316 
(although I still don't understand how it affects the work here, since I 
thought the createField was doing its job and consequently the tests were 
passing. Maybe I'm missing something), (b) we can leave the StoredDocument as 
is, and not change it from under the document cache (which is probably an 
awkward thing with the current patch), (c) it has efficient containsKey(), if 
needed, so the linear {{O(n)}} cost can be avoided. Though, point b will mean 
we won't need containsKey() anyway.
This also means that SOLR-8276 will have to change, and there we have decorate 
a SolrInputDocument instead of a SolrDocument. 
Keith, Yonik, what do you think?


was (Author: ichattopadhyaya):
{quote}
 We are adding fields retrieved from docValues by doing the following:
{code}
doc.add(schemaField.getType().createField(schemaField, 
sdv.get(docid).utf8ToString(), 1.0f));
{code}

this {{createField}} call is returning {{null}} based on the code I wrote 
above. Perhaps we need to create fields differently, or change how 
{{createField}} works.
{quote}
[Referencing this comment from SOLR-8316]. Can we "decorate" the SolrDocument 
in DocStreamer instead of trying to do that with the StoredDocument from 
lucene? That will give us the benefits: (a) we won't need to fix SOLR-8316 
(although I still don't understand how it affects the work here, since I 
thought the createField was doing its job and consequently the tests were 
passing. Maybe I'm missing something), (b) we can leave the StoredDocument as 
is, and not change it from under the document cache (which is probably an 
awkward thing with the current patch), (c) it has efficient containsKey(), if 
needed, so the linear O(n) cost can be avoided. Though, point b will mean we 
won't need containsKey() anyway.
This also means that SOLR-8276 will have to change, and there we have decorate 
a SolrInputDocument instead of a SolrDocument. 
Keith, Yonik, what do you think?

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

[jira] [Comment Edited] (SOLR-8179) SQL JDBC - DriverImpl loadParams doesn't support keys with no values in the connection string

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8179 at 11/20/15 6:43 PM:


[~risdenk], reviewed this closely today. Found a couple small things and one 
possible blocker. The blocker is that we need to be able to support the zk 
Quorum and chroot. There's no existing tests for this but I believe the 
existing parsing technique would work for this. Here is the string we need to 
support for the zkHost:

zoo1:9983,zoo2:9983,zoo3:9983/foo/bar

I suspect this will break the URI.

Any thoughts on this?


was (Author: joel.bernstein):
[~risdenk], reviewed this closely today. Found a couple small things one 
possible blocker. The blocker is that we need to be able to support the zk 
Quorum and chroot. There's no existing tests for this but I believe the 
existing parsing technique would work for this. Here is the string we need to 
support for the zkHost:

zoo1:9983,zoo2:9983,zoo3:9983/foo/bar

I suspect this will break the URI.

Any thoughts on this?

> SQL JDBC - DriverImpl loadParams doesn't support keys with no values in the 
> connection string
> -
>
> Key: SOLR-8179
> URL: https://issues.apache.org/jira/browse/SOLR-8179
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: Trunk
>Reporter: Kevin Risden
>Assignee: Joel Bernstein
> Attachments: SOLR-8179.patch
>
>
> DBVisualizer and SquirrelSQL when trying to use JDBC with no 
> username/password and the JDBC driver causes an exception.
> {code}
> DriverManager.getConnection("jdbc:solr://" + zkHost + 
> "?collection=collection1==");
> {code}
> {code}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
>   at 
> org.apache.solr.client.solrj.io.sql.DriverImpl.loadParams(DriverImpl.java:141)
>   ... 46 more
> {code}
> The loadParams method doesn't support keys with no values.



--
This message was sent by Atlassian 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

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-8220 at 11/20/15 6:43 PM:
--

{quote}
 We are adding fields retrieved from docValues by doing the following:
{code}
doc.add(schemaField.getType().createField(schemaField, 
sdv.get(docid).utf8ToString(), 1.0f));
{code}

this {{createField}} call is returning {{null}} based on the code I wrote 
above. Perhaps we need to create fields differently, or change how 
{{createField}} works.
{quote}
[Referencing this comment from SOLR-8316]. Can we "decorate" the SolrDocument 
in DocStreamer instead of trying to do that with the StoredDocument from 
lucene? That will give us the benefits: (a) we won't need to fix SOLR-8316 
(although I still don't understand how it affects the work here, since I 
thought the createField was doing its job and consequently the tests were 
passing. Maybe I'm missing something), (b) we can leave the StoredDocument as 
is, and not change it from under the document cache (which is probably an 
awkward thing with the current patch), (c) it has efficient containsKey(), if 
needed, so the linear O(n) cost can be avoided. Though, point b will mean we 
won't need containsKey() anyway.
This also means that SOLR-8276 will have to change, and there we have decorate 
a SolrInputDocument instead of a SolrDocument. 
Keith, Yonik, what do you think?


was (Author: ichattopadhyaya):
{quote}
 We are adding fields retrieved from docValues by doing the following:
{code}
doc.add(schemaField.getType().createField(schemaField, 
sdv.get(docid).utf8ToString(), 1.0f));
{code}

this {{createField}} call is returning {{null}} based on the code I wrote 
above. Perhaps we need to create fields differently, or change how 
{{createField}} works.
{quote}
[Referencing this comment from SOLR-8316]. Can we "decorate" the SolrDocument 
in DocStreamer instead of trying to do that with the StoredDocument from 
lucene? That will give us the benefits: (a) we won't need to fix SOLR-8316, (b) 
we can leave the StoredDocument as is, and not change it from under the 
document cache (which is probably an awkward thing with the current patch), (c) 
it has efficient containsKey(), if needed, so the linear O(n) cost can be 
avoided. Though, point b will mean we won't need containsKey() anyway.
This also means that SOLR-8276 will have to change, and there we have decorate 
a SolrInputDocument instead of a SolrDocument. 
Keith, Yonik, what do you think?

> 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
>
>
> 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-8303) CustomBufferedIndexInput should include resource description when throwing EOFException

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-8303:

Fix Version/s: 5.4

> CustomBufferedIndexInput should include resource description when throwing 
> EOFException
> ---
>
> Key: SOLR-8303
> URL: https://issues.apache.org/jira/browse/SOLR-8303
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3, 5.3
>Reporter: Mike Drob
>Assignee: Uwe Schindler
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8303.patch
>
>
> The other implementations of IndexInput all include the resource description 
> when throwing an EOFException, for example:
> https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/store/ByteBufferIndexInput.java#L81
> CustomBufferedIndexInput should follow suit.



--
This message was sent by Atlassian 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-8324) Logger Untanglement

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8324:


I found something that seems to work, and I think will work in both Java 7 and 
8:

{code:java}
  private static final Logger log = LoggerFactory
.getLogger(Thread.currentThread().getStackTrace()[1].getClass());
{code}


> Logger Untanglement
> ---
>
> Key: SOLR-8324
> URL: https://issues.apache.org/jira/browse/SOLR-8324
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mike Drob
> Fix For: Trunk
>
>
> I propose that we do a thorough examination of how we use loggers over the 
> whole project. There are many instances of loggers being shared between 
> classes that make troubleshooting difficult, and we can probably clean up 
> some of the usage that has accumulated over numerous code moves and 
> refactorings.
> Because this has the potential to scope wildly out of control, I would like 
> to break the work down into several subtasks.
> * Loggers should be declared all three of {{private static final}} when 
> possible. This both helps avoid the situations described in later bullets, 
> and might provide a very minor performance improvement.
> * Distinct classes should not use loggers from other classes, unless they are 
> explicitly delegated to do so.
> * Subclasses should declare their own loggers instead of relying on loggers 
> from parent classes.
> * Examine if forbidden-api or some other tool(s) can help maintain this, once 
> we reach a desired state.
> Each bullet might turn into one or more tasks, depending on how invasive 
> individual changes become.



--
This message was sent by Atlassian 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-6229) Remove Scorer.getChildren?

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-6229:
-

We're using getChildren() solely for inspection purposes, so I'd be very sad if 
this capability went away.  If it *does* go away, FWIW we use this to figure 
out which clause(s) of a BooleanQuery a document comes from, so we'd need 
equivalent functionality at that point.

Thanks!

> Remove Scorer.getChildren?
> --
>
> Key: LUCENE-6229
> URL: https://issues.apache.org/jira/browse/LUCENE-6229
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> This API is used in a single place in our code base: 
> ToParentBlockJoinCollector. In addition, the usage is a bit buggy given that 
> using this API from a collector only works if setScorer is called with an 
> actual Scorer (and not eg. FakeScorer or BooleanScorer like you would get in 
> disjunctions) so it needs a custom IndexSearcher that does not use the 
> BulkScorer API.



--
This message was sent by Atlassian 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-5971) 'Illegal character in query' when proxying request

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-5971:
-

Hi this patch does not pass the forbiddenapis check, because it uses 
HttpServletRequest.getParameterMap() & co. Calling these methods is forbidden 
in any solr code because it breaks with wrongly-configured servlet containers 
and is slow on Jetty. SolrRequestDispatcher's parameter parsing correctly 
parsers parameters into a SolrRequest. Why can't we use the SolrRequest?

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch, 
> SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:662)
> Without the facet.field attribute, it works fine on all the nodes.
> Is this some kind of double escaping when proxying the request?



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

[jira] [Commented] (SOLR-8323) Add CollectionWatcher API to ZkStateReader

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8323:
---

bq. waitForThingsToLevelOut

That one is pretty test specific.

bq.  I think it should be relatively easy to extend it to stateformat=1 
collections as well if people think that's worth it.

Someone should remove stateformat=1 for Solr 6 in an ideal world.

> Add CollectionWatcher API to ZkStateReader
> --
>
> Key: SOLR-8323
> URL: https://issues.apache.org/jira/browse/SOLR-8323
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Alan Woodward
> Attachments: SOLR-8323.patch
>
>
> An API to watch for changes to collection state would be a generally useful 
> thing, both internally and for client use.



--
This message was sent by Atlassian 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-8230) Create Facet Telemetry for Nested Facet Query

[Michael Sun (JIRA)]

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

Michael Sun commented on SOLR-8230:
---

Just uploaded a new patch. Here is the change after previous patch.
1. the facet debug information is organized as general objects (map and list) 
and is formulated by response writer. In this way, the output trace is in 
correct format.
2. add filter description for each sub-facet processed.


> Create Facet Telemetry for Nested Facet Query
> -
>
> Key: SOLR-8230
> URL: https://issues.apache.org/jira/browse/SOLR-8230
> Project: Solr
>  Issue Type: Sub-task
>  Components: Facet Module
>Reporter: Michael Sun
> Fix For: Trunk
>
> Attachments: SOLR-8230.patch, SOLR-8230.patch
>
>
> This is the first step for SOLR-8228 Facet Telemetry. It's going to implement 
> the telemetry for a nested facet query and put the information obtained in 
> debug field in response.



--
This message was sent by Atlassian 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-5971) 'Illegal character in query' when proxying request

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-5971:


Such mistakes, although would've been caught by (and eventually was) 
precommit/forbidden apis, perhaps also shows the need for us to bolster the 
unit tests around request forwarding a bit more.

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch, 
> SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:662)
> Without the facet.field attribute, it works fine on all the nodes.
> Is this some kind of double escaping when proxying the request?



--
This message was sent by Atlassian 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-8324) Logger Untanglement

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8324:


Yes, copy/paste errors are a possible source of problems with loggers.  Having 
identical code would eliminate that as a problem.  Because the code I quoted 
above is somewhat verbose, a utility method would make it a little safer.

> Logger Untanglement
> ---
>
> Key: SOLR-8324
> URL: https://issues.apache.org/jira/browse/SOLR-8324
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mike Drob
> Fix For: Trunk
>
>
> I propose that we do a thorough examination of how we use loggers over the 
> whole project. There are many instances of loggers being shared between 
> classes that make troubleshooting difficult, and we can probably clean up 
> some of the usage that has accumulated over numerous code moves and 
> refactorings.
> Because this has the potential to scope wildly out of control, I would like 
> to break the work down into several subtasks.
> * Loggers should be declared all three of {{private static final}} when 
> possible. This both helps avoid the situations described in later bullets, 
> and might provide a very minor performance improvement.
> * Distinct classes should not use loggers from other classes, unless they are 
> explicitly delegated to do so.
> * Subclasses should declare their own loggers instead of relying on loggers 
> from parent classes.
> * Examine if forbidden-api or some other tool(s) can help maintain this, once 
> we reach a desired state.
> Each bullet might turn into one or more tasks, depending on how invasive 
> individual changes become.



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

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

[jira] [Created] (SOLR-8327) SolrDispatchFilter is not caching new state format, which results in live fetch from ZK per request if node does not contain core from collection

[Jessica Cheng Mallet (JIRA)]

Jessica Cheng Mallet created SOLR-8327:
--

 Summary: SolrDispatchFilter is not caching new state format, which 
results in live fetch from ZK per request if node does not contain core from 
collection
 Key: SOLR-8327
 URL: https://issues.apache.org/jira/browse/SOLR-8327
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 5.3
Reporter: Jessica Cheng Mallet


While perf testing with non-solrj client (request can be sent to any solr 
node), we noticed a huge amount of data from Zookeeper in our tcpdump (~1G for 
20 second dump). From the thread dump, we noticed this:

java.lang.Object.wait (Native Method)
java.lang.Object.wait (Object.java:503)
org.apache.zookeeper.ClientCnxn.submitRequest (ClientCnxn.java:1309)
org.apache.zookeeper.ZooKeeper.getData (ZooKeeper.java:1152)
org.apache.solr.common.cloud.SolrZkClient$7.execute (SolrZkClient.java:345)
org.apache.solr.common.cloud.SolrZkClient$7.execute (SolrZkClient.java:342)
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation 
(ZkCmdExecutor.java:61)
org.apache.solr.common.cloud.SolrZkClient.getData (SolrZkClient.java:342)
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive 
(ZkStateReader.java:841)
org.apache.solr.common.cloud.ZkStateReader$7.get (ZkStateReader.java:515)
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull 
(ClusterState.java:175)
org.apache.solr.common.cloud.ClusterState.getLeader (ClusterState.java:98)
org.apache.solr.servlet.HttpSolrCall.getCoreByCollection (HttpSolrCall.java:784)
org.apache.solr.servlet.HttpSolrCall.init (HttpSolrCall.java:272)
org.apache.solr.servlet.HttpSolrCall.call (HttpSolrCall.java:417)
org.apache.solr.servlet.SolrDispatchFilter.doFilter 
(SolrDispatchFilter.java:210)
org.apache.solr.servlet.SolrDispatchFilter.doFilter 
(SolrDispatchFilter.java:179)
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter 
(ServletHandler.java:1652)
org.eclipse.jetty.servlet.ServletHandler.doHandle (ServletHandler.java:585)
org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:143)
org.eclipse.jetty.security.SecurityHandler.handle (SecurityHandler.java:577)
org.eclipse.jetty.server.session.SessionHandler.doHandle 
(SessionHandler.java:223)
org.eclipse.jetty.server.handler.ContextHandler.doHandle 
(ContextHandler.java:1127)
org.eclipse.jetty.servlet.ServletHandler.doScope (ServletHandler.java:515)
org.eclipse.jetty.server.session.SessionHandler.doScope 
(SessionHandler.java:185)
org.eclipse.jetty.server.handler.ContextHandler.doScope 
(ContextHandler.java:1061)
org.eclipse.jetty.server.handler.ScopedHandler.handle (ScopedHandler.java:141)
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle 
(ContextHandlerCollection.java:215)
org.eclipse.jetty.server.handler.HandlerCollection.handle 
(HandlerCollection.java:110)
org.eclipse.jetty.server.handler.HandlerWrapper.handle (HandlerWrapper.java:97)
org.eclipse.jetty.server.Server.handle (Server.java:499)
org.eclipse.jetty.server.HttpChannel.handle (HttpChannel.java:310)
org.eclipse.jetty.server.HttpConnection.onFillable (HttpConnection.java:257)
org.eclipse.jetty.io.AbstractConnection$2.run (AbstractConnection.java:540)
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob 
(QueuedThreadPool.java:635)
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run (QueuedThreadPool.java:555)
java.lang.Thread.run (Thread.java:745)

Looks like SolrDispatchFilter doesn't have caching similar to the 
collectionStateCache in CloudSolrClient, so if the node doesn't know about a 
collection in the new state format, it just live-fetch it from Zookeeper on 
every request.



--
This message was sent by Atlassian 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-8303) CustomBufferedIndexInput should include resource description when throwing EOFException

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8303: CustomBufferedIndexInput now includes resource description when 
throwing EOFException

> CustomBufferedIndexInput should include resource description when throwing 
> EOFException
> ---
>
> Key: SOLR-8303
> URL: https://issues.apache.org/jira/browse/SOLR-8303
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3, 5.3
>Reporter: Mike Drob
>Assignee: Uwe Schindler
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8303.patch
>
>
> The other implementations of IndexInput all include the resource description 
> when throwing an EOFException, for example:
> https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/store/ByteBufferIndexInput.java#L81
> CustomBufferedIndexInput should follow suit.



--
This message was sent by Atlassian 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-5971) 'Illegal character in query' when proxying request

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-5971:
-

So it is better to use the already decoded parameters: this.queryParams and use 
those!
Your code also has the problem that it cannot handle multiple identical keys 
(like multiple "fq=" parameters).

I will post a new patch later so you can check it.

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch, 
> SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:662)
> Without the facet.field attribute, it works fine on all the nodes.
> Is this some kind of double escaping when proxying the request?



--
This message was sent by Atlassian 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-5971) 'Illegal character in query' when proxying request

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-5971:


Ouch, I didn't check the precommit! The multiple parameters with same key not 
being handled was really bad; apologies...

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch, 
> SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:662)
> Without the facet.field attribute, it works fine on all the nodes.
> Is this some kind of double escaping when proxying the request?



--
This message was sent by Atlassian 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 # 203 - Failure!

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([8FB8B67C3393161:E1A1305F5DA0A1C9]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:750)
at 
org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir(TestArbitraryIndexDir.java:107)
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 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=*[count(//doc)=1]
xml response was: 

00


request was:q=id:2=standard=0=20=2.2
at 

[jira] [Updated] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?

[Steve Molloy (JIRA)]

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

Steve Molloy updated SOLR-7642:
---
Attachment: SOLR-7642.patch

Here's a patch that creates the znode only if you add the createZkRoot system 
property. This way users can decide which behaviour they want.

> Should launching Solr in cloud mode using a ZooKeeper chroot create the 
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
>  Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper 
> connection string that includes a chroot leads to the following 
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [   ] org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified 
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at 
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script 
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or 
> is that some violation of using a chroot?



--
This message was sent by Atlassian 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-8303) CustomBufferedIndexInput should include resource description when throwing EOFException

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved SOLR-8303.
-
Resolution: Fixed

Thanks Mike.

> CustomBufferedIndexInput should include resource description when throwing 
> EOFException
> ---
>
> Key: SOLR-8303
> URL: https://issues.apache.org/jira/browse/SOLR-8303
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3, 5.3
>Reporter: Mike Drob
>Assignee: Uwe Schindler
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8303.patch
>
>
> The other implementations of IndexInput all include the resource description 
> when throwing an EOFException, for example:
> https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/store/ByteBufferIndexInput.java#L81
> CustomBufferedIndexInput should follow suit.



--
This message was sent by Atlassian 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-8324) Logger Untanglement

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8324:


A static method could be added to a utility class, using the Thread call that I 
found.  A call to that method can be used in every class that needs a logger.

{code:java}
  private static final log = SomeUtilClass.getDefaultLogger();
{code}


> Logger Untanglement
> ---
>
> Key: SOLR-8324
> URL: https://issues.apache.org/jira/browse/SOLR-8324
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mike Drob
> Fix For: Trunk
>
>
> I propose that we do a thorough examination of how we use loggers over the 
> whole project. There are many instances of loggers being shared between 
> classes that make troubleshooting difficult, and we can probably clean up 
> some of the usage that has accumulated over numerous code moves and 
> refactorings.
> Because this has the potential to scope wildly out of control, I would like 
> to break the work down into several subtasks.
> * Loggers should be declared all three of {{private static final}} when 
> possible. This both helps avoid the situations described in later bullets, 
> and might provide a very minor performance improvement.
> * Distinct classes should not use loggers from other classes, unless they are 
> explicitly delegated to do so.
> * Subclasses should declare their own loggers instead of relying on loggers 
> from parent classes.
> * Examine if forbidden-api or some other tool(s) can help maintain this, once 
> we reach a desired state.
> Each bullet might turn into one or more tasks, depending on how invasive 
> individual changes become.



--
This message was sent by Atlassian 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-8324) Logger Untanglement

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-8324:
-

What specifically are we trying to solve by doing it that way? Prevent 
copy-paste errors? I think it would be more intuitive to figure out a static 
analysis rule to catch bad usage and keep things idiomatic rather than trying 
to find workarounds on JVM limitations.

> Logger Untanglement
> ---
>
> Key: SOLR-8324
> URL: https://issues.apache.org/jira/browse/SOLR-8324
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mike Drob
> Fix For: Trunk
>
>
> I propose that we do a thorough examination of how we use loggers over the 
> whole project. There are many instances of loggers being shared between 
> classes that make troubleshooting difficult, and we can probably clean up 
> some of the usage that has accumulated over numerous code moves and 
> refactorings.
> Because this has the potential to scope wildly out of control, I would like 
> to break the work down into several subtasks.
> * Loggers should be declared all three of {{private static final}} when 
> possible. This both helps avoid the situations described in later bullets, 
> and might provide a very minor performance improvement.
> * Distinct classes should not use loggers from other classes, unless they are 
> explicitly delegated to do so.
> * Subclasses should declare their own loggers instead of relying on loggers 
> from parent classes.
> * Examine if forbidden-api or some other tool(s) can help maintain this, once 
> we reach a desired state.
> Each bullet might turn into one or more tasks, depending on how invasive 
> individual changes become.



--
This message was sent by Atlassian 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-8326) Adding read restriction to BasicAuth + RuleBased authorization causes issue with replication

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8326:


Here are the list of steps that you'd need to run to see that things are fine 
for you without the read permission:
* Untar and setup Solr, don't start it yet
* Start clean zookeeper
* Put the security.json in zk, without anything other than a security-edit 
permission. Find the content of the file below. Upload it using your own zk 
client or through the solr script:
> solr-5.3.1/server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd 
> putfile /security.json ~/security.json

security.json:
{"authentication":{"class":"solr.BasicAuthPlugin","credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
 
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}},"authorization":{"class":"solr.RuleBasedAuthorizationPlugin","user-role":{"solr":["admin"]},"permissions":[{"name":"security-edit","role":"admin"}]}}

* Start solr: 
> solr-5.3.1/bin/solr start -e cloud -z localhost:2181

You would need to key in a few things e.g. #nodes and ports, leave them at the 
default values of 2 nodes and 8983/7574, unless you want to run Solr on a 
different port. Then let it create a default collection to just make sure that 
everything works fine.

* Add the 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"}}'

At this point, everything should be working fine. Restarting the nodes  should 
also work fine. You can try 2 things at this point:
1. Create a new collection with 1 shard and 1 replica and then try adding a 
replica, here's how:
> curl --user solr:SolrRocks 
> http://localhost:8983/solr/admin/collections?action=CREATE=testcollection=gettingstarted=1

> curl --user solr:SolrRocks 
> http://localhost:8983/solr/admin/collections?action=ADDREPLICA=testcollection=shard1

This should work fine.

2. After this, try restarting the solr cluster. Here's how you can do so, 
assuming you didn't change any of the defaults and you are running zk on 
localhost:2181. If not, just change those values below:
> bin/solr stop -all

After this, check that Solr was actually stopped. I'd also suggest you tail the 
logs on both nodes when they are coming up to see any errors, if any. The logs 
would be here: example/cloud/node1/logs/solr.log and 
example/cloud/node2/logs/solr.log

> bin/solr start -c -p 8983 -s "example/cloud/node1/solr" -z localhost:2181
> bin/solr start -c -p 7574 -s "example/cloud/node2/solr" -z localhost:2181

If you get to this checkpoint fine, try adding a read permission.
Add a permission:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : {"name":"read", 
> "role":"read"}}'

Add a user:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
> 'Content-type:application/json' -d '{"set-user" : {"solrread":"solrRocks"}}'

Assign a role to the user:
>curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
>'Content-type:application/json' -d '{"set-user-role" : {"solrread":["read"]}}'

After this, you should start having issues with ADDREPLICA.
Also, as you would at this point have a collection with a shard that has a 
replication factor > 1 (remember the ADDREPLICA we did earlier), you would have 
issues when you restart the cluster again using the steps I mentioned above.

> Adding read restriction to BasicAuth + RuleBased authorization causes issue 
> with replication
> 
>
> Key: SOLR-8326
> URL: https://issues.apache.org/jira/browse/SOLR-8326
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3, 5.3.1
>Reporter: Anshum Gupta
>Priority: Blocker
> Fix For: 5.4
>
>
> This was reported on the mailing list:
> https://www.mail-archive.com/solr-user@lucene.apache.org/msg115921.html
> I tested it out as follows to confirm that adding a 'read' rule causes 
> replication to break. 



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

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

[jira] [Created] (SOLR-8326) Adding read restriction to BasicAuth + RuleBased authorization causes issue with replication

[Anshum Gupta (JIRA)]

Anshum Gupta created SOLR-8326:
--

 Summary: Adding read restriction to BasicAuth + RuleBased 
authorization causes issue with replication
 Key: SOLR-8326
 URL: https://issues.apache.org/jira/browse/SOLR-8326
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3, 5.3.1
Reporter: Anshum Gupta
Priority: Blocker
 Fix For: 5.4


This was reported on the mailing list:
https://www.mail-archive.com/solr-user@lucene.apache.org/msg115921.html

I tested it out as follows to confirm that adding a 'read' rule causes 
replication to break. 




--
This message was sent by Atlassian 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-8324) Logger Untanglement

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-8324:
-

Using a utility method still wouldn't enforce that the Logger is declared 
private static final, which is the bigger issue, I think.

How does it work with subclassing? I imagine that it still returns a logger for 
the base class, but I'm not 100% sure on that.

I'm currently hesitant about replacing all of the Logger declarations with a 
snippet like this because I'd like to give the benefit of the doubt to the 
existing code. There _might_ be some reason that a few classes currently share 
loggers, and I'd feel more comfortable looking at each of those in turn, rather 
than replacing everything at once.

> Logger Untanglement
> ---
>
> Key: SOLR-8324
> URL: https://issues.apache.org/jira/browse/SOLR-8324
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mike Drob
> Fix For: Trunk
>
>
> I propose that we do a thorough examination of how we use loggers over the 
> whole project. There are many instances of loggers being shared between 
> classes that make troubleshooting difficult, and we can probably clean up 
> some of the usage that has accumulated over numerous code moves and 
> refactorings.
> Because this has the potential to scope wildly out of control, I would like 
> to break the work down into several subtasks.
> * Loggers should be declared all three of {{private static final}} when 
> possible. This both helps avoid the situations described in later bullets, 
> and might provide a very minor performance improvement.
> * Distinct classes should not use loggers from other classes, unless they are 
> explicitly delegated to do so.
> * Subclasses should declare their own loggers instead of relying on loggers 
> from parent classes.
> * Examine if forbidden-api or some other tool(s) can help maintain this, once 
> we reach a desired state.
> Each bullet might turn into one or more tasks, depending on how invasive 
> individual changes become.



--
This message was sent by Atlassian 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-7641) bin/solr script checks for the presence of the JAR command before resolving java (where it might also find jar)

[James Sterling (JIRA)]

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

James Sterling commented on SOLR-7641:
--

I just installed 5.3.1 on CentOS 7 and I'm seeing this issue. What gives?

> bin/solr script checks for the presence of the JAR command before resolving 
> java (where it might also find jar)
> ---
>
> Key: SOLR-7641
> URL: https://issues.apache.org/jira/browse/SOLR-7641
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: 5.3
>
>
> I have SOLR_JAVA_HOME set to point to a valid JDK in my bin/solr.in.sh
> {code}
> SOLR_JAVA_HOME="/home/ubuntu/jdk1.8.0_45"
> {code}
> Note: I do not have JAVA_HOME set in my environment nor is it in my PATH.
> And yet, when I run bin/solr, I get the following error:
> {code}
> $ bin/solr start -cloud -p 8984 -d cloud84 -f
> This script requires extracting a WAR file with either the jar or unzip 
> utility, please install these utilities or contact your administrator for 
> assistance.
> {code}
> I think this code in bin/solr should be after the script resolves the 
> location of "java" so it can check there for "jar" and use that rather than 
> failing the script as it's doing now.
> {code}
> if hash jar 2>/dev/null ; then  # hash returns true if jar is on the path
>   UNPACK_WAR_CMD=("$(command -v jar)" xf)
> elif hash unzip 2>/dev/null ; then  # hash returns true if unzip is on the 
> path
>   UNPACK_WAR_CMD=("$(command -v unzip)" -q)
> else
>   echo -e "This script requires extracting a WAR file with either the jar or 
> unzip utility, please install these utilities or contact your administrator 
> for assistance."
>   exit 1
> fi
> {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-8303) CustomBufferedIndexInput should include resource description when throwing EOFException

[ASF subversion and git services (JIRA)]

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

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

Commit 1715403 from [~thetaphi] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1715403 ]

Merged revision(s) 1715402 from lucene/dev/trunk:
SOLR-8303: CustomBufferedIndexInput now includes resource description when 
throwing EOFException

> CustomBufferedIndexInput should include resource description when throwing 
> EOFException
> ---
>
> Key: SOLR-8303
> URL: https://issues.apache.org/jira/browse/SOLR-8303
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3, 5.3
>Reporter: Mike Drob
>Assignee: Uwe Schindler
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8303.patch
>
>
> The other implementations of IndexInput all include the resource description 
> when throwing an EOFException, for example:
> https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/store/ByteBufferIndexInput.java#L81
> CustomBufferedIndexInput should follow suit.



--
This message was sent by Atlassian 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-6229) Remove Scorer.getChildren?

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6229:
--

Couldn't you do it by evaluating each clause on the top hits?

> Remove Scorer.getChildren?
> --
>
> Key: LUCENE-6229
> URL: https://issues.apache.org/jira/browse/LUCENE-6229
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> This API is used in a single place in our code base: 
> ToParentBlockJoinCollector. In addition, the usage is a bit buggy given that 
> using this API from a collector only works if setScorer is called with an 
> actual Scorer (and not eg. FakeScorer or BooleanScorer like you would get in 
> disjunctions) so it needs a custom IndexSearcher that does not use the 
> BulkScorer API.



--
This message was sent by Atlassian 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-8230) Create Facet Telemetry for Nested Facet Query

[Michael Sun (JIRA)]

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

Michael Sun updated SOLR-8230:
--
Attachment: SOLR-8230.patch

> Create Facet Telemetry for Nested Facet Query
> -
>
> Key: SOLR-8230
> URL: https://issues.apache.org/jira/browse/SOLR-8230
> Project: Solr
>  Issue Type: Sub-task
>  Components: Facet Module
>Reporter: Michael Sun
> Fix For: Trunk
>
> Attachments: SOLR-8230.patch, SOLR-8230.patch
>
>
> This is the first step for SOLR-8228 Facet Telemetry. It's going to implement 
> the telemetry for a nested facet query and put the information obtained in 
> debug field in response.



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

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

[jira] [Created] (SOLR-8328) This script requires extracting a WAR file with either the jar or unzip utility, please install these utilities or contact your administrator for assistance.

[James Sterling (JIRA)]

James Sterling created SOLR-8328:


 Summary: This script requires extracting a WAR file with either 
the jar or unzip utility, please install these utilities or contact your 
administrator for assistance.
 Key: SOLR-8328
 URL: https://issues.apache.org/jira/browse/SOLR-8328
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3.1
 Environment: CentOS 7
Reporter: James Sterling


Seeing the WAR error using solr 5.3.1 on CentOS 7 after fresh install.

wget http://www.eu.apache.org/dist/lucene/solr/5.3.1/solr-5.3.1.tgz
tar xzf solr-5.3.1.tgz solr-5.3.1/bin/install_solr_service.sh 
--strip-components=2
udo chmod +x install_solr_service.sh
sudo ./install_solr_service.sh solr-5.3.1.tgz




--
This message was sent by Atlassian 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=15018760#comment-15018760
 ] 

Keith Laban commented on SOLR-8220:
---

It looks like calling {{createFields}} instead actually creates both the fields 
we need. 

I was able to change decoration to something like this
{code}
SortedDocValues sdv = leafReader.getSortedDocValues(fieldName);
for(StorableField s: schemaField.getType().createFields(schemaField, 
sdv.get(docid).utf8ToString(), 1.0f)) {
  if(s != null) doc.add(s);
}
{code}

which makes the the SortedDocValueField get added to the document properly, but 
when trying to write the string value later on it doesn't write anything 
because the implementation in {{Field}} doesn't know how to write a 
{{BytesRef}}. We can override this is in {{SortedDocValueField}} but all of 
that stuff is in lucene code. It looks like {{StrField#createFields}} converts 
the string value to a {{BytesRef}} for the constructors of the doc values 
fields.


I'm still a bit confused how [SOLR-8276] works for you, i get a NPE when trying 
pull back the non-indexed/non-stored field in the current impl.

> 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
>
>
> 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-8328) This script requires extracting a WAR file with either the jar or unzip utility, please install these utilities or contact your administrator for assistance.

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-8328:
---
Fix Version/s: (was: 5.3.1)
   6.0
   5.4

> This script requires extracting a WAR file with either the jar or unzip 
> utility, please install these utilities or contact your administrator for 
> assistance.
> -
>
> Key: SOLR-8328
> URL: https://issues.apache.org/jira/browse/SOLR-8328
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3.1
> Environment: CentOS 7
>Reporter: James Sterling
>Assignee: Shawn Heisey
> Fix For: 5.4, 6.0
>
> Attachments: SOLR-8328.patch
>
>
> Seeing the WAR error using solr 5.3.1 on CentOS 7 after fresh install.
> wget http://www.eu.apache.org/dist/lucene/solr/5.3.1/solr-5.3.1.tgz
> tar xzf solr-5.3.1.tgz solr-5.3.1/bin/install_solr_service.sh 
> --strip-components=2
> udo chmod +x install_solr_service.sh
> sudo ./install_solr_service.sh solr-5.3.1.tgz



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

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

[jira] [Reopened] (SOLR-8328) This script requires extracting a WAR file with either the jar or unzip utility, please install these utilities or contact your administrator for assistance.

[Shawn Heisey (JIRA)]

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

Shawn Heisey reopened SOLR-8328:


There's a patch, but the fix is not yet applied.  Resolving is premature.

> This script requires extracting a WAR file with either the jar or unzip 
> utility, please install these utilities or contact your administrator for 
> assistance.
> -
>
> Key: SOLR-8328
> URL: https://issues.apache.org/jira/browse/SOLR-8328
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3.1
> Environment: CentOS 7
>Reporter: James Sterling
>Assignee: Shawn Heisey
> Fix For: 5.4, 6.0
>
> Attachments: SOLR-8328.patch
>
>
> Seeing the WAR error using solr 5.3.1 on CentOS 7 after fresh install.
> wget http://www.eu.apache.org/dist/lucene/solr/5.3.1/solr-5.3.1.tgz
> tar xzf solr-5.3.1.tgz solr-5.3.1/bin/install_solr_service.sh 
> --strip-components=2
> udo chmod +x install_solr_service.sh
> sudo ./install_solr_service.sh solr-5.3.1.tgz



--
This message was sent by Atlassian 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-5971) 'Illegal character in query' when proxying request

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-5971:


+1, LGTM.

> 'Illegal character in query' when proxying request
> --
>
> Key: SOLR-5971
> URL: https://issues.apache.org/jira/browse/SOLR-5971
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.7.1
> Environment: Debian Wheezy, Java(TM) SE Runtime Environment (build 
> 1.6.0_26-b03)
>Reporter: Eric Bus
>Priority: Blocker
>  Labels: characters, exception, invalid, proxy, query, solrcloud
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-5971.patch, SOLR-5971.patch, SOLR-5971.patch, 
> SOLR-5971.patch, SOLR-5971.patch
>
>
> My cluster contains 3 Solr instances. I have a collection consisting of one 
> shard with 2 replica's. So one node in the cluster does not have a replicate 
> of the shard.
> The following query works when I query one of the two replica nodes:
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*
> But when I query the node without the replica, I get;
> {msg=Illegal character in query at index 78: 
> http://X.X.X.X:8080/solr/collection/select/?facet=true={!ex%3Dfilters,filter1340+key%3Dfacet1340Values}string_months_month=true=*:*,trace=java.lang.IllegalArgumentException
>   at java.net.URI.create(URI.java:842)
>   at org.apache.http.client.methods.HttpGet.(HttpGet.java:69)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.remoteQuery(SolrDispatchFilter.java:527)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:368)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>   at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:662)
> Without the facet.field attribute, it works fine on all the nodes.
> Is this some kind of double escaping when proxying the request?



--
This message was sent by Atlassian 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-8328) This script requires extracting a WAR file with either the jar or unzip utility, please install these utilities or contact your administrator for assistance.

[Shawn Heisey (JIRA)]

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

Shawn Heisey edited comment on SOLR-8328 at 11/20/15 9:47 PM:
--

My patch was created on branch_5x.  When I tried to apply it to trunk, the 
CHANGES.txt update would not apply.  Comparing the trunk CHANGES with the 5x 
CHANGES, I can see a significant number of differences in the 5.4 section (and 
some sections further down), in addition to the obvious difference of having a 
6.0 section that is not present in the latter.  It looks like most of the 
differences are issue numbers in different places and whitespace differences.

The way I am inclined to fix this is to make sure that the 5x CHANGES is 
correct, then simply replace everything after the 6.0 section with the contents 
of the 5x file.


was (Author: elyograg):
My patch was created on branch_5x.  When I tried to apply it to trunk, the 
CHANGES.txt update would not apply.  Comparing the trunk CHANGES with the 5x 
CHANGES, I can see a significant number of differences in the 5.4 section (and 
some sections further down), in addition to the obvious difference of having a 
6.0 section that is not present in the latter.

> This script requires extracting a WAR file with either the jar or unzip 
> utility, please install these utilities or contact your administrator for 
> assistance.
> -
>
> Key: SOLR-8328
> URL: https://issues.apache.org/jira/browse/SOLR-8328
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3.1
> Environment: CentOS 7
>Reporter: James Sterling
>Assignee: Shawn Heisey
> Fix For: 5.4, 6.0
>
> Attachments: SOLR-8328.patch
>
>
> Seeing the WAR error using solr 5.3.1 on CentOS 7 after fresh install.
> wget http://www.eu.apache.org/dist/lucene/solr/5.3.1/solr-5.3.1.tgz
> tar xzf solr-5.3.1.tgz solr-5.3.1/bin/install_solr_service.sh 
> --strip-components=2
> udo chmod +x install_solr_service.sh
> sudo ./install_solr_service.sh solr-5.3.1.tgz



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

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