[jira] Resolved: (SOLR-194) SimplePostTool uses hardcoded UTF-8 encoding to read files
[ https://issues.apache.org/jira/browse/SOLR-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-194. Resolution: Fixed Per the comments above, this issue has been fixed already. SimplePostTool uses hardcoded UTF-8 encoding to read files -- Key: SOLR-194 URL: https://issues.apache.org/jira/browse/SOLR-194 Project: Solr Issue Type: Bug Components: clients - java Reporter: Bertrand Delacretaz Priority: Minor Attachments: post.jar Using java -Dfile.encoding=iso-8859-1 -jar post.jar http://localhost:8983/solr/update utf8-example.xml posts incorrect data, apparently utf8-example.xml is read using the JVM's encoding. As a workaround before we fix this, use java -Dfile.encoding=UTF-8 -jar post.jar http://localhost:8983/solr/update utf8-example.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-450) ArrayIndexOutOfBoundsException when search sometimes
[ https://issues.apache.org/jira/browse/SOLR-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-450: --- Attachment: SOLR-450.patch Changes QueryComponent#process to validate start parameter to be non-negative and throws exception otherwise. Is there any other change needed to close this issue? ArrayIndexOutOfBoundsException when search sometimes Key: SOLR-450 URL: https://issues.apache.org/jira/browse/SOLR-450 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Environment: win 2003 server. jdk1.6 Reporter: Eric Priority: Minor Attachments: SOLR-450.patch, solrconfig.xml Jan 3, 2008 1:39:44 PM org.apache.solr.common.SolrException log SEVERE: java.lang.ArrayIndexOutOfBoundsException: -1 at org.apache.solr.search.DocSlice$1.nextDoc(DocSlice.java:112) at org.apache.solr.util.SolrPluginUtils.optimizePreFetchDocs(SolrPluginUtils.java:255) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:112) at org.apache.solr.handler.SearchHandler.handleRequestBody(SearchHandler.java:98) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:117) at org.apache.solr.core.SolrCore.execute(SolrCore.java:815) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:206) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:174) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-950) Solr can throw an exception on distributed search due to bad if statement in FacetComponent.java:99
Solr can throw an exception on distributed search due to bad if statement in
FacetComponent.java:99
---
Key: SOLR-950
URL: https://issues.apache.org/jira/browse/SOLR-950
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4
Reporter: Jayson Minard
Priority: Critical
When issuing a distributed request, the aggregator node caused an exception due
to the following code at line 99 in FacetComponent.java
{code}
if (refList == null | refList.size()==0) continue;
{code}
(!) note the single pipe for a bitwise OR rather than boolean OR
Change code to:
{code}
if (refList == null || refList.size() == 0) continue;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-950) Solr can throw an exception on distributed search due to bad if statement in FacetComponent.java:99
[
https://issues.apache.org/jira/browse/SOLR-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayson Minard updated SOLR-950:
---
Affects Version/s: (was: 1.4)
1.3.1
Solr can throw an exception on distributed search due to bad if statement in
FacetComponent.java:99
---
Key: SOLR-950
URL: https://issues.apache.org/jira/browse/SOLR-950
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.3.1
Reporter: Jayson Minard
Priority: Critical
Fix For: 1.4
When issuing a distributed request, the aggregator node caused an exception
due to the following code at line 99 in FacetComponent.java
{code}
if (refList == null | refList.size()==0) continue;
{code}
(!) note the single pipe for a bitwise OR rather than boolean OR
Change code to:
{code}
if (refList == null || refList.size() == 0) continue;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-950) Solr can throw an exception on distributed search due to bad if statement in FacetComponent.java:99
[
https://issues.apache.org/jira/browse/SOLR-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-950:
---
Affects Version/s: (was: 1.3.1)
1.3
Solr can throw an exception on distributed search due to bad if statement in
FacetComponent.java:99
---
Key: SOLR-950
URL: https://issues.apache.org/jira/browse/SOLR-950
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.3
Reporter: Jayson Minard
Assignee: Shalin Shekhar Mangar
Priority: Critical
Fix For: 1.4
When issuing a distributed request, the aggregator node caused an exception
due to the following code at line 99 in FacetComponent.java
{code}
if (refList == null | refList.size()==0) continue;
{code}
(!) note the single pipe for a bitwise OR rather than boolean OR
Change code to:
{code}
if (refList == null || refList.size() == 0) continue;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-599) Lightweight SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662325#action_12662325 ] Shalin Shekhar Mangar commented on SOLR-599: With SOLR-865 coming in, we can use binary format for both searching and indexing. The solr-commons jar has already been removed and merged with the solrj jar. I think a lightweight client makes sense once again. The only gotcha is that we require slf4j as a dependency. Lightweight SolrJ client Key: SOLR-599 URL: https://issues.apache.org/jira/browse/SOLR-599 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Priority: Minor SolrJ provides a SolrServer implementation backed by commons-httpclient which introduces many dependency jars (commons-codec, commons-io and commons-logging). Apart from that SolrJ also uses StAX API for XML parsing which introduces dependencies like stax-api, stax and stax-utils. This enhancement will add a SolrServer implementation backed by java.net.HttpUrlConnection and will use BinaryResponseParser as the default response parser. Using this basic implementation out of the box would require no dependencies on either commons-httpclient or StAX. The only dependency would be on solr-commons making this a very lightweight and distribution friendly Java client for Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-951) Distributed query fails with tag / exclude pattern used for facets that are multi-valued.
Distributed query fails with tag / exclude pattern used for facets that are
multi-valued.
-
Key: SOLR-951
URL: https://issues.apache.org/jira/browse/SOLR-951
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.3.1
Reporter: Jayson Minard
Priority: Critical
Running this query:
{code}
http://testserver:8985/solr/select/?q=*%3A*version=2.2start=0rows=10indent=onfacet=truefacet.field={!ex=t1}SubjectTerms_mfacetfq={!tag=t1}SubjectTerms_mfacet:(testvalue)shards=test1:8985/solr,test2:8985/solr
{code}
causes this exception:
{code}
java.lang.NullPointerException
at
org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:330)
at
org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:231)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:266)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1325)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
{code}
which is at this area of the code in the aggregator, but not the root cause...
{code}
private void refineFacets(ResponseBuilder rb, ShardRequest sreq) {
FacetInfo fi = rb._facetInfo;
for (ShardResponse srsp: sreq.responses) {
// int shardNum = rb.getShardNum(srsp.shard);
NamedList facet_counts =
(NamedList)srsp.getSolrResponse().getResponse().get(facet_counts);
NamedList facet_fields = (NamedList)facet_counts.get(facet_fields);
for (int i=0; ifacet_fields.size(); i++) { // !
EXCEPTION LINE 330
String key = facet_fields.getName(i);
DistribFieldFacet dff = (DistribFieldFacet)fi.facets.get(key);
if (dff == null) continue;
NamedList shardCounts = (NamedList)facet_fields.getVal(i);
for (int j=0; jshardCounts.size(); j++) {
String name = shardCounts.getName(j);
long count = ((Number)shardCounts.getVal(j)).longValue();
ShardFacetCount sfc = dff.counts.get(name);
sfc.count += count;
}
}
}
}
{code}
The shard actually has an error on it, which is:
{code}
Jan 9, 2009 6:15:31 AM org.apache.solr.core.SolrCore execute
INFO: [] webapp=/solr path=/select
params={facet=truef.SubjectTerms_mfacet.facet.limit=160wt=javabinrows=10version=2.2fl=id,scorestart=0q=*:*facet.field={!ex%3Dt1}SubjectTerms_mfacetisShard=truefq={!tag%3Dt1}SubjectTerms_mfacet:(testvalue)fsv=true}
hits=0 status=0 QTime=265
Jan 9, 2009 6:15:31 AM org.apache.solr.common.SolrException log
SEVERE: Exception during facet
counts:org.apache.lucene.queryParser.ParseException: Expected identifier at pos
37 str='{!terms=$SubjectTerms_mfacet__termsex=t1}SubjectTerms_mfacet'
at
org.apache.solr.search.QueryParsing$StrParser.getId(QueryParsing.java:564)
at
org.apache.solr.search.QueryParsing.parseLocalParams(QueryParsing.java:135)
at
org.apache.solr.search.QueryParsing.getLocalParams(QueryParsing.java:191)
at
org.apache.solr.request.SimpleFacets.parseParams(SimpleFacets.java:91)
at
[jira] Commented: (SOLR-949) Add QueryResponse and SolrQuery support for TermVectorComponent
[ https://issues.apache.org/jira/browse/SOLR-949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662331#action_12662331 ] Shalin Shekhar Mangar commented on SOLR-949: bq. One note: I intended to use TermVectorComponent.COMPONENT_NAME in SolrQuery, but ant would not compile because it complained about not being able to find the package: package org.apache.solr.handler.component does not exist The Solrj client is compiled separately from the core solr source to avoid any dependency to the (large) core jar. The package you wanted to use is not in solrj's compile classpath. Add QueryResponse and SolrQuery support for TermVectorComponent --- Key: SOLR-949 URL: https://issues.apache.org/jira/browse/SOLR-949 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Aleksander M. Stensby Priority: Minor Attachments: SOLR-949.patch In a similar fashion to Facet information, it would be nice to have support for easily setting TermVector related parameters through SolrQuery, and it would be nice to have methods in QueryResponse to easily retrieve TermVector information -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-951) Distributed query fails with tag / exclude pattern used for facets that are multi-valued.
[
https://issues.apache.org/jira/browse/SOLR-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayson Minard updated SOLR-951:
---
Description:
Running this query:
{code}
http://testserver:8985/solr/select/?q=*%3A*version=2.2start=0rows=10indent=onfacet=true;
facet.field={!ex=t1}SubjectTerms_mfacetfq={!tag=t1}SubjectTerms_mfacet:(testvalue)
shards=test1:8985/solr,test2:8985/solr
{code}
causes this exception:
{code}
java.lang.NullPointerException
at
org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:330)
at
org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:231)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:266)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1325)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
{code}
which is at this area of the code in the aggregator, but not the root cause...
{code}
private void refineFacets(ResponseBuilder rb, ShardRequest sreq) {
FacetInfo fi = rb._facetInfo;
for (ShardResponse srsp: sreq.responses) {
// int shardNum = rb.getShardNum(srsp.shard);
NamedList facet_counts =
(NamedList)srsp.getSolrResponse().getResponse().get(facet_counts);
NamedList facet_fields = (NamedList)facet_counts.get(facet_fields);
for (int i=0; ifacet_fields.size(); i++) { // !
EXCEPTION LINE 330
String key = facet_fields.getName(i);
DistribFieldFacet dff = (DistribFieldFacet)fi.facets.get(key);
if (dff == null) continue;
NamedList shardCounts = (NamedList)facet_fields.getVal(i);
for (int j=0; jshardCounts.size(); j++) {
String name = shardCounts.getName(j);
long count = ((Number)shardCounts.getVal(j)).longValue();
ShardFacetCount sfc = dff.counts.get(name);
sfc.count += count;
}
}
}
}
{code}
The shard actually has an error on it, which is:
{code}
Jan 9, 2009 6:15:31 AM org.apache.solr.core.SolrCore execute
INFO: [] webapp=/solr path=/select
params={facet=truef.SubjectTerms_mfacet.facet.limit=160wt=javabinrows=10
version=2.2fl=id,scorestart=0q=*:*
facet.field={!ex%3Dt1}SubjectTerms_mfacetisShard=truefq={!tag%3Dt1}SubjectTerms_mfacet:(testvalue)
fsv=true} hits=0 status=0 QTime=265
Jan 9, 2009 6:15:31 AM org.apache.solr.common.SolrException log
SEVERE: Exception during facet
counts:org.apache.lucene.queryParser.ParseException: Expected identifier at pos
37 str='{!terms=$SubjectTerms_mfacet__termsex=t1}SubjectTerms_mfacet'
at
org.apache.solr.search.QueryParsing$StrParser.getId(QueryParsing.java:564)
at
org.apache.solr.search.QueryParsing.parseLocalParams(QueryParsing.java:135)
at
org.apache.solr.search.QueryParsing.getLocalParams(QueryParsing.java:191)
at
org.apache.solr.request.SimpleFacets.parseParams(SimpleFacets.java:91)
at
org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:275)
at
org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:170)
at
org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:71)
at
[jira] Commented: (SOLR-951) Distributed query fails with tag / exclude pattern used for facets that are multi-valued.
[
https://issues.apache.org/jira/browse/SOLR-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662337#action_12662337
]
Jayson Minard commented on SOLR-951:
Ok, looking at QueryParsing.java and ...
parseLocalParams() finds the start of an ID and then calls getId() to retrieve
it, but getId() doesn't know when to end (i.e. on = or }) so it eats until
it hits an unexpected java identifier character (in this case =) and bombs
with the exception.
THere either needs to be a special getId() function that knows when to quit
nicely, or getId() changed to have valid end tokens where it stops politely
rather than as an error.
I'm testing the quick variant function just for the localParams to work around
this for now.
Distributed query fails with tag / exclude pattern used for facets that are
multi-valued.
-
Key: SOLR-951
URL: https://issues.apache.org/jira/browse/SOLR-951
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.3.1
Reporter: Jayson Minard
Priority: Critical
Running this query:
{code}
http://testserver:8985/solr/select/?q=*%3A*version=2.2start=0rows=10indent=onfacet=true;
facet.field={!ex=t1}SubjectTerms_mfacetfq={!tag=t1}SubjectTerms_mfacet:(testvalue)
shards=test1:8985/solr,test2:8985/solr
{code}
causes this exception:
{code}
java.lang.NullPointerException
at
org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:330)
at
org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:231)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:266)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1325)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
{code}
which is at this area of the code in the aggregator, but not the root cause...
{code}
private void refineFacets(ResponseBuilder rb, ShardRequest sreq) {
FacetInfo fi = rb._facetInfo;
for (ShardResponse srsp: sreq.responses) {
// int shardNum = rb.getShardNum(srsp.shard);
NamedList facet_counts =
(NamedList)srsp.getSolrResponse().getResponse().get(facet_counts);
NamedList facet_fields = (NamedList)facet_counts.get(facet_fields);
for (int i=0; ifacet_fields.size(); i++) { // !
EXCEPTION LINE 330
String key = facet_fields.getName(i);
DistribFieldFacet dff = (DistribFieldFacet)fi.facets.get(key);
if (dff == null) continue;
NamedList shardCounts = (NamedList)facet_fields.getVal(i);
for (int j=0; jshardCounts.size(); j++) {
String name = shardCounts.getName(j);
long count = ((Number)shardCounts.getVal(j)).longValue();
ShardFacetCount sfc = dff.counts.get(name);
sfc.count += count;
}
}
}
}
{code}
The shard actually has an error on it, which is:
{code}
Jan 9, 2009 6:15:31 AM org.apache.solr.core.SolrCore execute
INFO: [] webapp=/solr path=/select
[jira] Updated: (SOLR-951) Distributed query fails with tag / exclude pattern used for facets that are multi-valued.
[
https://issues.apache.org/jira/browse/SOLR-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayson Minard updated SOLR-951:
---
Comment: was deleted
Distributed query fails with tag / exclude pattern used for facets that are
multi-valued.
-
Key: SOLR-951
URL: https://issues.apache.org/jira/browse/SOLR-951
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.3.1
Reporter: Jayson Minard
Priority: Critical
Running this query:
{code}
http://testserver:8985/solr/select/?q=*%3A*version=2.2start=0rows=10indent=onfacet=true;
facet.field={!ex=t1}SubjectTerms_mfacetfq={!tag=t1}SubjectTerms_mfacet:(testvalue)
shards=test1:8985/solr,test2:8985/solr
{code}
causes this exception:
{code}
java.lang.NullPointerException
at
org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:330)
at
org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:231)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:266)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1325)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
{code}
which is at this area of the code in the aggregator, but not the root cause...
{code}
private void refineFacets(ResponseBuilder rb, ShardRequest sreq) {
FacetInfo fi = rb._facetInfo;
for (ShardResponse srsp: sreq.responses) {
// int shardNum = rb.getShardNum(srsp.shard);
NamedList facet_counts =
(NamedList)srsp.getSolrResponse().getResponse().get(facet_counts);
NamedList facet_fields = (NamedList)facet_counts.get(facet_fields);
for (int i=0; ifacet_fields.size(); i++) { // !
EXCEPTION LINE 330
String key = facet_fields.getName(i);
DistribFieldFacet dff = (DistribFieldFacet)fi.facets.get(key);
if (dff == null) continue;
NamedList shardCounts = (NamedList)facet_fields.getVal(i);
for (int j=0; jshardCounts.size(); j++) {
String name = shardCounts.getName(j);
long count = ((Number)shardCounts.getVal(j)).longValue();
ShardFacetCount sfc = dff.counts.get(name);
sfc.count += count;
}
}
}
}
{code}
The shard actually has an error on it, which is:
{code}
Jan 9, 2009 6:15:31 AM org.apache.solr.core.SolrCore execute
INFO: [] webapp=/solr path=/select
params={facet=truef.SubjectTerms_mfacet.facet.limit=160wt=javabinrows=10
version=2.2fl=id,scorestart=0q=*:*
facet.field={!ex%3Dt1}SubjectTerms_mfacetisShard=truefq={!tag%3Dt1}SubjectTerms_mfacet:(testvalue)
fsv=true} hits=0 status=0 QTime=265
Jan 9, 2009 6:15:31 AM org.apache.solr.common.SolrException log
SEVERE: Exception during facet
counts:org.apache.lucene.queryParser.ParseException: Expected identifier at
pos 37 str='{!terms=$SubjectTerms_mfacet__termsex=t1}SubjectTerms_mfacet'
at
org.apache.solr.search.QueryParsing$StrParser.getId(QueryParsing.java:564)
at
[jira] Commented: (SOLR-951) Distributed query fails with tag / exclude pattern used for facets that are multi-valued.
[
https://issues.apache.org/jira/browse/SOLR-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662344#action_12662344
]
Jayson Minard commented on SOLR-951:
ok so if the string being parsed is:
{code}
{!terms=$SubjectTerms_mfacet__termsex=t1}SubjectTerms_mfacet
{code}
And this enters parseLocalParams() in QueryParsing...
It would see the {! and then start parsing the remainder
terms=$SubjectTerms_mfacet__termsex=t1}SubjectTerms_mfacet using the first
getId call which succeeds and finds terms and then the = via the peek, and
then enters the if that sees the $ and decides to dereference the parameter.
It immediately calls getId() again which pulls out
$SubjectTerms_mfacet__termsex and then loops to the top of the loop and calls
getId() a second time picking up the final = which is then an error. So,
something is missing in the parameters. Is ex=t1 another parameter and
should have a delimiter? Ah, it should have a space between there somewhere.
So the parsing is fine, but the creation of the string isn't. Searching
upwards the stack trace now.
Distributed query fails with tag / exclude pattern used for facets that are
multi-valued.
-
Key: SOLR-951
URL: https://issues.apache.org/jira/browse/SOLR-951
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.3.1
Reporter: Jayson Minard
Priority: Critical
Running this query:
{code}
http://testserver:8985/solr/select/?q=*%3A*version=2.2start=0rows=10indent=onfacet=true;
facet.field={!ex=t1}SubjectTerms_mfacetfq={!tag=t1}SubjectTerms_mfacet:(testvalue)
shards=test1:8985/solr,test2:8985/solr
{code}
causes this exception:
{code}
java.lang.NullPointerException
at
org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:330)
at
org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:231)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:266)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1325)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
{code}
which is at this area of the code in the aggregator, but not the root cause...
{code}
private void refineFacets(ResponseBuilder rb, ShardRequest sreq) {
FacetInfo fi = rb._facetInfo;
for (ShardResponse srsp: sreq.responses) {
// int shardNum = rb.getShardNum(srsp.shard);
NamedList facet_counts =
(NamedList)srsp.getSolrResponse().getResponse().get(facet_counts);
NamedList facet_fields = (NamedList)facet_counts.get(facet_fields);
for (int i=0; ifacet_fields.size(); i++) { // !
EXCEPTION LINE 330
String key = facet_fields.getName(i);
DistribFieldFacet dff = (DistribFieldFacet)fi.facets.get(key);
if (dff == null) continue;
NamedList shardCounts = (NamedList)facet_fields.getVal(i);
for (int j=0; jshardCounts.size(); j++) {
String name = shardCounts.getName(j);
long count =
[jira] Commented: (SOLR-951) Distributed query fails with tag / exclude pattern used for facets that are multi-valued.
[
https://issues.apache.org/jira/browse/SOLR-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662349#action_12662349
]
Jayson Minard commented on SOLR-951:
Ok, FacetComponent.java creates the parameter that is passed down and adds the
__terms that is at the end of the original tag. Just below that on line 108
is the place where it appends the new parameters to the existing.
{code}
if (dff.localParams != null) {
facetCommand = commandPrefix+termsKey+dff.facetStr.substring(2);
} else {
facetCommand = commandPrefix+termsKey+'}'+dff.field;
}
{code}
should have white space between the params, such as...
{code}
if (dff.localParams != null) {
facetCommand = commandPrefix+termsKey+ +dff.facetStr.substring(2);
} else {
facetCommand = commandPrefix+termsKey+'}'+dff.field;
}
{code}
I tested this fix and it no longer throws an exception, I have not tested that
it ensures the tag/exclude feature still works though.
Distributed query fails with tag / exclude pattern used for facets that are
multi-valued.
-
Key: SOLR-951
URL: https://issues.apache.org/jira/browse/SOLR-951
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.3.1
Reporter: Jayson Minard
Priority: Critical
Running this query:
{code}
http://testserver:8985/solr/select/?q=*%3A*version=2.2start=0rows=10indent=onfacet=true;
facet.field={!ex=t1}SubjectTerms_mfacetfq={!tag=t1}SubjectTerms_mfacet:(testvalue)
shards=test1:8985/solr,test2:8985/solr
{code}
causes this exception:
{code}
java.lang.NullPointerException
at
org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:330)
at
org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:231)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:266)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1325)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
{code}
which is at this area of the code in the aggregator, but not the root cause...
{code}
private void refineFacets(ResponseBuilder rb, ShardRequest sreq) {
FacetInfo fi = rb._facetInfo;
for (ShardResponse srsp: sreq.responses) {
// int shardNum = rb.getShardNum(srsp.shard);
NamedList facet_counts =
(NamedList)srsp.getSolrResponse().getResponse().get(facet_counts);
NamedList facet_fields = (NamedList)facet_counts.get(facet_fields);
for (int i=0; ifacet_fields.size(); i++) { // !
EXCEPTION LINE 330
String key = facet_fields.getName(i);
DistribFieldFacet dff = (DistribFieldFacet)fi.facets.get(key);
if (dff == null) continue;
NamedList shardCounts = (NamedList)facet_fields.getVal(i);
for (int j=0; jshardCounts.size(); j++) {
String name = shardCounts.getName(j);
long count = ((Number)shardCounts.getVal(j)).longValue();
[jira] Commented: (SOLR-950) Solr can throw an exception on distributed search due to bad if statement in FacetComponent.java:99
[
https://issues.apache.org/jira/browse/SOLR-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662350#action_12662350
]
Jayson Minard commented on SOLR-950:
Shalin, thanks for committing the fix.
Solr can throw an exception on distributed search due to bad if statement in
FacetComponent.java:99
---
Key: SOLR-950
URL: https://issues.apache.org/jira/browse/SOLR-950
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.3
Reporter: Jayson Minard
Assignee: Shalin Shekhar Mangar
Priority: Critical
Fix For: 1.4
When issuing a distributed request, the aggregator node caused an exception
due to the following code at line 99 in FacetComponent.java
{code}
if (refList == null | refList.size()==0) continue;
{code}
(!) note the single pipe for a bitwise OR rather than boolean OR
Change code to:
{code}
if (refList == null || refList.size() == 0) continue;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Issue Comment Edited: (SOLR-938) DataImportHandler: Add close hooks to the completion of a full-import process
Great. How about having an enum for Context (as compared to int) for type safety. Noble Paul (JIRA) wrote: [ https://issues.apache.org/jira/browse/SOLR-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662224#action_12662224 ] noble.paul edited comment on SOLR-938 at 1/8/09 6:10 PM: - =Context#currentProcess() can tell you what is going on now. was (Author: noble.paul): the Context can tell you which one is going on. Context#currentProcess() can tell you what is going on now. DataImportHandler: Add close hooks to the completion of a full-import process -- Key: SOLR-938 URL: https://issues.apache.org/jira/browse/SOLR-938 Project: Solr Issue Type: New Feature Components: contrib - DataImportHandler Affects Versions: 1.4 Environment: JRE 6, Tomcat 6 Reporter: Kay Kay Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: SOLR-938.patch, SOLR-938.patch, SOLR-938.patch, SOLR-938.patch Original Estimate: 48h Remaining Estimate: 48h Adding a new feature that we need for continuation of a workflow based on a full-import procedure. When a full-import completes , the pre-defined hook method is called at the end of the same. Implementations that need to notified , need to implement the new interface - DataImportCloseHook and register themselves in the data config file as follows. dataConfig . . . . closeHook type=com.myorg.fullimporter.closeHookImpl1 / closeHook type=com.myorg.fullimporter.closeHookImpl2 / /dataConfig A single instance of them is created (as part of DataImporter) during instantiation and the same insance is reused across multiple invocations. Since the dataImporter is protected by a thread-lock - there is no thred-safe guarantee for the implementations of the full-import close hook.
[jira] Closed: (SOLR-938) DataImportHandler: Add close hooks to the completion of a full-import process
[ https://issues.apache.org/jira/browse/SOLR-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay closed SOLR-938. DataImportHandler: Add close hooks to the completion of a full-import process -- Key: SOLR-938 URL: https://issues.apache.org/jira/browse/SOLR-938 Project: Solr Issue Type: New Feature Components: contrib - DataImportHandler Affects Versions: 1.4 Environment: JRE 6, Tomcat 6 Reporter: Kay Kay Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: SOLR-938.patch, SOLR-938.patch, SOLR-938.patch, SOLR-938.patch Original Estimate: 48h Remaining Estimate: 48h Adding a new feature that we need for continuation of a workflow based on a full-import procedure. When a full-import completes , the pre-defined hook method is called at the end of the same. Implementations that need to notified , need to implement the new interface - DataImportCloseHook and register themselves in the data config file as follows. dataConfig . . . . closeHook type=com.myorg.fullimporter.closeHookImpl1 / closeHook type=com.myorg.fullimporter.closeHookImpl2 / /dataConfig A single instance of them is created (as part of DataImporter) during instantiation and the same insance is reused across multiple invocations. Since the dataImporter is protected by a thread-lock - there is no thred-safe guarantee for the implementations of the full-import close hook. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-247) Allow facet.field=* to facet on all fields (without knowing what they are)
[ https://issues.apache.org/jira/browse/SOLR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Kotthoff updated SOLR-247: --- Attachment: SOLR-247.patch Syncing patch with trunk. Allow facet.field=* to facet on all fields (without knowing what they are) -- Key: SOLR-247 URL: https://issues.apache.org/jira/browse/SOLR-247 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Priority: Minor Attachments: SOLR-247-FacetAllFields.patch, SOLR-247.patch, SOLR-247.patch, SOLR-247.patch I don't know if this is a good idea to include -- it is potentially a bad idea to use it, but that can be ok. This came out of trying to use faceting for the LukeRequestHandler top term collecting. http://www.nabble.com/Luke-request-handler-issue-tf3762155.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-650) facet.field should accept field names separated by spaces or commas
[ https://issues.apache.org/jira/browse/SOLR-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Kotthoff updated SOLR-650: --- Attachment: SOLR-650.patch Syncing patch with trunk. facet.field should accept field names separated by spaces or commas --- Key: SOLR-650 URL: https://issues.apache.org/jira/browse/SOLR-650 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Reporter: Lars Kotthoff Priority: Minor Attachments: SOLR-650.patch, SOLR-650.patch, SOLR-650.patch The current version of SimpleFacets does not support specifying several fields to facet on in a single facet.field parameter; it has to be specified for each field. This behaviour is inconcistent with the other parameters which accept field names as arguments -- they allow specifying multiple field names either as a comma- or space-separated list or by specifying the parameter multiple times. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-705) Distributed search should optionally return docID-shard map
[ https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Kotthoff updated SOLR-705: --- Attachment: SOLR-705.patch Syncing patch with trunk. Distributed search should optionally return docID-shard map Key: SOLR-705 URL: https://issues.apache.org/jira/browse/SOLR-705 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Environment: all Reporter: Brian Whitman Fix For: 1.4 Attachments: SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, SOLR-705.patch SOLR-303 queries with shards parameters set need to return the dociD-shard mapping in the response. Without it, updating/deleting documents when the # of shards is variable is hard. We currently set this with a special requestHandler that filters /update and inserts the shard as a field in the index but it would be better if the shard location came back in the query response outside of the index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-247) Allow facet.field=* to facet on all fields (without knowing what they are)
[ https://issues.apache.org/jira/browse/SOLR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662516#action_12662516 ] Shalin Shekhar Mangar commented on SOLR-247: Lars, I see you have been updating the patches to trunk diligently. However, I'm not sure if there is a consensus on adding this without having a glob like feature in place. Do you have a use-case in mind which can be solved only with the current patch? Allow facet.field=* to facet on all fields (without knowing what they are) -- Key: SOLR-247 URL: https://issues.apache.org/jira/browse/SOLR-247 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Priority: Minor Attachments: SOLR-247-FacetAllFields.patch, SOLR-247.patch, SOLR-247.patch, SOLR-247.patch I don't know if this is a good idea to include -- it is potentially a bad idea to use it, but that can be ok. This came out of trying to use faceting for the LukeRequestHandler top term collecting. http://www.nabble.com/Luke-request-handler-issue-tf3762155.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-247) Allow facet.field=* to facet on all fields (without knowing what they are)
[ https://issues.apache.org/jira/browse/SOLR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662518#action_12662518 ] Lars Kotthoff commented on SOLR-247: Off the top of my head, having an automated feed parser which adds fields and facet_field to facet on. I agree that all this should be part of a global glob-like thing, but that would probably only apply to the part which parses the parameters anyway. How a glob is matched depends on the type of glob (i.e. whether the field is indexed/stored/... and we want to facet/highlight/...). If people start using it and it turns out to be important, it can always be refactored into something more general. If nobody uses globbing, there'd be no need to invest the effort of making it general :) Allow facet.field=* to facet on all fields (without knowing what they are) -- Key: SOLR-247 URL: https://issues.apache.org/jira/browse/SOLR-247 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Priority: Minor Attachments: SOLR-247-FacetAllFields.patch, SOLR-247.patch, SOLR-247.patch, SOLR-247.patch I don't know if this is a good idea to include -- it is potentially a bad idea to use it, but that can be ok. This came out of trying to use faceting for the LukeRequestHandler top term collecting. http://www.nabble.com/Luke-request-handler-issue-tf3762155.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-950) Solr can throw an exception on distributed search due to bad if statement in FacetComponent.java:99
[
https://issues.apache.org/jira/browse/SOLR-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662520#action_12662520
]
Yonik Seeley commented on SOLR-950:
---
I believe this bug was in unreleased code only (probably introduced through my
changes to support multi-select faceting)?
That should somehow be made clear in CHANGES.txt so people don't think this was
a 1.3 bug.
Solr can throw an exception on distributed search due to bad if statement in
FacetComponent.java:99
---
Key: SOLR-950
URL: https://issues.apache.org/jira/browse/SOLR-950
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.3
Reporter: Jayson Minard
Assignee: Shalin Shekhar Mangar
Priority: Critical
Fix For: 1.4
When issuing a distributed request, the aggregator node caused an exception
due to the following code at line 99 in FacetComponent.java
{code}
if (refList == null | refList.size()==0) continue;
{code}
(!) note the single pipe for a bitwise OR rather than boolean OR
Change code to:
{code}
if (refList == null || refList.size() == 0) continue;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-950) Solr can throw an exception on distributed search due to bad if statement in FacetComponent.java:99
[
https://issues.apache.org/jira/browse/SOLR-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662521#action_12662521
]
Shalin Shekhar Mangar commented on SOLR-950:
You are right Yonik. This was introduced after 1.3 was released. I'll update
the changelog.
Solr can throw an exception on distributed search due to bad if statement in
FacetComponent.java:99
---
Key: SOLR-950
URL: https://issues.apache.org/jira/browse/SOLR-950
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.3
Reporter: Jayson Minard
Assignee: Shalin Shekhar Mangar
Priority: Critical
Fix For: 1.4
When issuing a distributed request, the aggregator node caused an exception
due to the following code at line 99 in FacetComponent.java
{code}
if (refList == null | refList.size()==0) continue;
{code}
(!) note the single pipe for a bitwise OR rather than boolean OR
Change code to:
{code}
if (refList == null || refList.size() == 0) continue;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-952) TokenOrderingFilter class is defined in more than one java file
TokenOrderingFilter class is defined in more than one java file --- Key: SOLR-952 URL: https://issues.apache.org/jira/browse/SOLR-952 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 1.4 Reporter: Chris Harris Priority: Minor The class TokenOrderingFilter is defined, with identical text, both in org/apache/solr/highlight/DefaultSolrHighlighter.java and org/apache/solr/util/HighlightingUtils.java. I assume this is not good, from a code maintenance perspective. Verified this in Solr trunk r733155. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-952) TokenOrderingFilter class is defined in more than one java file
[ https://issues.apache.org/jira/browse/SOLR-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662555#action_12662555 ] Chris Harris commented on SOLR-952: --- I did a brief look through the svn logs: * The class started (I think) in org/apache/solr/util/SolrPluginUtils.java * In r510338 it was moved moved to org/apache/solr/util/HighlightingUtils.java. * In r639490 org/apache/solr/highlight/DefaultSolrHighlighter.java was created and the econd copy was added there; this revision did not, however, touch org/apache/solr/util/HighlightingUtils.java TokenOrderingFilter class is defined in more than one java file --- Key: SOLR-952 URL: https://issues.apache.org/jira/browse/SOLR-952 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 1.4 Reporter: Chris Harris Priority: Minor The class TokenOrderingFilter is defined, with identical text, both in org/apache/solr/highlight/DefaultSolrHighlighter.java and org/apache/solr/util/HighlightingUtils.java. I assume this is not good, from a code maintenance perspective. Verified this in Solr trunk r733155. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-952) TokenOrderingFilter class is defined in more than one java file
[ https://issues.apache.org/jira/browse/SOLR-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662555#action_12662555 ] ryguasu edited comment on SOLR-952 at 1/9/09 3:37 PM: --- I did a brief look through the svn logs: * In r448, the class was first added. It was added to org/apache/solr/util/SolrPluginUtils.java. The purpose of this commit was: order tokens by startOffset when highlighting * In r510338 it was moved moved to org/apache/solr/util/HighlightingUtils.java. * In r639490 org/apache/solr/highlight/DefaultSolrHighlighter.java was created and the econd copy was added there; this revision did not, however, touch org/apache/solr/util/HighlightingUtils.java was (Author: ryguasu): I did a brief look through the svn logs: * The class started (I think) in org/apache/solr/util/SolrPluginUtils.java * In r510338 it was moved moved to org/apache/solr/util/HighlightingUtils.java. * In r639490 org/apache/solr/highlight/DefaultSolrHighlighter.java was created and the econd copy was added there; this revision did not, however, touch org/apache/solr/util/HighlightingUtils.java TokenOrderingFilter class is defined in more than one java file --- Key: SOLR-952 URL: https://issues.apache.org/jira/browse/SOLR-952 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 1.4 Reporter: Chris Harris Priority: Minor The class TokenOrderingFilter is defined, with identical text, both in org/apache/solr/highlight/DefaultSolrHighlighter.java and org/apache/solr/util/HighlightingUtils.java. I assume this is not good, from a code maintenance perspective. Verified this in Solr trunk r733155. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-952) TokenOrderingFilter class is defined in more than one java file
[ https://issues.apache.org/jira/browse/SOLR-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662555#action_12662555 ] ryguasu edited comment on SOLR-952 at 1/9/09 3:39 PM: --- I did a brief look through the svn logs: * In r422248, the class was first added. It was added to org/apache/solr/util/SolrPluginUtils.java. The purpose of this commit was: order tokens by startOffset when highlighting * In r510338 it was moved moved to org/apache/solr/util/HighlightingUtils.java. * In r639490 org/apache/solr/highlight/DefaultSolrHighlighter.java was created and the econd copy was added there; this revision did not, however, touch org/apache/solr/util/HighlightingUtils.java was (Author: ryguasu): I did a brief look through the svn logs: * In r448, the class was first added. It was added to org/apache/solr/util/SolrPluginUtils.java. The purpose of this commit was: order tokens by startOffset when highlighting * In r510338 it was moved moved to org/apache/solr/util/HighlightingUtils.java. * In r639490 org/apache/solr/highlight/DefaultSolrHighlighter.java was created and the econd copy was added there; this revision did not, however, touch org/apache/solr/util/HighlightingUtils.java TokenOrderingFilter class is defined in more than one java file --- Key: SOLR-952 URL: https://issues.apache.org/jira/browse/SOLR-952 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 1.4 Reporter: Chris Harris Priority: Minor The class TokenOrderingFilter is defined, with identical text, both in org/apache/solr/highlight/DefaultSolrHighlighter.java and org/apache/solr/util/HighlightingUtils.java. I assume this is not good, from a code maintenance perspective. Verified this in Solr trunk r733155. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-947) QueryParsing.toString() should check ConstantScoreRangeQuery before RangeQuery
[
https://issues.apache.org/jira/browse/SOLR-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-947:
Affects Version/s: (was: 1.3)
1.4
bq. Ah, this was introduced when Lucene changed ConstantScoreRangeQuery to
inherit from RangeQuery.
Thanks Yonik for the input. I've changed affects version as 1.4 and removed the
log from CHANGES.txt.
QueryParsing.toString() should check ConstantScoreRangeQuery before RangeQuery
--
Key: SOLR-947
URL: https://issues.apache.org/jira/browse/SOLR-947
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4
Reporter: Koji Sekiguchi
Assignee: Koji Sekiguchi
Priority: Minor
Fix For: 1.4
Attachments: SOLR-947.patch
This
{code:title=QueryParsing.toString()}
if (query instanceof TermQuery) {
:
} else if (query instanceof RangeQuery) {
:
} else if (query instanceof ConstantScoreRangeQuery) {
:
}
:
{code}
should be
{code:title=QueryParsing.toString()}
if (query instanceof TermQuery) {
:
} else if (query instanceof ConstantScoreRangeQuery) {
:
} else if (query instanceof RangeQuery) {
:
}
:
{code}
This causes NPE when open ended range query (price:[1 TO *]) with
debugQuery=on.
This is reported on the thread:
http://www.nabble.com/http-internal-error-if-i-enable-debugQuery%3Don-td21210570.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-308) Add a field that generates an unique id when you have none in your data to index
[ https://issues.apache.org/jira/browse/SOLR-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662615#action_12662615 ] Lance Norskog commented on SOLR-308: This field type and its use is not documented in the Wiki: search for 'UUID' finds only custom code in ExtractingRequestHandler. Add a field that generates an unique id when you have none in your data to index Key: SOLR-308 URL: https://issues.apache.org/jira/browse/SOLR-308 Project: Solr Issue Type: New Feature Components: search Reporter: Thomas Peuss Assignee: Hoss Man Priority: Minor Fix For: 1.3 Attachments: UUIDField.patch, UUIDField.patch, UUIDField.patch, UUIDField.patch, UUIDField.patch This patch adds a field that generates an unique id when you have no unique id in your data you want to index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-308) Add a field that generates an unique id when you have none in your data to index
[ https://issues.apache.org/jira/browse/SOLR-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662626#action_12662626 ] Otis Gospodnetic commented on SOLR-308: --- Lance - anyone can add/modify a Wiki page. Do you mind adding info about this field type? Add a field that generates an unique id when you have none in your data to index Key: SOLR-308 URL: https://issues.apache.org/jira/browse/SOLR-308 Project: Solr Issue Type: New Feature Components: search Reporter: Thomas Peuss Assignee: Hoss Man Priority: Minor Fix For: 1.3 Attachments: UUIDField.patch, UUIDField.patch, UUIDField.patch, UUIDField.patch, UUIDField.patch This patch adds a field that generates an unique id when you have no unique id in your data you want to index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
