[jira] [Commented] (LUCENE-668) Incremental Search
[ https://issues.apache.org/jira/browse/LUCENE-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155955#comment-13155955 ] Antony Stubbs commented on LUCENE-668: -- Hi Mark, don't you think this is a valid feature request? > Incremental Search > -- > > Key: LUCENE-668 > URL: https://issues.apache.org/jira/browse/LUCENE-668 > Project: Lucene - Java > Issue Type: Improvement > Components: core/search >Affects Versions: 1.9, 2.0.0, 2.1 > Environment: All >Reporter: Fernando Mato Mira >Priority: Minor > > Add full support for long searches executed in steps. > QueryFilters only support narrowing down a set of results, they don't allow > extending it with OR clauses. They also don't allow to add new clauses to > SpanQueries. > This facility is needed because repeatedly creating new queries and executing > a full, more complicated query at each step is not efficient for search > sessions where you may have chains of hundreds of such steps. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-668) Incremental Search
[ https://issues.apache.org/jira/browse/LUCENE-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155960#comment-13155960 ] Antony Stubbs commented on LUCENE-668: -- Cool, thanks for the explanation Uwe. > Incremental Search > -- > > Key: LUCENE-668 > URL: https://issues.apache.org/jira/browse/LUCENE-668 > Project: Lucene - Java > Issue Type: Improvement > Components: core/search >Affects Versions: 1.9, 2.0.0, 2.1 > Environment: All >Reporter: Fernando Mato Mira >Priority: Minor > > Add full support for long searches executed in steps. > QueryFilters only support narrowing down a set of results, they don't allow > extending it with OR clauses. They also don't allow to add new clauses to > SpanQueries. > This facility is needed because repeatedly creating new queries and executing > a full, more complicated query at each step is not efficient for search > sessions where you may have chains of hundreds of such steps. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1268) Incorporate Lucene's FastVectorHighlighter
[ https://issues.apache.org/jira/browse/SOLR-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178463#comment-13178463 ] Antony Stubbs commented on SOLR-1268: - Koji, with mutli-term fields, Highlighter would return the single value that matched. FVH however merges values in the fragment returned. Is there a way to get the same behavior as highlighter in this respect (in my use case, i only want the value that matched to be highlighted)? > Incorporate Lucene's FastVectorHighlighter > -- > > Key: SOLR-1268 > URL: https://issues.apache.org/jira/browse/SOLR-1268 > Project: Solr > Issue Type: New Feature > Components: highlighter >Reporter: Koji Sekiguchi >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.1, 4.0 > > Attachments: SOLR-1268-0_fragsize.patch, SOLR-1268-0_fragsize.patch, > SOLR-1268.patch, SOLR-1268.patch, SOLR-1268.patch > > > Correcting Fix Version based on CHANGES.txt, see this thread for more > details... > http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3calpine.deb.1.10.1005251052040.24...@radix.cryptio.net%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2464) FastVectorHighlighter: add a FragmentBuilder to return entire field contents
[ https://issues.apache.org/jira/browse/LUCENE-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178828#comment-13178828 ] Antony Stubbs commented on LUCENE-2464: --- Related to : SOLR-2998 Standard highlighter would, specifically LuceneGapFragmenter, only return a single highlighted value from mutlivalue field highlighting. I can't see how to get the same response from FVH, it seems to insist on concatenating all values of a multivalue field together (or at least surrounding values on highlight matches. > FastVectorHighlighter: add a FragmentBuilder to return entire field contents > > > Key: LUCENE-2464 > URL: https://issues.apache.org/jira/browse/LUCENE-2464 > Project: Lucene - Java > Issue Type: Improvement > Components: modules/highlighter >Reporter: Koji Sekiguchi >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.1 > > Attachments: LUCENE-2464.patch > > > In Highlightrer, there is a Nullfragmenter. There is a requirement its > counterpart in FastVectorhighlighter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1566) Allow components to add fields to outgoing documents
[ https://issues.apache.org/jira/browse/SOLR-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178856#comment-13178856 ] Antony Stubbs commented on SOLR-1566: - Are there any tests writing for any of the doctransformer architecture? I can't find any. I'm looking for something to base tests for a new regex transformer and highlighting augmenting transformer.. > Allow components to add fields to outgoing documents > > > Key: SOLR-1566 > URL: https://issues.apache.org/jira/browse/SOLR-1566 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Noble Paul >Assignee: Ryan McKinley > Fix For: 4.0 > > Attachments: SOLR-1566-DocTransformer.patch, > SOLR-1566-DocTransformer.patch, SOLR-1566-DocTransformer.patch, > SOLR-1566-DocTransformer.patch, SOLR-1566-DocTransformer.patch, > SOLR-1566-DocTransformer.patch, SOLR-1566-PageTool.patch, > SOLR-1566-gsi.patch, SOLR-1566-rm.patch, SOLR-1566-rm.patch, > SOLR-1566-rm.patch, SOLR-1566-rm.patch, SOLR-1566-rm.patch, SOLR-1566.patch, > SOLR-1566.patch, SOLR-1566.patch, SOLR-1566.patch, SOLR-1566_parsing.patch > > > Currently it is not possible for components to add fields to outgoing > documents which are not in the the stored fields of the document. This makes > it cumbersome to add computed fields/metadata . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1566) Allow components to add fields to outgoing documents
[
https://issues.apache.org/jira/browse/SOLR-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178926#comment-13178926
]
Antony Stubbs commented on SOLR-1566:
-
Thanks, that's a start. I'm specifically looking to access the highlighting
results, but I can't see how I can. The highlighting results are added to the
ResponseBuilder.Response directly in HighlightingComponent:
rb.rsp.add("highlighting", sumData);. I want to be able to extract that
highlighting component and do some processing on it in my DocTransformer..
> Allow components to add fields to outgoing documents
>
>
> Key: SOLR-1566
> URL: https://issues.apache.org/jira/browse/SOLR-1566
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Noble Paul
>Assignee: Ryan McKinley
> Fix For: 4.0
>
> Attachments: SOLR-1566-DocTransformer.patch,
> SOLR-1566-DocTransformer.patch, SOLR-1566-DocTransformer.patch,
> SOLR-1566-DocTransformer.patch, SOLR-1566-DocTransformer.patch,
> SOLR-1566-DocTransformer.patch, SOLR-1566-PageTool.patch,
> SOLR-1566-gsi.patch, SOLR-1566-rm.patch, SOLR-1566-rm.patch,
> SOLR-1566-rm.patch, SOLR-1566-rm.patch, SOLR-1566-rm.patch, SOLR-1566.patch,
> SOLR-1566.patch, SOLR-1566.patch, SOLR-1566.patch, SOLR-1566_parsing.patch
>
>
> Currently it is not possible for components to add fields to outgoing
> documents which are not in the the stored fields of the document. This makes
> it cumbersome to add computed fields/metadata .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1566) Allow components to add fields to outgoing documents
[ https://issues.apache.org/jira/browse/SOLR-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179092#comment-13179092 ] Antony Stubbs commented on SOLR-1566: - Thanks Ryan.. I was trying to get access to the highlighting results, rather than run it from the transformer - doesn't seem right. But it could be a start.. I think I saw an access point for that... > Allow components to add fields to outgoing documents > > > Key: SOLR-1566 > URL: https://issues.apache.org/jira/browse/SOLR-1566 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Noble Paul >Assignee: Ryan McKinley > Fix For: 4.0 > > Attachments: SOLR-1566-DocTransformer.patch, > SOLR-1566-DocTransformer.patch, SOLR-1566-DocTransformer.patch, > SOLR-1566-DocTransformer.patch, SOLR-1566-DocTransformer.patch, > SOLR-1566-DocTransformer.patch, SOLR-1566-PageTool.patch, > SOLR-1566-gsi.patch, SOLR-1566-rm.patch, SOLR-1566-rm.patch, > SOLR-1566-rm.patch, SOLR-1566-rm.patch, SOLR-1566-rm.patch, SOLR-1566.patch, > SOLR-1566.patch, SOLR-1566.patch, SOLR-1566.patch, SOLR-1566_parsing.patch > > > Currently it is not possible for components to add fields to outgoing > documents which are not in the the stored fields of the document. This makes > it cumbersome to add computed fields/metadata . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2804) Logging error causes entire DIH process to fail
[ https://issues.apache.org/jira/browse/SOLR-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179181#comment-13179181 ] Antony Stubbs commented on SOLR-2804: - Hi. I keep forgetting to change the logging level in the admin tool when I restart. Is there an easy way to permanently change this setting? perhaps -D param? > Logging error causes entire DIH process to fail > --- > > Key: SOLR-2804 > URL: https://issues.apache.org/jira/browse/SOLR-2804 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 4.0 > Environment: java version "1.6.0_26" > Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425) > Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode) > Model Name: MacBook Pro > Model Identifier: MacBookPro8,2 > Processor Name: Intel Core i7 > Processor Speed:2.2 GHz > Number of Processors: 1 > Total Number of Cores: 4 > L2 Cache (per Core):256 KB > L3 Cache: 6 MB > Memory: 4 GB > System Software Overview: > System Version: Mac OS X 10.6.8 (10K549) > Kernel Version: Darwin 10.8.0 >Reporter: Pulkit Singhal > Labels: dih > Attachments: SOLR-2804-3x.patch, SOLR-2804.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > SEVERE: Full Import failed:java.lang.ClassCastException: > java.util.ArrayList cannot be cast to java.lang.String >at org.apache.solr.common.util.NamedList.getName(NamedList.java:127) >at org.apache.solr.common.util.NamedList.toString(NamedList.java:263) >at java.lang.String.valueOf(String.java:2826) >at java.lang.StringBuilder.append(StringBuilder.java:115) >at > org.apache.solr.update.processor.LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:188) >at > org.apache.solr.handler.dataimport.SolrWriter.close(SolrWriter.java:57) >at > org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:265) >at > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:372) >at > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:440) >at > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:421) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2998) FastVectorHighlighter should be able to return single matched multivalue result, not concatenate surrounding values
[
https://issues.apache.org/jira/browse/SOLR-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179219#comment-13179219
]
Antony Stubbs commented on SOLR-2998:
-
A better explanation:
This comment is a variation on __. Can we get a modification for
SingleFragListBuilder that when working on a multivalued field, return an
entire, _single_, value from the set of multi values? I.e. instead of the
entire collection of values, return the entire single value. i.e.
index (multi value field): {one, wow two wow, three}
hl.q: two
returns: "wow two wow"
instead of current: "..ne wow two wow thr.."
> FastVectorHighlighter should be able to return single matched multivalue
> result, not concatenate surrounding values
> ---
>
> Key: SOLR-2998
> URL: https://issues.apache.org/jira/browse/SOLR-2998
> Project: Solr
> Issue Type: Improvement
> Components: highlighter
>Affects Versions: 4.0
>Reporter: Antony Stubbs
>
> Standard highlighter would, specifically LuceneGapFragmenter, only return a
> single highlighted value from mutlivalue field highlighting. I can't see how
> to get the same response from FVH, it seems to insist on concatenating all
> values of a multivalue field together (or at least surrounding values on
> highlight matches.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2804) Logging error causes entire DIH process to fail
[ https://issues.apache.org/jira/browse/SOLR-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179941#comment-13179941 ] Antony Stubbs commented on SOLR-2804: - Seems this causes SOLR-3003 :/ @Mikhail, what does solr use by default? Can't see anything.. > Logging error causes entire DIH process to fail > --- > > Key: SOLR-2804 > URL: https://issues.apache.org/jira/browse/SOLR-2804 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 4.0 > Environment: java version "1.6.0_26" > Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425) > Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode) > Model Name: MacBook Pro > Model Identifier: MacBookPro8,2 > Processor Name: Intel Core i7 > Processor Speed:2.2 GHz > Number of Processors: 1 > Total Number of Cores: 4 > L2 Cache (per Core):256 KB > L3 Cache: 6 MB > Memory: 4 GB > System Software Overview: > System Version: Mac OS X 10.6.8 (10K549) > Kernel Version: Darwin 10.8.0 >Reporter: Pulkit Singhal > Labels: dih > Attachments: SOLR-2804-3x.patch, SOLR-2804.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > SEVERE: Full Import failed:java.lang.ClassCastException: > java.util.ArrayList cannot be cast to java.lang.String >at org.apache.solr.common.util.NamedList.getName(NamedList.java:127) >at org.apache.solr.common.util.NamedList.toString(NamedList.java:263) >at java.lang.String.valueOf(String.java:2826) >at java.lang.StringBuilder.append(StringBuilder.java:115) >at > org.apache.solr.update.processor.LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:188) >at > org.apache.solr.handler.dataimport.SolrWriter.close(SolrWriter.java:57) >at > org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:265) >at > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:372) >at > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:440) >at > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:421) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3029) Poor json formatting of spelling collation info
[
https://issues.apache.org/jira/browse/SOLR-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184238#comment-13184238
]
Antony Stubbs commented on SOLR-3029:
-
I imagine this will also be in 3.5?
> Poor json formatting of spelling collation info
> ---
>
> Key: SOLR-3029
> URL: https://issues.apache.org/jira/browse/SOLR-3029
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
>Affects Versions: 4.0
>Reporter: Antony Stubbs
>
> {noformat}
> "spellcheck": {
> "suggestions": [
> "dalllas",
> {
>
> {
> "word": "canallas",
> "freq": 1
> }
> ]
> },
> "correctlySpelled",
> false,
> "collation",
> "dallas"
> ]
> }
> {noformat}
> The correctlySpelled and collation key/values are stored as consecutive
> elements in an array - quite odd. Is there a reason isn't not a key/value map
> like most things?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184441#comment-13184441 ] Antony Stubbs commented on SOLR-1277: - What happened in regards to multicore support and zookeeper? http://wiki.apache.org/solr/SolrCloud http://wiki.apache.org/solr/ZooKeeperIntegration but it's as clear as mud. Do either systems support multicore? Or do I need to setup 4 servers, 2 for each core? (I have a single server with 2 cores - I want redundancy). Does SolrCloud supersede ZooKeeperIntegration? > Implement a Solr specific naming service (using Zookeeper) > -- > > Key: SOLR-1277 > URL: https://issues.apache.org/jira/browse/SOLR-1277 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 3.2 > > Attachments: SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, > SOLR-1277.patch, log4j-1.2.15.jar, zookeeper-3.2.1.jar > > Original Estimate: 672h > Remaining Estimate: 672h > > The goal is to give Solr server clusters self-healing attributes > where if a server fails, indexing and searching don't stop and > all of the partitions remain searchable. For configuration, the > ability to centrally deploy a new configuration without servers > going offline. > We can start with basic failover and start from there? > Features: > * Automatic failover (i.e. when a server fails, clients stop > trying to index to or search it) > * Centralized configuration management (i.e. new solrconfig.xml > or schema.xml propagates to a live Solr cluster) > * Optionally allow shards of a partition to be moved to another > server (i.e. if a server gets hot, move the hot segments out to > cooler servers). Ideally we'd have a way to detect hot segments > and move them seamlessly. With NRT this becomes somewhat more > difficult but not impossible? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2667) Finish Solr Admin UI
[ https://issues.apache.org/jira/browse/SOLR-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184471#comment-13184471 ] Antony Stubbs commented on SOLR-2667: - It seems the ui for dataimporthandler doesn't pass through the clean, optimize or commit commands when clicking execute. No mater what I select, it only passes through the "command". > Finish Solr Admin UI > > > Key: SOLR-2667 > URL: https://issues.apache.org/jira/browse/SOLR-2667 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Fix For: 4.0 > > Attachments: SOLR-2667-110722.patch > > > In SOLR-2399, we added a new admin UI. The issue has gotten too long to > follow, so this is a new issue to track remaining tasks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2329) old index files not deleted on slave
[ https://issues.apache.org/jira/browse/SOLR-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189260#comment-13189260 ] Antony Stubbs commented on SOLR-2329: - I also have the same problem with the index growing wihtout restriction on the slave. Except I see no errors in the log. It was discussed 3 years ago here: http://lucene.472066.n3.nabble.com/Solr-Replication-disk-space-consumed-on-slave-much-higher-than-on-master-td494237.html > old index files not deleted on slave > > > Key: SOLR-2329 > URL: https://issues.apache.org/jira/browse/SOLR-2329 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 4.0 > Environment: centos 5.5 > ext3 file system >Reporter: Edwin Khodabakchian > Attachments: solrconfig.xml, solrconfig_slave.xml > > > I have set up index replication (triggered on optimize). The problem I > am having is the old index files are not being deleted on the slave. > After each replication, I can see the old files still hanging around > as well as the files that have just been pulled. This causes the data > directory size to increase by the index size every replication until > the disk fills up. > I am running 4.0 rev 993367 with patch SOLR-1316. Otherwise, the setup > is pretty vanilla. I can reproduce this on multiple slaves. > Checking the logs, I see the following error: > SEVERE: SnapPull failed > org.apache.solr.common.SolrException: Index fetch failed : >at > org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:329) >at > org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:265) >at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:159) >at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) >at > java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) >at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) >at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) >at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) >at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) >at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >at java.lang.Thread.run(Thread.java:619) > Caused by: org.apache.lucene.store.LockObtainFailedException: Lock > obtain timed out: > NativeFSLock@/var/solrhome/data/index/lucene-cdaa80c0fefe1a7dfc7aab89298c614c-write.lock >at org.apache.lucene.store.Lock.obtain(Lock.java:84) >at org.apache.lucene.index.IndexWriter.(IndexWriter.java:1065) >at org.apache.lucene.index.IndexWriter.(IndexWriter.java:954) >at > org.apache.solr.update.SolrIndexWriter.(SolrIndexWriter.java:192) >at > org.apache.solr.update.UpdateHandler.createMainIndexWriter(UpdateHandler.java:99) >at > org.apache.solr.update.DirectUpdateHandler2.openWriter(DirectUpdateHandler2.java:173) >at > org.apache.solr.update.DirectUpdateHandler2.forceOpenWriter(DirectUpdateHandler2.java:376) >at org.apache.solr.handler.SnapPuller.doCommit(SnapPuller.java:471) >at > org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:319) >... 11 more > lsof reveals that the file is still opened from the java process. > Contents of the index data dir: > master: > -rw-rw-r-- 1 feeddo feeddo 191 Dec 14 01:06 _1lg.fnm > -rw-rw-r-- 1 feeddo feeddo 26M Dec 14 01:07 _1lg.fdx > -rw-rw-r-- 1 feeddo feeddo 1.9G Dec 14 01:07 _1lg.fdt > -rw-rw-r-- 1 feeddo feeddo 474M Dec 14 01:12 _1lg.tis > -rw-rw-r-- 1 feeddo feeddo 15M Dec 14 01:12 _1lg.tii > -rw-rw-r-- 1 feeddo feeddo 144M Dec 14 01:12 _1lg.prx > -rw-rw-r-- 1 feeddo feeddo 277M Dec 14 01:12 _1lg.frq > -rw-rw-r-- 1 feeddo feeddo 311 Dec 14 01:12 segments_1ji > -rw-rw-r-- 1 feeddo feeddo 23M Dec 14 01:12 _1lg.nrm > -rw-rw-r-- 1 feeddo feeddo 191 Dec 18 01:11 _24e.fnm > -rw-rw-r-- 1 feeddo feeddo 26M Dec 18 01:12 _24e.fdx > -rw-rw-r-- 1 feeddo feeddo 1.9G Dec 18 01:12 _24e.fdt > -rw-rw-r-- 1 feeddo feeddo 483M Dec 18 01:23 _24e.tis > -rw-rw-r-- 1 feeddo feeddo 15M Dec 18 01:23 _24e.tii > -rw-rw-r-- 1 feeddo feeddo 146M Dec 18 01:23 _24e.prx > -rw-rw-r-- 1 feeddo feeddo 283M Dec 18 01:23 _24e.frq > -rw-rw-r-- 1 feeddo feeddo 311 Dec 18 01:24 segments_1xz > -rw-rw-r-- 1 feeddo feeddo 23M Dec 18 01:24 _24e.nrm > -rw-rw-r-- 1 feeddo feeddo 191 Dec 18 13:15 _25z.fnm > -rw-rw-r-- 1 feeddo feeddo 26M Dec 18 13:16 _
[jira] [Commented] (SOLR-1601) Schema browser does not indicate presence of charFilter
[
https://issues.apache.org/jira/browse/SOLR-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196578#comment-13196578
]
Antony Stubbs commented on SOLR-1601:
-
I'm running 4 and I don't see any char filters still.
> Schema browser does not indicate presence of charFilter
> ---
>
> Key: SOLR-1601
> URL: https://issues.apache.org/jira/browse/SOLR-1601
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Affects Versions: 1.4
>Reporter: Jake Brownell
>Assignee: Koji Sekiguchi
>Priority: Trivial
> Fix For: 1.5, 3.1, 4.0
>
> Attachments: SOLR-1601.patch
>
>
> My schema has a field defined as:
> {noformat}
> positionIncrementGap="100">
>
> mapping="mapping-ISOLatin1Accent.txt"/>
>
> words="stopwords.txt" enablePositionIncrements="true" />
> generateWordParts="1" generateNumberParts="1"
> catenateWords="1" catenateNumbers="1" catenateAll="0"
> splitOnCaseChange="1" />
>
> protected="protwords.txt" />
>
>
>
>
> mapping="mapping-ISOLatin1Accent.txt"/>
>
> synonyms="synonyms.txt"
> ignoreCase="true" expand="true"/>
> words="stopwords.txt" enablePositionIncrements="true" />
>
> generateWordParts="1" generateNumberParts="1"
> catenateWords="0" catenateNumbers="0" catenateAll="0"
> splitOnCaseChange="1" />
>
> protected="protwords.txt" />
>
>
>
>
> {noformat}
> and when I view the field in the schema browser, I see:
> {noformat}
> Tokenized: true
> Class Name: org.apache.solr.schema.TextField
> Index Analyzer: org.apache.solr.analysis.TokenizerChain
> Tokenizer Class: org.apache.solr.analysis.WhitespaceTokenizerFactory
> Filters:
> org.apache.solr.analysis.StopFilterFactory args:{words: stopwords.txt
> ignoreCase: true enablePositionIncrements: true }
> org.apache.solr.analysis.WordDelimiterFilterFactory args:{splitOnCaseChange:
> 1 generateNumberParts: 1 catenateWords: 1 generateWordParts: 1 catenateAll: 0
> catenateNumbers: 1 }
> org.apache.solr.analysis.LowerCaseFilterFactory args:{}
> org.apache.solr.analysis.EnglishPorterFilterFactory args:{protected:
> protwords.txt }
> org.apache.solr.analysis.RemoveDuplicatesTokenFilterFactory args:{}
> Query Analyzer: org.apache.solr.analysis.TokenizerChain
> Tokenizer Class: org.apache.solr.analysis.WhitespaceTokenizerFactory
> Filters:
> org.apache.solr.analysis.SynonymFilterFactory args:{synonyms: synonyms.txt
> expand: true ignoreCase: true }
> org.apache.solr.analysis.StopFilterFactory args:{words: stopwords.txt
> ignoreCase: true enablePositionIncrements: true }
> org.apache.solr.analysis.WordDelimiterFilterFactory args:{splitOnCaseChange:
> 1 generateNumberParts: 1 catenateWords: 0 generateWordParts: 1 catenateAll: 0
> catenateNumbers: 0 }
> org.apache.solr.analysis.LowerCaseFilterFactory args:{}
> org.apache.solr.analysis.EnglishPorterFilterFactory args:{protected:
> protwords.txt }
> org.apache.solr.analysis.RemoveDuplicatesTokenFilterFactory args:{}
> {noformat}
> It's not a big deal, but I expected to see some indication of the charFilter
> that is in place.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3034) replicateAfter optimize not working
[
https://issues.apache.org/jira/browse/SOLR-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197940#comment-13197940
]
Antony Stubbs commented on SOLR-3034:
-
Yes, replication is working great after new imports.
Should optimising cause the index generation to increment? I don't see it
increment. After clicking optimise, I only see log messages around the commit,
nothing about optimise.
Also, in the UI, after I run optimise, the tick appears, but if I refresh the
page, it does not appear to remain 'optimised', as the tick goes back to cross.
(There are no imports happening).
I'm running on a build from jenkins from
apache-solr-4.0-2012-01-30_09-45-51.zip.
Perhaps my index isn't actually being optimised..
> replicateAfter optimize not working
> ---
>
> Key: SOLR-3034
> URL: https://issues.apache.org/jira/browse/SOLR-3034
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Antony Stubbs
>
> I have:
> {noformat}
> optimize
> commit
> startup
> {noformat}
> But the UI only shows:
> {noformat}
> replicateAfter:commit, startup
> {noformat}
> And sure enough, optimizing does not cause a replication to happen.
> Also, replicating an optimized index, does not seem to keep in "optimized" on
> the slave. Is that really the case, or is it a bug? I would expect if an
> index is optimized on master, when it is then replicated to slaves, the
> slaves would receive the optimized index.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3047) DisMaxQParserPlugin drops my field in the phrase field list (pf) if it uses KeywordTokenizer instead of StandardTokenizer or Whitespace
[ https://issues.apache.org/jira/browse/SOLR-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199111#comment-13199111 ] Antony Stubbs commented on SOLR-3047: - Ok, I'll try to reproduce it in a simple setup. > DisMaxQParserPlugin drops my field in the phrase field list (pf) if it uses > KeywordTokenizer instead of StandardTokenizer or Whitespace > --- > > Key: SOLR-3047 > URL: https://issues.apache.org/jira/browse/SOLR-3047 > Project: Solr > Issue Type: Bug >Reporter: Antony Stubbs > > Has this got something to do with the minimum clause = 2 part in the code? It > drops it without warning - IMO it should error out if the field isn't > compatible. > If it is on purpose - i don't see why. I split with the ngram token filter, > so there is def more than 1 clause in the indexed field. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3047) DisMaxQParserPlugin drops my field in the phrase field list (pf) if it uses KeywordTokenizer instead of StandardTokenizer or Whitespace
[ https://issues.apache.org/jira/browse/SOLR-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199119#comment-13199119 ] Antony Stubbs commented on SOLR-3047: - Hoss, is there a way I can send you the example privately? > DisMaxQParserPlugin drops my field in the phrase field list (pf) if it uses > KeywordTokenizer instead of StandardTokenizer or Whitespace > --- > > Key: SOLR-3047 > URL: https://issues.apache.org/jira/browse/SOLR-3047 > Project: Solr > Issue Type: Bug >Reporter: Antony Stubbs > > Has this got something to do with the minimum clause = 2 part in the code? It > drops it without warning - IMO it should error out if the field isn't > compatible. > If it is on purpose - i don't see why. I split with the ngram token filter, > so there is def more than 1 clause in the indexed field. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3047) DisMaxQParserPlugin drops my field in the phrase field list (pf) if it uses KeywordTokenizer instead of StandardTokenizer or Whitespace
[ https://issues.apache.org/jira/browse/SOLR-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199125#comment-13199125 ] Antony Stubbs commented on SOLR-3047: - It just seems that if the field tokeniser only produces a single token (as keywordtokenizer produces), it gets silently dropped from phrase list queries (even though multiple tokens are produced by the ngramfilter in the end). If I just change the tokenizer to standard, it works as expected. > DisMaxQParserPlugin drops my field in the phrase field list (pf) if it uses > KeywordTokenizer instead of StandardTokenizer or Whitespace > --- > > Key: SOLR-3047 > URL: https://issues.apache.org/jira/browse/SOLR-3047 > Project: Solr > Issue Type: Bug >Reporter: Antony Stubbs > > Has this got something to do with the minimum clause = 2 part in the code? It > drops it without warning - IMO it should error out if the field isn't > compatible. > If it is on purpose - i don't see why. I split with the ngram token filter, > so there is def more than 1 clause in the indexed field. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
