[jira] [Commented] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet
[
https://issues.apache.org/jira/browse/SOLR-7495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14910143#comment-14910143
]
Oliver Schrenk commented on SOLR-7495:
--
Is there another way of faceting numeric data now?
> Unexpected docvalues type NUMERIC when grouping by a int facet
> --
>
> Key: SOLR-7495
> URL: https://issues.apache.org/jira/browse/SOLR-7495
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.3
>Reporter: Fabio Batista da Silva
> Attachments: SOLR-7495.patch
>
>
> Hey All,
> After upgrading from solr 4.10 to 5.1 with solr could
> I'm getting a IllegalStateException when i try to facet a int field.
> IllegalStateException: unexpected docvalues type NUMERIC for field 'year'
> (expected=SORTED). Use UninvertingReader or index with docvalues.
> schema.xml
> {code}
>
>
>
>
>
>
> multiValued="false" required="true"/>
> multiValued="false" required="true"/>
>
>
> stored="true"/>
>
>
>
> />
> sortMissingLast="true"/>
> positionIncrementGap="0"/>
> positionIncrementGap="0"/>
> positionIncrementGap="0"/>
> precisionStep="0" positionIncrementGap="0"/>
> positionIncrementGap="0"/>
> positionIncrementGap="100">
>
>
> words="stopwords.txt" />
>
> maxGramSize="15"/>
>
>
>
> words="stopwords.txt" />
> synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
>
>
>
> positionIncrementGap="100">
>
>
> words="stopwords.txt" />
>
> maxGramSize="15"/>
>
>
>
> words="stopwords.txt" />
> synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
>
>
>
> class="solr.SpatialRecursivePrefixTreeFieldType" geo="true"
> distErrPct="0.025" maxDistErr="0.09" units="degrees" />
>
> id
> name
>
>
> {code}
> query :
> {code}
> http://solr.dev:8983/solr/my_collection/select?wt=json=id=index_type:foobar=true=year_make_model=true=true=year
> {code}
> Exception :
> {code}
> ull:org.apache.solr.common.SolrException: Exception during facet.field: year
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:627)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:612)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:566)
> at
> org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:637)
> at
> org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:280)
> at
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:106)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
> 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
>
[jira] [Updated] (SOLR-7825) Use slf4j consistently
[ https://issues.apache.org/jira/browse/SOLR-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Schrenk updated SOLR-7825: - Attachment: slf4j.patch Use slf4j consistently -- Key: SOLR-7825 URL: https://issues.apache.org/jira/browse/SOLR-7825 Project: Solr Issue Type: Improvement Components: Server Affects Versions: 5.2.1 Reporter: Oliver Schrenk Priority: Minor Attachments: slf4j.patch There are a few classes that directly rely on log4j to be on the classpath instead and don't use the slf4j logging facade. This creates problems when trying to switch the logging implementation. 1. org.apache.solr.core.ZkContainer https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/core/ZkContainer.java#L218 I don't know the impact of this change, but shouldn't this call `org.apache.solr.logging.MDCLoggingContext.clear()` ? 2. org.apache.solr.handler.component.RangeFacetProcessor and org.apache.solr.handler.component.RangeFacetRequest should use slf4j instead of log4j I had a stab at it at https://github.com/oschrenk/lucene-solr/commit/025b4802caf0360c63a3554af82e9ed4c94ff5a3#diff-7d822e8ff8ff21d88437652bbc894739R28 -- This message was sent by Atlassian JIRA (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-7825) Use slf4j consistently
[
https://issues.apache.org/jira/browse/SOLR-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640504#comment-14640504
]
Oliver Schrenk commented on SOLR-7825:
--
The logging implementations of dependencies can't be changed. As you mentioned
though, not all is lost and these calls can be intercepted. I felt though that
at least core should strive for consistency in its logging usage. There are
actually not so many usages throughout the project
There are some instances in contrib
{code}
contrib/map-reduce/src/java/org/apache/solr/hadoop/MapReduceIndexerTool.java
contrib/map-reduce/src/java/org/apache/solr/hadoop/SolrRecordWriter.java
contrib/map-reduce/src/java/org/apache/solr/hadoop/Utils.java
{code}
or just used by contrib
{code}
core/src/java/org/apache/solr/util/SolrLogLayout.java
{code}
Then there are that are specific to log4j. Im not sure how they are used.
{code}
core/src/java/org/apache/solr/logging/log4j/EventAppender.java
core/src/java/org/apache/solr/logging/log4j/Log4jInfo.java:22
core/src/java/org/apache/solr/logging/log4j/Log4jWatcher.java
{code}
This is standalone
{code}
core/src/java/org/apache/solr/util/SolrCLI.java
{code}
Usages in test
{code}
core/src/test/org/apache/solr/cloud/ConcurrentDeleteAndCreateCollectionTest.java
core/src/test/org/apache/solr/handler/admin/LoggingHandlerTest.java
core/src/test/org/apache/solr/handler/RequestLoggingTest.java
{code}
I just thought I start because the one in ZkContainer was actually a nuisance
to me (because I wasn't aware of {{log4j-over-slf4}}
Use slf4j consistently
--
Key: SOLR-7825
URL: https://issues.apache.org/jira/browse/SOLR-7825
Project: Solr
Issue Type: Improvement
Components: Server
Affects Versions: 5.2.1
Reporter: Oliver Schrenk
Priority: Minor
Attachments: slf4j.patch
There are a few classes that directly rely on log4j to be on the classpath
instead and don't use the slf4j logging facade. This creates problems when
trying to switch the logging implementation.
1. org.apache.solr.core.ZkContainer
https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/core/ZkContainer.java#L218
I don't know the impact of this change, but shouldn't this call
`org.apache.solr.logging.MDCLoggingContext.clear()` ?
2. org.apache.solr.handler.component.RangeFacetProcessor and
org.apache.solr.handler.component.RangeFacetRequest
should use slf4j instead of log4j
I had a stab at it at
https://github.com/oschrenk/lucene-solr/commit/025b4802caf0360c63a3554af82e9ed4c94ff5a3#diff-7d822e8ff8ff21d88437652bbc894739R28
--
This message was sent by Atlassian JIRA
(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-7825) Use slf4j consistently
Oliver Schrenk created SOLR-7825: Summary: Use slf4j consistently Key: SOLR-7825 URL: https://issues.apache.org/jira/browse/SOLR-7825 Project: Solr Issue Type: Improvement Components: Server Affects Versions: 5.2.1 Reporter: Oliver Schrenk Priority: Minor There are a few classes that directly rely on log4j to be on the classpath instead and don't use the slf4j logging facade. This creates problems when trying to switch the logging implementation. 1. org.apache.solr.core.ZkContainer https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/core/ZkContainer.java#L218 I don't know the impact of this change, but shouldn't this call `org.apache.solr.logging.MDCLoggingContext.clear()` ? 2. org.apache.solr.handler.component.RangeFacetProcessor and org.apache.solr.handler.component.RangeFacetRequest should use slf4j instead of log4j I had a stab at it at https://github.com/oschrenk/lucene-solr/commit/025b4802caf0360c63a3554af82e9ed4c94ff5a3#diff-7d822e8ff8ff21d88437652bbc894739R28 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
