[jira] Updated: (SOLR-1120) Simplify EntityProcessor API
[ https://issues.apache.org/jira/browse/SOLR-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1120: - Attachment: SOLR-1120.patch Simplify EntityProcessor API Key: SOLR-1120 URL: https://issues.apache.org/jira/browse/SOLR-1120 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch Writing an EntityProcessor is deceptively complex. There are so many gotchas. I propose the following: # Extract out the Transformer application logic from EntityProcessor and add it to DocBuilder. Then EntityProcessor do not need to call applyTransformer or know about rowIterator and getFromRowCache() methods. # Change the meaning of EntityProcessor#destroy to be called on end of parent's row -- Right now init is called once per parent row but destroy actually means the end of import. In fact, there is no correct way for an entity processor to do clean up right now. Most do clean up when returning null (end of data) but with the introduction of $skipDoc, a transformer can return $skipDoc and the entity processor will never get a chance to clean up for the current init. # EntityProcessor will use the EventListener API to listen for import end. This should be used by EntityProcessor to do a final cleanup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1197) memcached implement solr cache for queryresultCache
memcached implement solr cache for queryresultCache Key: SOLR-1197 URL: https://issues.apache.org/jira/browse/SOLR-1197 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Environment: multiple slave solr replication environment Reporter: Linbin Chen Fix For: 1.4 multiple slave create query result together, and share that slaves. implement memcached cache instead LRUCache my implement: solr-memcache.zip http://solr-side.googlecode.com/files/solr-memcache.zip object transport by net need Serializable, so need patch solr 1.3, DocSetBase implements Serializable, see http://code.google.com/p/solr-side/issues/detail?id=1can=1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1197) memcached implement solr cache for queryresultCache
[ https://issues.apache.org/jira/browse/SOLR-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Linbin Chen updated SOLR-1197: -- Description: multiple slave create query result together, and slaves can share that. implement memcached cache instead LRUCache my implement: solr-memcache.zip http://solr-side.googlecode.com/files/solr-memcache.zip object transport by net need Serializable, so need patch solr 1.3, DocSetBase implements Serializable, see http://code.google.com/p/solr-side/issues/detail?id=1can=1 was: multiple slave create query result together, and share that slaves. implement memcached cache instead LRUCache my implement: solr-memcache.zip http://solr-side.googlecode.com/files/solr-memcache.zip object transport by net need Serializable, so need patch solr 1.3, DocSetBase implements Serializable, see http://code.google.com/p/solr-side/issues/detail?id=1can=1 memcached implement solr cache for queryresultCache Key: SOLR-1197 URL: https://issues.apache.org/jira/browse/SOLR-1197 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Environment: multiple slave solr replication environment Reporter: Linbin Chen Fix For: 1.4 multiple slave create query result together, and slaves can share that. implement memcached cache instead LRUCache my implement: solr-memcache.zip http://solr-side.googlecode.com/files/solr-memcache.zip object transport by net need Serializable, so need patch solr 1.3, DocSetBase implements Serializable, see http://code.google.com/p/solr-side/issues/detail?id=1can=1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1197) memcached implement solr cache for queryresultCache
[ https://issues.apache.org/jira/browse/SOLR-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Linbin Chen updated SOLR-1197: -- Attachment: SOLR_1197-solr-memcache.patch Solr 1.3 only DocSetBase implement Serializable memcached implement solr cache for queryresultCache Key: SOLR-1197 URL: https://issues.apache.org/jira/browse/SOLR-1197 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Environment: multiple slave solr replication environment Reporter: Linbin Chen Fix For: 1.4 Attachments: SOLR_1197-solr-memcache.patch multiple slave create query result together, and slaves can share that. implement memcached cache instead LRUCache my implement: solr-memcache.zip http://solr-side.googlecode.com/files/solr-memcache.zip object transport by net need Serializable, so need patch solr 1.3, DocSetBase implements Serializable, see http://code.google.com/p/solr-side/issues/detail?id=1can=1 -- 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-1197) memcached implement solr cache for queryresultCache
[ https://issues.apache.org/jira/browse/SOLR-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715879#action_12715879 ] Linbin Chen edited comment on SOLR-1197 at 6/3/09 2:41 AM: --- patch for Solr 1.3 this patch only DocSetBase implement Serializable was (Author: chenlb): Solr 1.3 only DocSetBase implement Serializable memcached implement solr cache for queryresultCache Key: SOLR-1197 URL: https://issues.apache.org/jira/browse/SOLR-1197 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Environment: multiple slave solr replication environment Reporter: Linbin Chen Fix For: 1.4 Attachments: SOLR_1197-solr-memcache.patch multiple slave create query result together, and slaves can share that. implement memcached cache instead LRUCache my implement: solr-memcache.zip http://solr-side.googlecode.com/files/solr-memcache.zip object transport by net need Serializable, so need patch solr 1.3, DocSetBase implements Serializable, see http://code.google.com/p/solr-side/issues/detail?id=1can=1 -- 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-1197) memcached implement solr cache for queryresultCache
[ https://issues.apache.org/jira/browse/SOLR-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715879#action_12715879 ] Linbin Chen edited comment on SOLR-1197 at 6/3/09 2:42 AM: --- patch for Solr 1.3 this patch only DocSetBase implement Serializable solr-memcache =readme.txt= MemcachedCache instead of solr queryresultCache (default LRUCache) config in solrconfig.xml to use solr-memcache add newSearcher and firstSearcher Listener, such as: listener event=newSearcher class=solr.MemcachedCache / listener event=firstSearcher class=solr.MemcachedCache / use listener only for get index version, to create memcached key indexVersion is static long field of MemcachedCache.java. //originalKey is QueryResultKey memcached key = keyPrefix+indexVersion+-+originalKey.hashCode() !-- MemcachedCache params: memcachedHosts (required), , split. name (optional) no default. expTime (optional) default 1800 s (= 30 minute) defaultPort (optional) default 11211 keyPrefix (optional) default -- queryResultCache class=solr.MemcachedCache memcachedHosts=192.168.0.100,192.168.0.101:1234,192.168.0.103 expTime=21600 defaultPort=11511 keyPrefix=shard-1-/ dep jar: memcached-2.2.jar spy-2.4.jar solr-memcache.patch for solr 1.3 if download and unzip to d:/apache-solr-1.3.0 copy patch-build.xml and solr-memcache.patch to (d:/apache-solr-1.3.0) D:\apache-solr-1.3.0ant -f patch-build.xml -Dpatch.file=solr-memcache.patch Buildfile: patch-build.xml apply-patch: [patch] patching file src/java/org/apache/solr/search/DocSet.java BUILD SUCCESSFUL Total time: 0 seconds if exist d:/apache-solr-1.3.0/contrib/solr-memcache, if no exist you can unzip solr-memcache.zip to that dir and dist D:\apache-solr-1.3.0ant dist ... look D:\apache-solr-1.3.0\dist\apache-solr-memcache-1.3.0.jar was (Author: chenlb): patch for Solr 1.3 this patch only DocSetBase implement Serializable memcached implement solr cache for queryresultCache Key: SOLR-1197 URL: https://issues.apache.org/jira/browse/SOLR-1197 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Environment: multiple slave solr replication environment Reporter: Linbin Chen Fix For: 1.4 Attachments: SOLR_1197-solr-memcache.patch multiple slave create query result together, and slaves can share that. implement memcached cache instead LRUCache my implement: solr-memcache.zip http://solr-side.googlecode.com/files/solr-memcache.zip object transport by net need Serializable, so need patch solr 1.3, DocSetBase implements Serializable, see http://code.google.com/p/solr-side/issues/detail?id=1can=1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
confine all solrconfig.xml parsing to SolrConfig.java - Key: SOLR-1198 URL: https://issues.apache.org/jira/browse/SOLR-1198 Project: Solr Issue Type: Improvement Reporter: Noble Paul Currently , xpath evaluations are spread across Solr code. It would be cleaner if if can do it all in one place . All the parsing can be done in SolrConfig.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1198: - Description: Currently , xpath evaluations are spread across Solr code. It would be cleaner if if can do it all in one place . All the parsing can be done in SolrConfig.java another problem with the current design is that we are not able to benefit from re-use of solrconfig object across cores. was:Currently , xpath evaluations are spread across Solr code. It would be cleaner if if can do it all in one place . All the parsing can be done in SolrConfig.java confine all solrconfig.xml parsing to SolrConfig.java - Key: SOLR-1198 URL: https://issues.apache.org/jira/browse/SOLR-1198 Project: Solr Issue Type: Improvement Reporter: Noble Paul Currently , xpath evaluations are spread across Solr code. It would be cleaner if if can do it all in one place . All the parsing can be done in SolrConfig.java another problem with the current design is that we are not able to benefit from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1199) [DIH] deltaImportQuery attribute is not used in child entities
[DIH] deltaImportQuery attribute is not used in child entities -- Key: SOLR-1199 URL: https://issues.apache.org/jira/browse/SOLR-1199 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.3 Reporter: Martin Davidsson From a message to solr-users (Noble Paul suggested I create an issue): I have a data-config.xml that is structured in the following fashion: document entity name=parent query=fullParentQuery deltaImportQuery=deltaParentImportQuery deltaQuery=deltaParentQuery entity name=child query=fullChildQuery deltaImportQuery=deltaChildImportQuery / /entity /document Is the deltaImportQuery attribute even allowed on the child entity? The behavior I'm seeing is that when I issue a delta-import command, Solr uses the deltaParentImportQuery and deltaParentQuery from the parent entity but the fullChildQuery from the child entity. I was hoping it would use the deltaChildImportQuery on the child entity, if it exists, to figure out what data to use in the case of a delta-import. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1200) NullPointerException when unloading an absent core
NullPointerException when unloading an absent core -- Key: SOLR-1200 URL: https://issues.apache.org/jira/browse/SOLR-1200 Project: Solr Issue Type: Bug Affects Versions: 1.4 Environment: java version 1.6.0_07 Reporter: Peter Wolanin Priority: Minor When I try to unload a core that does not exist (e.g. it has already been unloaded), Solr throws a NullPointerException java.lang.NullPointerException at org.apache.solr.handler.admin.CoreAdminHandler.handleUnloadAction(CoreAdminHandler.java:319) at org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:125) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:301) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:174) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1200) NullPointerException when unloading an absent core
[ https://issues.apache.org/jira/browse/SOLR-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Wolanin updated SOLR-1200: Attachment: SOLR-1200.patch Here's a simple patch that follows the pattern in the other core admin methods. NullPointerException when unloading an absent core -- Key: SOLR-1200 URL: https://issues.apache.org/jira/browse/SOLR-1200 Project: Solr Issue Type: Bug Affects Versions: 1.4 Environment: java version 1.6.0_07 Reporter: Peter Wolanin Priority: Minor Attachments: SOLR-1200.patch Original Estimate: 1h Remaining Estimate: 1h When I try to unload a core that does not exist (e.g. it has already been unloaded), Solr throws a NullPointerException java.lang.NullPointerException at org.apache.solr.handler.admin.CoreAdminHandler.handleUnloadAction(CoreAdminHandler.java:319) at org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:125) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:301) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:174) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: NPE when unloading an absent
I did not find any relevant issue, so here's a new issue with a patch: https://issues.apache.org/jira/browse/SOLR-1200 -Peter On Wed, Jun 3, 2009 at 4:56 PM, Peter Wolanin peter.wola...@acquia.com wrote: Is this a known bug? When I try to unload a core that does not exist, Solr throws a NullPointerException java.lang.NullPointerException at org.apache.solr.handler.admin.CoreAdminHandler.handleUnloadAction(CoreAdminHandler.java:319) at org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:125) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:301) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:174) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) -- Peter M. Wolanin, Ph.D. Momentum Specialist, Acquia. Inc. peter.wola...@acquia.com
[jira] Commented: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12716128#action_12716128 ] Ron Veenstra commented on SOLR-236: --- I require assistance. I've installed a fresh Solr (1.3.0), and all appears/operates well. I then patch using SOLR-236_collapsing.patch (the last patch i saw claimed to work with 1.3.0), without error. I then add to solrconfig.xml the following (per: http://wiki.apache.org/solr/FieldCollapsing) : searchComponent name=collapse class=org.apache.solr.handler.component.CollapseComponent / Upon restart, I get a long configuration error, which seems to hinge on: HTTP Status 500 - Severe errors in solr configuration. Check your log files for more detailed information on what may be wrong. If you want solr to continue after configuration errors, change: abortOnConfigurationErrorfalse/abortOnConfigurationError in solrconfig.xml - org.apache.solr.common.SolrException: Error loading class 'org.apache.solr.handler.component.CollapseComponent' at org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:273) [the full error can be included if desired.] I've verified that the CollapseComponent file exists in the proper place. I've moved CollapseParams as required, (move CollapseParams.java from common/org/apache/solr/common/params to java/org/apache/solr/common/params/ ) I've tried multiple iterations of the patch (on fresh installs), all with the same issue. Are there additional steps, patches, or configurations that are required? Is this a known issue? Any help is very much appreciated. Field collapsing Key: SOLR-236 URL: https://issues.apache.org/jira/browse/SOLR-236 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Emmanuel Keller Fix For: 1.5 Attachments: collapsing-patch-to-1.3.0-dieter.patch, collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, collapsing-patch-to-1.3.0-ivan_3.patch, field-collapse-solr-236-2.patch, field-collapse-solr-236.patch, field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, solr-236.patch, SOLR-236_collapsing.patch, SOLR-236_collapsing.patch This patch include a new feature called Field collapsing. Used in order to collapse a group of results with similar value for a given field to a single entry in the result set. Site collapsing is a special case of this, where all results for a given web site is collapsed into one or two entries in the result set, typically with an associated more documents from this site link. See also Duplicate detection. http://www.fastsearch.com/glossary.aspx?m=48amid=299 The implementation add 3 new query parameters (SolrParams): collapse.field to choose the field used to group results collapse.type normal (default value) or adjacent collapse.max to select how many continuous results are allowed before collapsing TODO (in progress): - More documentation (on source code) - Test cases Two patches: - field_collapsing.patch for current development version - field_collapsing_1.1.0.patch for Solr-1.1.0 P.S.: Feedback and misspelling correction are welcome ;-) -- 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-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12716128#action_12716128 ] Ron Veenstra edited comment on SOLR-236 at 6/3/09 7:22 PM: --- I require assistance. I've installed a fresh Solr (1.3.0), and all appears/operates well. I then patch using SOLR-236_collapsing.patch [by Thomas Traeger] (the last patch i saw claimed to work with 1.3.0), without error. I then add to solrconfig.xml the following (per: http://wiki.apache.org/solr/FieldCollapsing) : searchComponent name=collapse class=org.apache.solr.handler.component.CollapseComponent / Upon restart, I get a long configuration error, which seems to hinge on: HTTP Status 500 - Severe errors in solr configuration. Check your log files for more detailed information on what may be wrong. If you want solr to continue after configuration errors, change: abortOnConfigurationErrorfalse/abortOnConfigurationError in solrconfig.xml - org.apache.solr.common.SolrException: Error loading class 'org.apache.solr.handler.component.CollapseComponent' at org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:273) [the full error can be included if desired.] I've verified that the CollapseComponent file exists in the proper place. I've moved CollapseParams as required, (move CollapseParams.java from common/org/apache/solr/common/params to java/org/apache/solr/common/params/ ) I've tried multiple iterations of the patch (on fresh installs), all with the same issue. Are there additional steps, patches, or configurations that are required? Is this a known issue? Any help is very much appreciated. was (Author: ronunism): I require assistance. I've installed a fresh Solr (1.3.0), and all appears/operates well. I then patch using SOLR-236_collapsing.patch (the last patch i saw claimed to work with 1.3.0), without error. I then add to solrconfig.xml the following (per: http://wiki.apache.org/solr/FieldCollapsing) : searchComponent name=collapse class=org.apache.solr.handler.component.CollapseComponent / Upon restart, I get a long configuration error, which seems to hinge on: HTTP Status 500 - Severe errors in solr configuration. Check your log files for more detailed information on what may be wrong. If you want solr to continue after configuration errors, change: abortOnConfigurationErrorfalse/abortOnConfigurationError in solrconfig.xml - org.apache.solr.common.SolrException: Error loading class 'org.apache.solr.handler.component.CollapseComponent' at org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:273) [the full error can be included if desired.] I've verified that the CollapseComponent file exists in the proper place. I've moved CollapseParams as required, (move CollapseParams.java from common/org/apache/solr/common/params to java/org/apache/solr/common/params/ ) I've tried multiple iterations of the patch (on fresh installs), all with the same issue. Are there additional steps, patches, or configurations that are required? Is this a known issue? Any help is very much appreciated. Field collapsing Key: SOLR-236 URL: https://issues.apache.org/jira/browse/SOLR-236 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Emmanuel Keller Fix For: 1.5 Attachments: collapsing-patch-to-1.3.0-dieter.patch, collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, collapsing-patch-to-1.3.0-ivan_3.patch, field-collapse-solr-236-2.patch, field-collapse-solr-236.patch, field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, solr-236.patch, SOLR-236_collapsing.patch, SOLR-236_collapsing.patch This patch include a new feature called Field collapsing. Used in order to collapse a group of results with similar value for a given field to a single entry in the result set. Site collapsing is a special case of this, where all results for a given web site is collapsed into one or two entries in the result set, typically with an associated more documents from this site link. See also Duplicate detection. http://www.fastsearch.com/glossary.aspx?m=48amid=299 The implementation add 3 new query parameters (SolrParams): collapse.field to choose the field used to group results collapse.type normal (default value) or adjacent collapse.max to select how many continuous
